rns.recipes

Lew wrote:

Zenith wrote:
> Lol, go fuck yourself. When I ran your vibecoded dumpsterfire of a "port", it didn't even work against the basic link examples included in the Python ref. Did you not also write this "Killing Reticulum to Save It"?

Wow, 'go fuck yourself' ... that's the aggressive conversation you prefer? Insults end every discussion.

Hint: It is only possible to establish a productive community with a respectful tone and constructive criticism, even when people have different views.

Insulting people drives them out our your forum, Zenith, and I assume that's your attention. With me, you are successfull.

Ok, bye.

Here's a commit to your project, Leviculum, that is a Sloppulus of epic proportions where it's just Claude talking to itself over and over, designing some Rube Goldberg Bash script contraption to try and remove "Co-Authored by Claude" from the commit line. https://codeberg.org/Lew_Palm/Leviculum/commit/99439d7cb999c1b912dc5a95bc1f8da17b8bbd6f

https://codeberg.org/Lew_Palm/Leviculum/commit/76810ff9f690d31a4afbed56a04635f7bf4a681c

The diff total is more than 1000 lines. I think this is a prime example of why you should not use vibecoded Reticulum ports. But tell me more about how you are killing Reticulum to save it or whatever.

"LLMs give people the confidence to do something a skilled person can, but not the understanding or wisdom to know why it works."

Totally agree and support!!! The tacit knowledge is something this sequential convergence machine, called AI, will NEVER get.
People touch it and decide they have become gods of programming, empowered and capable, but they forget the simple truth - AI is a tool, that VERY CLEARLY conducts the tacit knowledge of the person using it. When there is zero understanding, humility and respect for what one starts from, the result is shit.
I am not into programming, but I have fought this game with a VERY sophisticated AI auto-router for PCB's. The thing, no matter how many rules the guy against me injected onto it, failed miserably in routing a 100W HF amplifier board. And just because the guy behind the wheel had zero real understanding of what it took to make one successfully.
As we say in Bulgaria - We found the problem plaguing your car! It is the bushing between the driver's seat and the steering wheel!
And I want to add - Zenith's behavior is driven not by ill manners, but by the same deep and enduring sickness we get in out stomachs, when we hit against the next piece of shit, pretending to be the next Bigger Better Reticulum. So I support him wholeheartedly!

reposted by accident

Zenith wrote:

Here's a commit to your project, Leviculum, that is a Sloppulus of epic proportions where it's just Claude talking to itself over and over, designing some Rube Goldberg Bash script contraption to try and remove "Co-Authored by Claude" from the commit line. https://codeberg.org/Lew_Palm/Leviculum/commit/99439d7cb999c1b912dc5a95bc1f8da17b8bbd6f

https://codeberg.org/Lew_Palm/Leviculum/commit/76810ff9f690d31a4afbed56a04635f7bf4a681c

The diff total is more than 1000 lines. I think this is a prime example of why you should not use vibecoded Reticulum ports. But tell me more about how you are killing Reticulum to save it or whatever.

What the actual fuck.

Rust implementations:

1. Beechat Reticulum-rs - https://github.com/BeechatNetworkSystemsLtd/Reticulum-rs
2. LXMF-rs - https://github.com/FreeTAKTeam/LXMF-rs
3. Styrene-rs - https://github.com/styrene-lab/styrene-rs
4. ferret-rns - https://github.com/kageedwards/ferret-rns
5. hyf - https://github.com/hyfmesh/hyf
6. rsReticulum - https://github.com/ratspeak/rsReticulum
7. Rust Reticulum - https://jirijakes.com/code/rust-reticulum
8. reticulum-sdk - https://github.com/ReticulaLabs/reticulum-sdk
9. leviculum - https://codeberg.org/Lew_Palm/Leviculum
10. rns-rs - https://github.com/lelloman/rns-rs

• this one, and there is probably more I haven't found yet.

Some people are putting in so much effort to hide their usage of LLMs.

You should definitely be apprehensive about the cryptography implementation in any project that relies on it, this one included.

