Reticulum Outgrew Its Creator, and That's the Point

Reticulum keeps landing on Hacker News front pages, and the pitch explains why: a networking stack where addresses are cryptographic hashes instead of IPs, every link is end-to-end encrypted with forward secrecy by design (you literally cannot send an unencrypted packet), and the whole thing runs over anything that moves bits — LoRa radios, packet radio TNCs, serial lines, TCP tunnels, I2P — down to links as slow as 5 bits per second. No DHCP, no DNS, no certificate authorities, no ICANN. It's pitched as an alternative to socket.h, not another VPN or overlay.

But if you're evaluating Reticulum in mid-2026, the protocol design is the settled part. The open question is everything around it — because over the last eighteen months, Reticulum became a live case study in what "sovereign networking" means when the sovereign is one person.

What the design actually gets right

Most "decentralized networking" projects are either apps wearing a protocol costume or overlays that quietly assume the internet underneath. Meshtastic is a terrific LoRa messaging app, but it's an app: flood-routed, capped hop counts, no general transport for your own software. Yggdrasil and cjdns build encrypted IPv6 overlays, which is useful precisely because it keeps IP semantics — and limiting for the same reason, since IP semantics assume link capacities that a 1,200-baud packet radio channel will never offer. Tor gives you anonymity but requires the internet to exist.

Reticulum is the rare project that rethought the layer itself. Identities are Ed25519/X25519 keypairs; destinations are hashes of public keys, so addressing is self-issued and portable across networks. Packets carry no source address. Routing self-configures across multi-hop topologies without a coordinator. Because the stack was designed for the worst link first, the same application code runs over a gigabit Ethernet segment and a solar-powered LoRa node on a hilltop. That's a genuinely different contract than TCP/IP offers, and nothing else in the space provides it as a general-purpose library you can pip install rns and build against today, with a working application ecosystem (LXMF messaging, the Sideband and MeshChat clients, NomadNet) already on top.

Then 2025 happened

Reticulum was always effectively one person: Mark Qvist, who spent roughly a decade building the stack, the LXMF messaging layer, the RNode radio firmware, and most of the apps. In April 2025 he changed the reference implementation's license from MIT to a custom "Reticulum License" with anti-AI and no-harm clauses — well-intentioned, but it made the package undistributable in Debian, F-Droid, and Alpine's main repos, and ineligible for most open-source funding. RNS 1.0.0 shipped that fall. Then in December 2025 came what Qvist called a "carrier switch": he withdrew from public engagement entirely. The issue tracker was hidden — years of technical discussion gone — pull requests and support channels closed, documentation frozen. His parting statement: "If you want Reticulum to continue evolving, you have the power to make that happen. The protocol is public domain. The code is open source. Everything you need is right here."

Here's the strange part: development didn't stop. Releases kept flowing through 2026 — RNS 1.4.2 landed in late July with dynamic path re-balancing and CPU optimizations. The code ships; the conversation doesn't. It's cathedral-style development taken to its logical extreme, and it forces a question most open-source consumers never confront: is a project "maintained" if you can't report a bug to it?

The community's answer is the interesting part

The community that gathered at FOSDEM in February 2026 didn't fork-and-flame. It did something smarter: it treated the public-domain protocol as the asset and the Python code as one replaceable implementation. There's now RetiNet, an AGPL community fork of the pre-license-change code with an open contribution model; Beechat's Reticulum-rs in Rust, whose rnsd-rs transport daemon reportedly runs the same workload at under 4% sustained CPU where the Python daemon spikes to 20–100%; microReticulum in C++ targeting ESP32 and nRF52 so radio nodes won't need a tethered host; a Go implementation compiling to WASM; and Columba, a native Android client with LXMF messaging and Codec2 voice calls. Wire compatibility is the shared goal, and mundane interop work — like converting RNS's almost-TOML configobj format into actual TOML — is where the effort is going.

That's the same move that made TCP/IP durable: the spec outlives any codebase. Twelve months ago, Reticulum's bus factor was one. Now it's a protocol with five implementations in flight. The December withdrawal, painful as it was, may end up being the healthiest thing that ever happened to the project.

Should you build on it?

Depends entirely on which tier you're playing in.

For off-grid messaging, emergency comms, community networks, and resilience projects: yes, now. The stack is genuinely usable — pip install rns, wire up interfaces in ~/.reticulum/config, flash RNode firmware onto an off-the-shelf LoRa board, and you have encrypted multi-hop comms with no infrastructure. This is the best tooling that exists for the job.

For production products: not yet, with specific reasons. The reference implementation has had no external security audit, and the maintainer you'd escalate a vulnerability to doesn't answer. The custom license is a legal-review headache and blocks the packaging channels enterprises rely on (RetiNet exists partly to fix this). Python's per-packet overhead is real on constrained transport nodes until the Rust implementation matures. If you transmit on amateur bands, encrypted traffic is illegal in most jurisdictions, which confines radio deployments to ISM-band hardware like LoRa. And temper the "unstoppable network" framing: deployed Reticulum meshes today are hobbyist-scale, orders of magnitude smaller than Meshtastic's install base, and the anonymity story is "no source addresses," not Tor-grade traffic analysis resistance.

The pragmatic play for developers: prototype against the Python RNS now, pin your versions, keep your application logic on LXMF or the Link API rather than implementation internals, and watch Reticulum-rs and RetiNet — the moment a second implementation passes full interop, the single-maintainer risk mostly evaporates. The protocol has already proven it can survive its network links going down. In 2026 it's proving it can survive its creator logging off, which for infrastructure software is the harder test — and so far, it's passing.