rns.recipes

Hey y'all! For a good while now I've been heads-down building a ground-up implementation of Reticulum that can run everywhere, and it's finally at the point where I get to share it. Prns is now public, dual-licensed under MIT or Apache 2.0!

The core engine was written in no_std Rust (alloc isn't even needed) from day one, with the express goal being to have the same engine efficiently run on a $5 microcontroller, in a browser tab over WebAssembly, inside Android and iOS apps natively, and on laptops/backbone servers/etc.

Here are some of my favorite bits, in no particular order:

• A zero-config Bluetooth auto-interface, with a compat layer so Columba peers connect too
• WebSocket interfaces. Not only great for browser integrations on the other end, but since it's ordinary web traffic, a free tunnel (cloudflare tunnel, Tailscale funnel, etc.) gets you a public node from home without the port forwarding or IP exposure.
• JavaScript/TypeScript/browser support as a first-class thing. One package that runs native on Node.js/Bun and switches to WebAssembly in the browser. A browser instance can even discover another prnsd (the Prns daemon) on your LAN with its implementation of the Wifi auto-interface.
• Interface changes will apply live to a running node without a restart. The daemon has an interactive/guided CLI (even while running). Plus a lil system tray; handy to have when running it on your personal computers!
• Flashing a board into a complete, self-contained Reticulum node with the Hopspot firmware. There's a web flasher & a guided flasher CLI. A few known boards are live already, and plenty more in the immediate sights.

And it's very efficient. The repo ships a benchmark harness that runs Prns and stock RNS side by side on your machine, under identical workloads. On my hardware, most throughput scenarios land between 3× and 20× stock, with peaks of 89× the throughput, 48× smaller peak memory, and 33× the energy efficiency. But the whole point of the harness is that you can get your own numbers, and I'd rather you trust those.

Where it all stands today: the foundation is done and verifiable. It was continually built up with a serious focus on safety, performance, energy efficiency, compatibility, and developer/user experience. On top of the expected unit tests, the testing & validation suites include wire parity, live interop, formal proofs (via Kani), fuzzing, and mutation testing, along with matching CI.

While documentation is definitely still a work in progress (as is the entire repo), the guides will take you from clone to two meshing nodes today. What's also still taking shape is the outward-facing layer, e.g., SDK ergonomics in each language; packaging; the guides as fresh eyes read them. That's why I'm posting now rather than after another month of quiet polish. Feedback on those pieces steers them while they can still best be steered, and honestly, a few days of you all reading and building will teach me more than that month alone would. (PS: if you've done devrel or docs work, your experience could especially help here.)

None of this exists without the years of work behind Reticulum and its reference implementation. What I want most is for this to pull more builders into the ecosystem we already share. I'm excited about a future where we see more apps, more boards, and more nodes meshing. In part just cuz I still think it's freaking cool, but also because every one of them strengthens the same network we're all on.

If you're willing and able to help out, there's plenty of need! Even the small things help a ton. Here's a list of things already top-of-mind that would be helpful:

• Try it and tell me how it went. Friction and breakage reports are gold
• Build something small and tell me what the API made easy or awkward
• If one of the preview languages is home for you, opinions on its API and packaging are the most helpful thing there is right now (and if your language is missing but can consume a C ABI, give a holler or a PR!)
• Board reports beyond what I have on deck (Heltec V4, T-Beam Supreme, T-Echo, XIAO ESP32-C6 live now, plus all the ones you see on the website under 'Bring-up')
• Examples we can link to; guides for individual interfaces (they're little programs unto themselves; heck, even just explaining one well is immensely helpful)
• Translations! The website has some basic i18n but those translations were AI-written and could use a look from actual native speakers. Eventually, I'd love to have the actual full-on guides available in as many languages as possible too.
• Game devs: Godot is where I've been proving things out already, and other engines are wide open and very welcome
• Help getting prnsd into apt and friends
• Tell me what you'd want to build with it. Real use cases can help inform priorities
• And if Prns is useful or just interesting at all to you, a GitHub star helps too!

On AI Usage: I certainly use AI tooling as a part of my workflow. If you do as well, your contributions are welcome on Prns, but only if you truly digest and respect the first item in the CONTRIBUTING.md guide, under "What we value":

Ownership. Contributors own their submissions.
AI tools (and other assistance like pair programming, web snippets, etc.) are welcome, but slop is slop regardless of how it was produced.
How you wield your tools is still under your control, and what you submit is yours.

Everything's in the source, including the interop suite and the benchmark harness, available on GitHub.

Quick overview + web flasher + small browser demo/playground at prns.dev.

I can't wait to see what y'all build!

[Note for the admin] Hey Zenith, I believe this project honors the spirit of your guidelines for projects built with the use of AI tools, even though it doesn't yet meet the age threshold. If you see it differently, just reply here to let me know, and of course feel free to remove the thread. Thanks!

Having more systems with WebSocket interface is great, as that enables browser applications to play a part. After all, web apps are one of the last "permissionless" ways to distribute software for the Major platforms.

Have you verified your WebSockets interface works with the Python and reticulum-js (and microReticulum_Firmware) ones? Are you using HLDC or KISS?

i wouldnt pick that name if i were you

Looking forward to the Heltec T114 build to test out

Yay! yet another AI Rust implementation.

Good to see the repo at last :)
...but wow, it's massive, that is gonna take a while to even crossread. Thanks in any way for sharing the link.

Zenith wrote:

Why does this not mirror anything from the Python reference implementation at all? There isn't even anything that remotely resembles a Destination

Why is announcing a "command"? and not a method?

 handle.issue(PrnsCommand::AnnounceNow(AnnounceNow { destination, target, app_data }))

Nevermind the fact this is the millionth purely vibecoded LLM Rust port monorepo Sloppulus that is DoA, I have no idea why, even if you were just prompting an AI, would make these decisions. There is no reason to. Why not just mirror what already existed? The Go port and microReticulum do this just fine.

Not defending this particular line of Code, but I think there are good reasons to deviate frome the python source, especially with some kind of embedded-first approach. Lots of stuff is simply not doable the way python handles it.
That being said, idk how microReticulum solved these particular challenges. C++ is just not easy digestable to me.

This is just the consequence of no spec and the emergence of LLMs attracts low-effort people to churn out slop implementations and software. The ones that matter are a year old, still maintained and work with the reference implementation not against it.

Having 10+ Rust implementations, more than half either vibe coded or heavily AI assisted is honestly embarrassing and fractures the community.

Time will tell which implementations actually survive.

Great work, KenAKAFrosty!

High performance is great and trying to get it working with apt is really cool and interesting.

I appreciate your excitement and initiative regarding the vision of making a high performance Reticulum implementation. I am eager to see its continued development and support.

Anonymous wrote:

This is just the consequence of no spec and the emergence of LLMs attracts low-effort people to churn out slop implementations and software. The ones that matter are a year old, still maintained and work with the reference implementation not against it.

Having 10+ Rust implementations, more than half either vibe coded or heavily AI assisted is honestly embarrassing and fractures the community.

Time will tell which implementations actually survive.

isn't the point of different implementations that they're wire compatible? otherwise it's a different thing, no?

Sojourner wrote:

isn't the point of different implementations that they're wire compatible? otherwise it's a different thing, no?

In theory, yes. But of course given the lack of a formal spec and compatibility test suite, the actual level of wire compatibility will differ, and likely lean towards the particular use cases implementation author had in mind (for example, my JS implementation doesn't support being a transport node at all. It'll come, but is not a priority for JavaScript apps)

Woo, catching up now!

bergie wrote:

Having more systems with WebSocket interface is great, as that enables browser applications to play a part. After all, web apps are one of the last "permissionless" ways to distribute software for the Major platforms.

Have you verified your WebSockets interface works with the Python and reticulum-js (and microReticulum_Firmware) ones? Are you using HLDC or KISS?

Didn't reach for HDLC framing, or any framing here, since websockets as an abstraction already gives us framed messages. Instead I just avoided that little bit of framing overhead, since we're given that discrete message abstraction already, and set it up so one Reticulum packet was one binary websocket message.

BUT that said, if it's for the sake of compatibility with the ecosystem, I'm all for adding that compat layer! (I was just focused specifically on the reference impl only, which didn't have any websocket interface to interop with in the first place, and I wasn't aware of other established websocket impls yet). All I ask is if you can link me in here to the repo(s) so I can see the contract/protocol, etc. This is a good call-out and I'd love to interop.