But to be very clear here, I'm not doing anything novel at the primitive layer. It's not like I'm out here writing curve math by hand or something (and I'm sure as hell not having an LLM do it). Prns uses x25519-dalek and ed25519-dalek, which are highly vetted public implementations used by all sorts of respected projects in the Rust ecosystem. For example, they're the same core cryptography crates that the Tor project uses in its low level crypto module in Arti, as well as Signal's libsignal. Similar story for aes, cbc, hmac, sha2, and hkdf. Those are all from the venerable RustCrypto crates.

This project is very young and no system is perfect, but it is an outright misrepresentation if anyone reading this thread walks away thinking Prns is built on vibecoded crypto primitives.

CarL_PetErson wrote:

I imagine it would run smoothly on OpenWRT routers with limited resources right?

I have every reason to believe so, and will find out soon! I have a heltec HaLoW dongle waiting for me here on my desk, which is OpenWrt-based. Been itching to get to it!

Also looking forward to test how the upgraded AutoInterface features fare on batman adv meshes that got some multicast filtering. Those features only work prns <-> prns right?

I'd have to familiarize myself more with batman-adv before I could speak to it at all, but the other rendezvous mechanisms are just Prns <-> Prns right now, yes (normal Autowifi via UDP multicast like in stock RNS is interoperable RNS <-> Prns though, just to be clear).

Would love to hear what findings you run into as you explore this more too. It's definitely not the first time I've heard of batman-adv so I bet others are already wondering the same thing.

It's also capable of running standalone nodes on a nRF52840? microRNS hit some roadblocks with very limited path storage on that one, how is prns doing?

Yep! The LilyGo T-Echo runs on an nRF52840. Others running on nRF52840 will still need their board-specific details wired up (I'm starting on the heltec T096 right now, for example). But the chip itself (and the vast majority of the work) is confirmed running the Hopspot firmware with BLE-auto, LoRa (with the seemingly-ubiquitous sx1262), and USB-auto interfaces, including reading a nomadnet page off of it on a nearby computer, and also while acting as a transport node between a Linux laptop and a Mac mini each sending messages and files to each other over nomadnet.

The constrained size on embedded is definitely limiting. Main three ways it's currently mitigated:

• using recursive path requests by default
• fighting very hard to keep the data representations as compact as I possibly can
• and making sure that adjusting the sizing of different parts of the engine are easy knobs to turn, so that it's both easy to adjust toward better defaults as we learn more, and easy for someone to configure for their own builds to handle their special cases.

So for example one could greatly reduce resource/channel buffers since they don't expect to directly talk to that node in a way that really needs those, freeing up more room for tracking destinations for transport. Or go opposite, if the board was meant to largely exist to serve a small page or something, you might instead bump up the # of max active link sessions and accept fewer tracked transport destinations.

But this is an ongoing effort open to more insight and contribution! The defaults are almost certainly not yet ideal. Right now it simply needs more eyeballs and reports from practical use cases and needs. The important part is that changing them is mostly a simple matter of flipping a few const values or type parameters while making sure the new aggregate size still fits in the budget.

By no means do I consider this part mature, but it does indeed have thoughtful first legs.

Also: Are you planning to add a SocksInterface for easy usage of Tor in the future?

This wasn't on my radar for the near future, but definitely open to it. Best place to start is to open a discussion on GitHub beacause others are probably also right there with you on wanting this, and I think the end result would be better for it.

Thanks for all the thoughtful questions!

Also just a quick update for bergie: I now have the ws compatibility tracked as issue #97, and as far as I can tell right now it should be something I can start this week.

But to be very clear here, I'm not doing anything novel at the primitive layer. It's not like I'm out here writing curve math by hand or something (and I'm sure as hell not having an LLM do it). Prns uses x25519-dalek and ed25519-dalek, which are highly vetted public implementations used by all sorts of respected projects in the Rust ecosystem. For example, they're the same core cryptography crates that the Tor project uses in its low level crypto module in Arti, as well as Signal's libsignal. Similar story for aes, cbc, hmac, sha2, and hkdf. Those are all from the venerable RustCrypto crates.

I never said that was the issue.

Primitives and protocols are not the same. They are called "primitives" for a reason. Primitives are the building blocks used to design protocols that let us do secure encryption over a channel.

The byte level operations of an Ed25519 implementation could be perfectly sound, yet how it's implemented might not be. This is why things like the Noise protocol exists.

