Introducing Prns: high-performance Reticulum, built to run on any device (and how you can help)
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
prnsdinto 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!