Puint wrote:

Zenith wrote:
> Why does this not mirror anything from the Python reference implementation at all? There isn't even anything that remotely resembles a Destination
>
> Why is announcing a "command"? and not a method?
>
> > handle.issue(PrnsCommand::AnnounceNow(AnnounceNow { destination, target, app_data })) >
>
> Nevermind the fact this is the millionth purely vibecoded LLM Rust port monorepo Sloppulus that is DoA, I have no idea why, even if you were just prompting an AI, would make these decisions. There is no reason to. Why not just mirror what already existed? The Go port and microReticulum do this just fine.

Not defending this particular line of Code, but I think there are good reasons to deviate frome the python source, especially with some kind of embedded-first approach. Lots of stuff is simply not doable the way python handles it.
That being said, idk how microReticulum solved these particular challenges. C++ is just not easy digestable to me.

Yeah, methods are a lot hairier to deal with when you're targeting different platforms. To Zenith's concerns about the why it was designed that way:

There's no doubt its exact API is not going to look 1:1 with the reference implementation. I don't think the point of any of this is just to outright transliterate it, though, right?

It's 100% fair if typed message passing & command patterns are just not your cup of tea. I do strongly disagree with "There is no reason to", though.

An ordinary method call exists only for the instant it happens, on one stack, in one language. Commands are data. Since they're just data, commands:

• can cross a thread, CPU core, or language boundary with little friction and a stable wire/ABI representation
• can wait in a queue, where backpressure is also just a value you handle (like Busy, or Full)
• can be easily tested deterministically. The system runs heavily on just putting state + command in, getting outcome (again, just data) out. This is especially useful for property testing and fuzzing
• can funnel into a single queue for a single owner. In Prns, the engine owns its state exclusively. That setup sidesteps a large class of locks and contention slowdown. A good chunk of the both the portability and performance story comes from exactly this setup.

I promise you this is not a whimsical choice from a drunken afternoon of vibecoding or something lol.

But all that may be moot beacuse to be clear, there is indeed a handle.announce(destination) convenience method also. (This is a good sign I should probably mention that in the first example though, will add that shortly)

For what it's worth, the following examples then go on to show that method-style API too in all the other places where you do want to wait for meaningful returned data, e.g.:

let link_id = requester_handle.establish_link(responder_hash).await,

let (response, rtt) = requester_handle.request(link_id, RequestEndpointId::of(EXAMPLE_ENDPOINT_ID), message).await

Professor_Boop wrote:

Great work, KenAKAFrosty!

High performance is great and trying to get it working with apt is really cool and interesting.

I appreciate your excitement and initiative regarding the vision of making a high performance Reticulum implementation. I am eager to see its continued development and support.

Thanks, Professor!

A. Non wrote:

Looking forward to the Heltec T114 build to test out

You're already the second person to mention this board. I'll look into getting one to help get this bumped up the list! I have a T096 on my desk waiting to get brought in, but not that one yet.

Puint wrote:

Good to see the repo at last :)
...but wow, it's massive, that is gonna take a while to even crossread. Thanks in any way for sharing the link.

Yes, sorry for the wait! Thanks for the patience in the meantime haha. If you have questions as you're digging through it, keep note! That could help a lot with improving the documentation

BUT that said, if it's for the sake of compatibility with the ecosystem, I'm all for adding that compat layer! (I was just focused specifically on the reference impl only, which didn't have any websocket interface to interop with in the first place, and I wasn't aware of other established websocket impls yet). All I ask is if you can link me in here to the repo(s) so I can see the contract/protocol, etc. This is a good call-out and I'd love to interop.

• microReticulum_Firmware supports KISS-framed WebSockets
• Reticulum-js supports both HDLc and KISS framing (configurable per interface)
• For Python there's https://github.com/nilu96/rnsWebsocketInterface

bergie wrote:

> BUT that said, if it's for the sake of compatibility with the ecosystem, I'm all for adding that compat layer! (I was just focused specifically on the reference impl only, which didn't have any websocket interface to interop with in the first place, and I wasn't aware of other established websocket impls yet). All I ask is if you can link me in here to the repo(s) so I can see the contract/protocol, etc. This is a good call-out and I'd love to interop.