When I say "roll your own crypto" I am not referring to actually writing an Ed25519 implementation based on the RFC yourself. I am talking about the order of operations in which these primitives are used which defines our protocol

This is much harder said than done, and it's often a great way to shoot yourself in the foot. Multiply this by 100x when you are working entirely in a black box.

You don't understand the code. You don't know what it's doing. You can't even tell it "no, don't do that" because you don't have any ground truth or reference. And neither does the LLM. It spits out the statistical median for the next word in a sentence. That's what LLMs do.

This is just one reason out of a thousand not to use a 100% nonsensically vibecoded port of Reticulum where there is no human in the loop who can do anything but trust the output of what Claude says.

You are also outsourcing every facet of development, design, and decision making from now until perpetuity to a model you don't control, on some highly centralized corporate third party software as a service provider, whos output you don't even understand. If the model didn't exist your project wouldn't. Does that sound like digital sovereignty to you?

I should not have to explain this over and over again to people. I am sick of the Reddit techbro manchild archetype shitting this project up, which will inevitably fracture it until the value Reticulum had is meaningless.

This forum is a forum for Reticulum. It's not a hugbox for your digital equivalent of macaroni art powered by Claude ™️. I don't have to congratulate you or be cordial with you when what you are doing amounts to usurping the entire project. We are now on the dozenth Rust port, half vibecoded, 90% barely working.

Nothing you did couldn't have been achieved with what already exists. Even if you just wanted to prooompt all day you could have contributed to something that already exists.

If you argument is "look at this ecosystem toolkit harness .MD that says its 86x more faster than the Python version" "faster" as a quantifier of what? Even if this is true (it may be, but that is meaningless) weigh the fact the entire project is LITERALLY SPAT OUT FROM A BLACK BOX, WITH NO ONE UNDERSTANDING WHY OR HOW IT WORKS.

I'm no Freud, but there is some arrested development manchild shit going on here. Talking to vibecode sloperators is all the same. I should not have to explain something that is this much of common sense to you. Or anyone.

I will leave your post up but I discourage anyone from using this. I can't stop you from doing it, but this is a absolute disaster. Do not use this.

I think your words are falling on deaf ears, Zenith. I don't think any of the slop creators really understand either what you wrote, or where they stand psychologically. This is not about Reticulum, it will be the same in any other project or app. It is about complex compensation, like getting a big car to compensate for low self esteem. And instead AI making them whole, more powerful, truly meaningful, better selves, it makes them weaker and weaker, shining their inabilities and shortcomings more and more brightly. This is, after all, the purpose of the publicly available AI - to weaken mankind and give it a false sense of value. It works very well, this trojan horse, on the weak minded. Only people that actually have true value, be it talent or hard earned understanding and capability, will be empowered by AI, I suppose one locally fostered, hosted and ran. All else will just be more and more shit, worthless junk and dilution of quality. I second this - please, do not use this crap. It is crap.

aetherlab wrote:

I think your words are falling on deaf ears, Zenith. I don't think any of the slop creators really understand either what you wrote, or where they stand psychologically. This is not about Reticulum, it will be the same in any other project or app. It is about complex compensation, like getting a big car to compensate for low self esteem. And instead AI making them whole, more powerful, truly meaningful, better selves, it makes them weaker and weaker, shining their inabilities and shortcomings more and more brightly. This is, after all, the purpose of the publicly available AI - to weaken mankind and give it a false sense of value. It works very well, this trojan horse, on the weak minded. Only people that actually have true value, be it talent or hard earned understanding and capability, will be empowered by AI, I suppose one locally fostered, hosted and ran. All else will just be more and more shit, worthless junk and dilution of quality. I second this - please, do not use this crap. It is crap.

Yeah. We live in interesting times, for sure.

Something I forgot to include in my rant is you are discarding work by other members of the community when you do this. microReticulum, developed over the last two years ships firmware that could run on any type of ESP32 or microcontroller you could ever want.

I have worked with it extensively and it is great, fully operational with the reference implementation with very few hiccups. I literally have a solar powered ESP32-S3 sitting in a little junction box with a 10 watt solar panel running a Nomad node right now.

Hell you could have just pointed Claude at that.

