Node Star
Opinion · April 2026
Moving Reticulum Forward
Here's what the community is building.
Photo:
“Welcome to FOSDEM” keynote
by Thibaultmol · resized, tinted, & overlaid for this article ·
CC BY-SA 4.0
Here's what the community is building.
If you've been following the Reticulum story — the license change, the public withdrawal, the FOSDEM conversations — you already know the background. We covered it in The Man Who Built the Next Internet and Then Disappeared. That piece was about what happened. This one is about what's happening now.
The short version: a lot. More than most people realize. The Reticulum ecosystem has been expanding quietly in multiple directions at once: new language implementations, new transports, new tools that nobody planned for. The protocol is public domain. People took that seriously.
What follows is a tour of what's being built, by people who showed up and started working.
The reference implementation of Reticulum is written in Python. Python is readable and runs nearly everywhere, but it's slow, and it's particularly rough on mobile phones, small single-board computers, and anything resembling a microcontroller. The community noticed. Several teams have been building independent implementations of the same protocol in languages better suited to constrained hardware, all wire-compatible with the original, meaning a device running any of them can talk to any other without either one knowing the difference.
Two implementations are wire-compatible when they speak exactly the same protocol over the air. A node running a Rust implementation and a node running the original Python see each other as just another Reticulum peer. No translation layer, no compatibility shim. They interoperate natively.
Built by Beechat Network Systems. By early 2026, Leviculum had achieved functional completeness and confirmed wire compatibility with the Python original on real hardware. Rust's memory efficiency makes this the leading candidate for embedded targets.
Maintained by the Quad4 crew, the same team behind MeshChatX and Nomad Navigator. Go's simplicity and strong networking primitives make it a natural fit for gateway and infrastructure roles.
Targeting both operating systems and embedded devices, including WebAssembly. Zig compiles to extremely small binaries with no runtime overhead. Interesting for the most constrained hardware scenarios.
A C++ port aimed specifically at 32-bit microcontrollers. If this matures, Reticulum could run directly on the same chip inside a LoRa radio, collapsing the requirement for a separate host computer entirely.
A separate embedded-focused port by 0xSeren, targeting microcontrollers with an emphasis on real-time performance. Another path toward running Reticulum on the radio itself.
A pure MicroPython port by varna9000 that runs on ESP32-S3 and Raspberry Pi Pico W class boards. Wire-compatible with the reference implementation, with full LXMF messaging, NomadNet page serving, and direct SX1262 LoRa SPI control using RNode-compatible split-packet framing. The complete stack — crypto and all — running in Python on a $4 microcontroller.
An Elixir implementation by int32, self-described as not ready for day-to-day use. Elixir's concurrency model is interesting for high-throughput transport node scenarios. Worth watching.
None of these are production-ready replacements for the Python reference implementation today. But the direction is clear, and what's striking is how many directions there are. Rust, Go, Zig, C++, Elixir — and even Python itself, reimagined for microcontrollers — all converging on the same wire format. The community is building the foundation for Reticulum to run on hardware the reference implementation never could reach. In µReticulum's case, by way of Python itself.
If Reticulum can run on the radio itself, the barrier to deploying serious, cryptographically sound mesh infrastructure drops considerably.
Reticulum was designed from the start to be transport-agnostic, designed to run over anything that can carry bits. The community has been proving how literally that was meant. The list of supported physical media keeps growing, and some of the recent additions are genuinely surprising.
Two separate projects — ReticulumHF and FreeDVInterface by RFnexus — bring Reticulum to HF radio using FreeDV digital modes. HF propagation can cover thousands of miles with no infrastructure whatsoever. For emergency preparedness and off-grid long-haul communication, this is a significant capability. RFnexus also published a configuration guide for anyone wanting to set this up without writing code.
ble-reticulum adds a BLE interface for Reticulum with no additional hardware required on Linux devices. Your laptop or single-board computer becomes a Reticulum interface over Bluetooth. The range is short, but for local mesh scenarios where you want to avoid radio licensing, it opens options that didn't exist before.
RNS-over-HTTP tunnels Reticulum traffic inside standard HTTP/S POST requests. This means Reticulum can operate on networks where only web traffic is permitted, passing through firewalls, captive portals, and deep packet inspection systems that would block any other protocol. It's a quiet capability with significant implications for anyone operating in restrictive network environments.
RNS-over-HTTP is the kind of thing that rarely makes headlines but matters enormously in practice. If you're in a country with aggressive internet filtering, or on a corporate network that blocks non-HTTP traffic, this is the difference between having Reticulum and not having it.
The list continues. rns-over-icmp uses ICMP ping packets as a transport layer. Genuinely unexpected. A D-STAR interface by R2AirVlad enables Reticulum over Icom transceivers using GMSK modems. And there's a community-maintained guide for running Reticulum over DNS tunnels using Iodine. If there's a physical medium that can carry a digital data stream, someone is probably working on a Reticulum interface for it.
Beyond the protocol implementations and transport interfaces, a range of practical tools has emerged that extends what you can do with a Reticulum node. Some of these are polished and production-ready. Others are rough around the edges but fill gaps that didn't have any solution before.
rnsh by acehoss provides SSH-like shell sessions over a Reticulum network. If you have a remote node running anywhere on the mesh, you can open a terminal session to it, encrypted, authenticated, and routed through whatever physical infrastructure Reticulum is using. No IP address required, no port forwarding, no exposure to the public internet. For anyone maintaining remote infrastructure, this is a significant capability.
RETCON by DanBeard takes a different approach to deployment: pre-configured Raspberry Pi images that automatically form resilient mesh networks the moment they boot. Drop a RETCON node somewhere with power and a radio, and it joins the mesh without any configuration. For rapid deployment scenarios: emergency response, event coverage, temporary infrastructure. This dramatically lowers the barrier to standing up a network quickly.
rBrowser brings a modern web-based interface to NomadNet nodes and pages. If you've found NomadNet's terminal interface intimidating, rBrowser offers an alternative entry point to the same network. It's the kind of usability improvement that expands who can participate.
lxmf-cli is a feature-rich terminal-based LXMF messaging client, a serious alternative to Sideband for users who prefer working in the terminal or need something that runs headlessly on a server. Worth knowing about if you're running nodes on systems without a graphical interface.
Columba brings LXMF messaging to Android over Bluetooth LE, no radio hardware needed. Ren/Browser from the Quad4 team is a cross-platform Reticulum network browser targeting Web, Linux, Windows, macOS, Android, and iOS. And RNode Firmware CE by LiberatedSystems is a community-maintained fork of the reference RNode firmware, kept up to date and distributable through standard channels.
Some of the most interesting developments in the Reticulum ecosystem are the ones that weren't part of any roadmap. They're the projects that appear when a community of technically capable people has a solid protocol and the freedom to build whatever they want with it.
The ollama-bot project lets you interact with locally-running large language models over the LXMF protocol using the LXMFy bot framework. Send a message over Reticulum, get a response from an AI model running on a machine somewhere on the mesh. No cloud, no account, no internet required. The implications for off-grid AI assistance, particularly for emergency preparedness and remote operations, are real, even if the use case sounds unusual at first.
lxmf-vanity-address-generator does exactly what it sounds like: generates LXMF addresses with a chosen prefix. In a network where addresses are cryptographic hashes and otherwise look like random strings, being able to choose a recognizable prefix matters for identity and trust. Small tool, but thoughtful.
A cluster of tools around Micron, NomadNet's lightweight markdown format, has emerged for people who want to publish content on the mesh. micron-blog is a Pelican plugin that publishes a site in Micron format. micron-composer is a WYSIWYG editor for creating NomadNet pages. micron-parser-js brings a JavaScript parser to the format, opening the door to web-based Micron tooling. The mesh has a publishing ecosystem now.
RRCd by KC1AV implements a live chat system on top of Reticulum, similar to IRC in concept. It's a reminder that the protocol is general enough to carry almost any communication pattern, not just the messaging and page-browsing use cases that ship with the reference tools.
Reticulum Phantom by roogle-dev — the same hands behind the Roogle mesh search engine — bills itself as the first torrent-like application built natively on Reticulum. No trackers, no central servers, no DNS. Files split into verified chunks and seeded over whatever interfaces a node has configured: TCP/IP, LoRa, packet radio, serial. .ghost files take the place of .torrent files. Multi-file seeding shares one announce footprint regardless of how many files you're hosting, and PEX over encrypted Links keeps coordination off the announce channel entirely. Doing chunked file transfer over a stack designed for "low-bandwidth communications" is exactly the kind of thing that wasn't on anyone's roadmap, which is what makes it interesting.
One protocol, public domain, and this is what happens. Nobody asked permission. Nobody waited. They just started building.
The curated list at awesome-reticulum.net is the best single place to track what's being built across the ecosystem. It's community-maintained and updated regularly. If you're building something on Reticulum, it's worth submitting a pull request to get listed.