• microReticulum_Firmware supports KISS-framed WebSockets
• Reticulum-js supports both HDLc and KISS framing (configurable per interface)
• For Python there's https://github.com/nilu96/rnsWebsocketInterface

Sick, thanks, I've got this on my short list now

I kind of get the mixed reactions, it does sound too good to be true :D

But I sure hope it is. Been looking for something like that. I imagine it would run smoothly on OpenWRT routers with limited resources right?

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?

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?

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

I mean, you could have built on top of the heavily tested Leviculum implementation, that has already a running T114 firmware and a no_std core… just to share the effort.

Lew wrote:

I mean, you could have built on top of the heavily tested Leviculum implementation, that has already a running T114 firmware and a no_std core… just to share the effort.

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"?

https://leviculum.network/posts/killing-reticulum-to-save-it

That's another unfortunate outcome of vibe coding, more duplication of efforts and less collaboration. There have been 7 (edit: 10+) Rust implementations so far, most of which are still active. I suppose evolution will run its course and the projects that are best maintained will remain, but it does feel like a lot of time is wasted on competition that could have been spent on collaboration. The perceived efficiency gains of vibe coding doesn't add up when you consider the whole picture, so much precious time is wasted on projects that won't make it. Not to mention the maintenance nightmare.

Call me old fashioned, but I don't trust any vibe coded Reticulum implementation to be correct anyway. It's hard enough for a human to understand the intricacies and nuances of Reticulum, let alone for a single developer relying on an LLM to understand it.

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.

joakim wrote:

That's another unfortunate outcome of vibe coding, more duplication of efforts and less collaboration. There have been 7 Rust implementations so far, 5 of which are still active. I suppose evolution will run its course and the projects that are best maintained will remain, but it does feel like a lot of time is spent on competition that could have been spent on collaboration. The perceived efficiency gains of AI don't add up when you consider the whole picture, so much precious time is wasted on projects that won't make it.

Nevermind the fact that most of them aren't even compatible with the reference implementation, even when they report "feature complete". Or are highly unstable and probably one of the reasons why the public network was so jank with constant path resolution failures up until interface gravity in the latest RNS versions.

And I'll add this on too. Reticulum's core networking properties are derived from cryptographic functions. Cryptography and LLMs are something that should NEVER touch. The worst part about Reticulum IMO is it rolls its own crypto instead of using existing RFCs or something like the Noise framework. But that is more of a tradeoff to accomplish everything it does.

You are hedging your entire bet on code you didn't produce and can't read. Let me remind everyone what Reticulum is. It's a cryptographic networking stack.

Most human people should not be touching cryptographic primitives, let alone an LLM. Small mistakes compound into huge disasters. This vibecoding bullshit doesn't just introduce a maintenance nightmare but is a flagrant security risk. (Of course, unless you prompt Claude to do it with no mistakes and to think really really really hard about it)

Also, this will all inevitability lead to fragmentation. LLMs give people the confidence to do something a skilled person can, but not the understanding or wisdom to know why it works.

Someone will get a bright idea that will break interoperability with everything else and at that point, what do you even have? Why even bother with Reticulum? Go prompt Claude to make a super duper encrypted milspec quantum secure resistant gooder mesh network. We can have 9 billion of those too.

This has been such a problem for this project. Slop after slop, it is enough to drive anyone up the wall. I have no idea why in particular Reticulum is such a target for this. Perhaps some type of naivety of people who go "Look I'm helping!" sitting at the keyboard prompting Codex or whatever.

Or some type of ulterior motive combined with a little bit of narcissism. The last person I'm familiar with who vibecoded a Rust port went and launched a scam crypto-token semi-adjacent-but-not-really related to their project that was an obvious day 1 rugpull. Just straight up scamming people using LLM laundered code.

I have no idea when enough will be enough. It is exhausting.

I shouldn't have to say these things. They should be common sense. If you turn on your fucking brain for 5 minutes and think about something you should come to this same conclusion.

But whatever. That's probably enough bitching for now. I'm disappointed in everything and frankly, I think humanity is cooked.