The inevitable outcome of all of this, besides the unmaintainable slop mountain and slop ouroboros, is fragmentation.

"ChatGPT go add post quantum security and multicast. Also make it gooder. No mistakes".

Now what do you have? Something that isn't compatible with the wire or existing protocol. Even slight divergences in the Transport logic can break the entire network, and my guess one of the contributors to why the public network was so broken prior to interface gravity changes.

LLMs almost never say no or push back on things that aren't good ideas btw. It is also amazing at lying. Either you, or the model, can lead you down spirals which it self-reinforces through whatever context you have.

The first commit to Prns was b0e1b2d, on May 26, 2026

Today is August 11th, 2026

There are 2,234 commits, representing 204 commits a week. 30 commits a day. That is almost the total number of commits to the entire Python reference implementation which's first commit was on 9a9630c on May 29th, 2016.

There are TWO THOUSAND FIVE HUNDRED AND TWENTY SEVEN files tracked in the master branch

There are 1500 files with the .rs extension non-withstanding things like dependencies or submodules. Running
`git ls-files | grep -E '.(rs)$' gives you https://pastebin.com/FKaHkWrJ

git ls-files -z '*.rs' | grep -zZv -e '^vendor/' -e '/vendor/' | xargs -0 cat | wc -m
Just looking at the character counts alone of all files with the .rs extension there are 12,642,864 characters. If you typed at 100 words per minute, for every day straight that would take 20 days.

For files tagged with .md, there are 926,249 characters total.

Character count's aren't an estimate of much, but for not even two months, do you realize how insane this is?

Do you even have any background in Rust development? There are probably entire segments of this repo you haven't even looked at. It's not humanly possible.

You could fit the entirety of the KJV Bible from Project Gutenberg with 3,566,480 characters including spaces 3.9x in just the total character count of whats tracked with .rs extensions excluding anything in a vendor/ folder. You could fit War and Peace in 4.1 times

The initial README is also just strange, full of some of the most bizarre suggestions which probably hints at what your typical Claude conversation looked like when prooooompting Claude.

This line stood out to me the most though https://github.com/KenAKAFrosty/Prns/blob/b0e1b2d73eb2cc9b4eb547eb9a6030d43ae81cdd/docs/build-ethos.md

That distinction draws our scope line. Link, Resource, Channel, Buffer are application-facing surfaces — an app opens a link and sends a resource; the daemon only transports the packets. So a piece of library surface earns its place in the codebase only if:

    daemon behavior needs it, or
    a named SDK consumer ships it.

If neither is true, it is reference material, not code we carry. When in doubt, name the consumer out loud. If you can't, you have your answer.

Between those two boundaries, the model is yours. Clean, typed, idiomatic Rust. It owes the reference nothing — not its names, not its function breakdown, not its types.

Yeah, just ignore all that. Why not? It's the build ethos ecosystem harness or whatever, my eyes can only glaze over this shit so much.

Followed by what I can't even decipher:

 The shape: a game engine

The core is a pure tick:

tick(&mut State, Input, dt) -> Effects

No I/O, no clock reading, no syscalls inside the core. Time is an argument. Inbound is data. Outbound is data — typed Effects that the surrounding loop interprets, not calls the core makes itself.

This is not exotic. It is the same attractor that Elm/Redux, deterministic lockstep netcode, ECS game loops, and embedded superloops all evolve toward independently. A pure function of (state, input, time) is the most testable and most portable object there is. Arriving at this shape is a sign the decomposition is natural, not forced.

This is some type of eldritch abomination.

This is Claude wanking quietly in the early hours... :D

Anonymous wrote:

Rust implementations:

1. Beechat Reticulum-rs - https://github.com/BeechatNetworkSystemsLtd/Reticulum-rs
2. LXMF-rs - https://github.com/FreeTAKTeam/LXMF-rs
3. Styrene-rs - https://github.com/styrene-lab/styrene-rs
4. ferret-rns - https://github.com/kageedwards/ferret-rns
5. hyf - https://github.com/hyfmesh/hyf
6. rsReticulum - https://github.com/ratspeak/rsReticulum
7. Rust Reticulum - https://jirijakes.com/code/rust-reticulum
8. reticulum-sdk - https://github.com/ReticulaLabs/reticulum-sdk
9. leviculum - https://codeberg.org/Lew_Palm/Leviculum
10. rns-rs - https://github.com/lelloman/rns-rs

• this one, and there is probably more I haven't found yet.

Some people are putting in so much effort to hide their usage of LLMs.

Despite all the shit going on in this thread, and that I might also comment later, thanks for the list.
I still find it interesting to Look through.

Anonymous wrote:

Some people are putting in so much effort to hide their usage of LLMs.

It's interesting that people go to great lengths to hide their good friend Claude when it's so obvious that the project was vibecoded. Are they ashamed? Afraid people won't touch it if they find out, hoping they won't?

I respect that Ken is upfront about it, so people can make an informed decision. It ultimately comes down to people's good(/bad) judgment. The skill of discernment has never been more important in tech.

(I had no idea there were 10+ Rust implementations, ~80% of which are vibe coded. That's crazy!)

If you are not happy with vibecoded RNS implementations, don’t use them. It is as easy as that. I really don’t understand the hate here.

In my opinion, agent-based coding is what gave RNS a chance, since having alternative implementations that are suitable for running in diverse environments was nearly impossible to develop from the ground up before – at least without having serious funding to pay a whole team. And alternatives to the Python-only reference are definitely needed, I think this is something we can all agree on. So basically AI is what sparked the recent community growth, that I have a feeling not everybody is happy about. But at the end of the day, RNS is a mesh protocol; its power scales directly with its node count, which inherently relies on growing the user base. Compared to projects like Meshtastic or MeshCore, RNS still demands too heavy a technical commitment to truly open up to a broader, non-technical audience. Because of that steep barrier to entry, the arguments made in the blog post "Killing Reticulum to Save It" actually ring quite true.

Regarding Leviculum: I have to defend it. I have used it for a while now and it works for me (with a few hiccups, but these also occur in microReticulum and even in the reference implementation).
And the most important thing: I really think that it is completely unnecessary to insult anyone. As Lew said, a productive community needs a respectful tone and constructive criticism. I just don’t get the hate.

I don’t know about everyone else, but I would rather have 10 vibecoded Rust implementations than zero purely human-developed ones. Even though, of course, joakim has a point that it’s unfortunate to have more duplication of efforts and less collaboration. However, that is not something that is caused exclusively by vibecoding. Of course, there are pretty bad implementations out there, and the majority might be vibecoded, but who cares. In the end these implementations won’t be used and will not survive for long. Ultimately, the success of these projects comes down to how effectively the AI is guided, which is rapidly proving to be an entirely new skill of its own.

For my part, I am excited to have a look at the Prns project! And time will tell if this is something that sticks.

nilu96 wrote:

If you are not happy with vibecoded RNS implementations, don’t use them. It is as easy as that. I really don’t understand the hate here.

Being implementations of a mesh networking protocol, they end up causing issues on the network for everybody.

In my opinion, agent-based coding is what gave RNS a chance, since having alternative implementations that are suitable for running in diverse environments was nearly impossible to develop from the ground up before – at least without having serious funding to pay a whole team.

Ivan begs to differ. Reticulum-Go is the most mature port of RNS so far. He does use AI for non-critical tasks, but it's intelligent use of AI (132f67e79d9b24aad014e93015fb858f:/page/repo.mu`g=public|r=Reticulum-Go|anchor=ai-disclaimer), not vibecoded. And it shows on the timeline of commits and the quality of the implementation.

Atterman begs to differ. AFAICT, microReticulum is the most stable and conforming implementation for microcontrollers.

But at the end of the day, RNS is a mesh protocol; its power scales directly with its node count, which inherently relies on growing the user base.

Growth and power are not things we should strive for. IMO, slow growth is a virtue. Quality over quantity. Also relevant: This is not a teahouse (a8d24177d946de4f1f0a0fe1af9a1338:/page/work_doc.mu`g=reticulum|r=reticulum|id=4)

And the most important thing: I really think that it is completely unnecessary to insult anyone. As Lew said, a productive community needs a respectful tone and constructive criticism.

I agree.

I don’t know about everyone else, but I would rather have 10 vibecoded Rust implementations than zero purely human-developed ones.

False dichotomy.

Of course, there are pretty bad implementations out there, and the majority might be vibecoded, but who cares.

I do care that there are so many shitty implementations of Reticulum out there. It hurts the network and it hurts Reticulum's reputation. I'd rather have a handful of hand-written implementations than the slopfest that we have now, even if it took years instead of days. More ≠ better.

Zenith, at this point your replies are just disingenuous to anyone who reads this thread.

Zenith wrote:

I never said that was the issue.

Yes, you did. Your words:

Zenith wrote:

Most human people should not be touching cryptographic primitives, let alone an LLM.

The point you later pivoted to (it's how the primitives are used) is a valid one which I'll address in a moment.

Zenith wrote:

Do you even have any background in Rust development?

Yes, that's why I chose it.

Zenith wrote:

This forum is a forum for Reticulum.

Yeah I'd love that. That's what I'm trying actively to engage in, despite your foaming at the mouth about AI usage.

So for fuck's sake, let's talk about Reticulum.

Under all the ranting, the only major technical thing you actually spoke to was this

Zenith wrote:

I am talking about the order of operations in which these primitives are used which defines our protocol

That's also the kind of discussion that a community of enthusiasts would probably be interested in and benefit from anyway, right? So let's discuss.

What are the specific Reticulum crypto operations that you believe Prns is misassembling?

• Key splitting? First half is signing, second half is encryption
• Mode select? With a 32 byte key AES-128-CBC is selected; 64 byte key, AES-256-CBC
• Layout? Prns also follws the iv(16) || CBC(PKCS7(pt)) || HMAC(32) layout
• MAC coverage? It's HMAC over iv || ciphertext
• Order? Prns does encrypt-then-MAC, and verify MAC before decrypt
• Padding? PKCS7, always pads
• MAC comparison? Okay yeah I guess we do diverge here. Prns uses a constant-time verify while the reference uses Python's == comparison. But obviously that was intentional to be strictly safer.

If not about token construction, then maybe Identity encryption?

• DH target? ephemeral X25519 private key against the recipient identity's public key (or ratchet)
• Key derivation? HKDF-SHA256, 64-byte output. The salt is recipiient's identity hash, empty context
• The ratchet subtlety maybe? Prns is the same here too. encrypting to a ratchet, only DH target changes. HKDF salt stays the identity hash
• Layout? also same as the reference, ephemeral_pub(32) || token

Link establishment?

• link_id? truncated sha-256 of the link request's hashable part (with MTU signalling bytes trimmed off first). same as reference
• Session key? HKDF-SHA256 over the ECDH shared secret. salt is link_id, empty context. 64B ooutput for the AES-256 mode the reference defaults to
• the proof? responder signs link_id || its encryption pub || its signing pub || signalling bytes with its Ed25519 identity key. initiator validates that against destination's identity
• Per-message crypto? session-key token per packet, same token construction as above, same as the reference

Announce signing?

• Signed data? destination_hash || publc key || name_hash || random_hash || ratchet (when present) || app_data
• random_hash? 10-byte field that's actually 5 random bytes plus 5 time-derived bytes.
• Ratchet field? Same optional 32byte field in the same position (after random_hash, before the signature). covered by the signature

Or perhaps packet hashing?

• hashable part? flags byte masked to its low nibble, hops byte skpped, and for HEADER_2 packets the 16-byte transport ID is skipped too.
• packet hash itself? full 32-byte sha256 of the hashable part; where a truncated packet hash is required, first 16 bytes
• proofs? signature covers full 32-byte packet hash. explicit is 32 byte packet hash plus 64 byte signature, implicit is the signature alone.

Derivations?

• public identity? X25519_pub(32) || Ed25519_pub(32)
• identity hash? first 16 bytes of sha-256(public identity)
• name hash? it's the first 10 bytes of sha256(expanded_dotted_name_utf8)
• SINGLE destination hash? first 16 bytes of sha256(name_hash || identity_hash). PLAIN detinations are the same but without the identity hash

None of this even has to be my word against yours, by the way. It shouldn't be. The validation suite litearlly runs stock RNS 1.4.2 as a live oracle. Prns encrypts and the reference implementation decrypts, and vice-versa. All of that across message sizes from empty through block boundaries to MDU, plus a matrix of corrupted and truncated tokens both sides must reject.

Let alone the part where all the code is public. Anyone can go verify it for themselves and draw their own conclusions.

(Side note: Issues/PRs/reports about any of these kinds of things being incorrect are highly appreciated and taken very seriously. I really care, and I want this to be good)

Anyway, these are the kinds of technical discussions I looked forward to, which is why I posted here in the first place. I hope that we can all continue to have them.

KenAKAFrosty wrote:

Zenith, at this point your replies are just disingenuous to anyone who reads this thread.

Just speak for youself, would you? No one authorized you to speak for "anyone".

Anyway, these are the kinds of technical discussions I looked forward to, which is why I posted here in the first place. I hope that we can all continue to have them.

Do you honestly expect living breathing humans to go elbow-deep into this piece of slop and provide feedback so you can feed it to the LLM once more so it can churn out more cruft?

Yes, this forum is for Reticulum. This contraption is anything but Reticulum.

I second Nickie on both points!
I find Zenith's replies very on point and your will to push your crap mutant slop onto the community as some kind of blessing, that commands everyone's attention and absolutely should engage them into bathing in your crap and trying to understand what the hell Claude wanked about truly vomit inducing. Why don't you stop for a second and consider yourself at fault for once? Why don't you step out of your path and at least exercise the notion, that we might be right?! No, you prefer to childishly insist on...

joakim wrote:

Growth and power are not things we should strive for. IMO, slow growth is a virtue. Quality over quantity.

I'd rather have a handful of hand-written implementations than the slopfest that we have now, even if it took years instead of days. More ≠ better.

I agree that quality of quantity is a good idea. I agree with Mark's sentiment that if you're touching networking code that's going to used by millions of people that "you better fucking know what you're doing" (paraphrased)

I do however worry about the quick rise of AI backed authoritarianism that we may only have a shrinking window of opportunity to build and implement a large scale Reticulum network before its not possible anymore. I worry that we might all be letting perfect be the enemy of good. I worry that with the sentiment of "even if it took years rather than days" it could result in Reticulum becoming the next Gnu/Hurd; interesting technology that's always being worked on but never actually being released in any meaningful capacity.

I understand that there is an inherent cognitive dissonance between those two thoughts that I don't know how to reconcile.

I do however think that while it's important to keep code quality high, insulting people doesn't make for a welcoming community nor fosters cooperation. If we just constantly gatekeep people and gain a reputation that the Reticulum community is toxic, it will push people away and the project will stagnate.

That leads to my next point: wtf is the point of building a tool like Reticulum if no-one actually uses it? Isn't people actually using it the central point, or is Reticulum just our fun little toy to theorize and debate about just to tickle our 'tisms for our own amusement?

Professor_Boop wrote:

That leads to my next point: wtf is the point of building a tool like Reticulum if no-one actually uses it?

I think there's two ways to look at Reticulum: one is a global mesh network, and the other is a local, personal one. My perspective is more from the latter side, as we spend most of our time without internet uplink in remote locations where there aren't many we could mesh with. At most I've seen 3 other boats with Meshtastic in the same atoll as us.

In this scenario, Reticulum is useful as long as it allows us to do things. I can interact with out boat's rngit repositories over LoRa from the beach. The collaborative editing tools I'm developing can similarly sync state over the boat WiFi, or over LoRa, or even internet when that's available.

Basically everything we do with Reticulum works without anybody else in the mesh, though they'll work even better when there are others: possible LoRa transport nodes in places we sail, internet-based store-and-forward messaging nodes for when we have uplink. And of course if Reticulum is more popular, we have the possibility of collaborating and talking over it with people outside of the boat and crew.

First we worry about Reticulum working well within the sphere we can influence (by deploying a higher-up transport node on the boat, building more software we need), and only then about whether it works in a wider context.

There's of course the classical (and likely not fully correct) "given enough eyeballs, all bugs are shallow" aspect. If Reticulum is popular, people will find and fix problems. And there will be more apps than just the things we build for ourselves.

That all said, it wouldn't hurt to have a more polite discussion culture here. But then again this is the Internet ¯\_(ツ)_/¯