One Protocol, Many Engines: Reticulum's New Rust Implementations

When I wrote LPWAN Meshes: Reticulum, Where I Landed earlier this year, I covered Reticulum as Mark Qvist’s reference Python implementation: rnsd, Sideband, NomadNet, all built on RNS. That was accurate at the time, and it undersold what was already starting to happen underneath it. Reticulum was never meant to be a Python project. It is a protocol specification, and a protocol specification with only one implementation isn’t decentralised yet, it’s just a single point of failure with good branding.

Over the past year, that has changed. Four independent teams have built substantial Reticulum and LXMF stacks in Rust (at least one smaller from-scratch implementation exists outside these four, still early and separate from all of them), for reasons that have nothing to do with fashion and everything to do with where Python actually falls over: mobile devices. I’ve had my own run-in with exactly this kind of embedded-runtime fragility this year, The Ubuntu Lovers’ Blues covers a Flutter build breaking under me for reasons that had nothing to do with my own code, and the underlying pattern is familiar: a heavy, bundled runtime wedged into an app via a compatibility shim is a liability waiting for the next platform update. Rust doesn’t carry that liability, and that turns out to matter for something bigger than developer convenience.

Protocol, Not Product

The distinction matters, and the rest of this piece leans on it: Reticulum is a cryptographic network protocol. RNS, the original Python codebase, is its reference implementation, not the thing itself. Qvist designed Reticulum from the ground up as a transport-agnostic, open specification rather than a single piece of software, and that protocol-first architecture is what makes independent implementations in other languages possible at all.

For most of Reticulum’s life, the practical picture was still one runtime:

flowchart TD
    P["RETICULUM PROTOCOL"] --> RNS["Python RNS (rnsd)"]
    RNS --> SB["Sideband"]
    RNS --> NN["NomadNet"]

What’s emerging now is multi-runtime and considerably harder to break in one place:

flowchart TD
    P["RETICULUM PROTOCOL"] --> PY["Python RNS<br/>(reference implementation)"]
    P --> RS["Rust stacks<br/>Leviculum, rsReticulum,<br/>Beechat, FreeTAKTeam"]
    P --> OL["Other languages<br/>Kotlin, C, Go, etc."]
    PY --> APP["Downstream applications<br/>mobile clients, field gateways,<br/>TAK nodes, MCUs"]
    RS --> APP
    OL --> APP

That shift matters for the same reason decentralisation always matters here: the survival, security, and interoperability of the mesh should never depend on a single language runtime, package registry, or development team.

Why Rust, and Why It Matters More on a Phone

Rust suits Reticulum for a specific, technical set of reasons, not because it’s the language of the moment:

• Memory safety without a garbage collector. Zero-cost abstractions and deterministic memory management (RAII) rule out whole classes of buffer overflows, use-after-free bugs, and memory leaks at compile time, not at runtime.
• A small, predictable resource footprint. Native Rust typically runs at around 2 to 6 MB of RAM, against roughly 35 to 60 MB for an embedded CPython runtime doing the same job.
• Fearless concurrency. Rust’s Send and Sync primitives let cryptographic ratchets, routing logic, and Proof-of-Work stamp miners run on multiple threads at once without data races, checked by the compiler rather than by discipline.
• Genuine cross-compilation. Standard toolchains (cargo-ndk, cargo-zigbuild, cross) target Android, Linux, iOS, and bare-metal microcontrollers from the same codebase.
• Direct mobile integration. Rust compiles straight to native shared libraries, .so on Android, a framework or .dylib on iOS, callable over FFI without an intermediate daemon or a heavyweight runtime emulator sitting in between.

One distinction shapes every implementation below: whether a Rust codebase depends on the standard library (std) or runs bare-metal (no_std plus alloc).

For a mobile architecture specifically, an in-process Rust networking core gives a clean, decoupled shape to the whole app:

flowchart TD
    UI["Android application<br/>(Kotlin / Flutter UI)"] --> FFI["JNI / UniFFI / FFI (v2)"]
    FFI --> CORE["Rust Reticulum core<br/>(in-process)"]
    CORE --> LORA["LoRa radio over BLE<br/>(RAK WisBlock / RNode)"]
    CORE --> TCP["TCP / UDP peering<br/>(mesh hubs / gateways)"]
    CORE --> WIFI["WiFi AutoInterface<br/>(local multicast)"]

That layout avoids the heavy memory penalty of embedding Python (via something like Chaquopy) and sidesteps Android’s habit of aggressively killing detached background daemon processes to save battery.

Four Implementations, One Protocol

Four Rust codebases currently matter here, and each one is solving a different problem with the same underlying wire format.

Leviculum

• Repository: Codeberg: Lew_Palm/Leviculum
• Website: leviculum.network
• Licence: GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later)
• Maintainer: Lew Palm (Lew_Palm)

flowchart TD
    L["LEVICULUM"] --> CORE["leviculum-core<br/>(no_std core)"]
    L --> LXMF["leviculum-lxmf<br/>(messages / telemetry)"]
    L --> FFI["leviculum-ffi<br/>(shared C / FFI)"]
    L --> STD["leviculum-std<br/>(lnsd daemon)"]
    CORE --> MCU["Microcontrollers<br/>(nRF52 / T114)"]
    LXMF --> TEL["Field telemetry &<br/>stamp miner"]
    FFI --> MOB["Mobile apps<br/>(Android / Flutter)"]
    STD --> GW["Linux systemd<br/>gateways"]

Leviculum is an independent, protocol-first reimplementation written in modern Rust, adhering strictly to the official Reticulum protocol specification. Its own framing is direct: build a memory-safe Rust foundation for Reticulum that stays decoupled from any single commercial product and faithful to the wire specification.

The core protocol engine compiles as no_std with alloc, meaning the identical cryptographic and routing code runs on microcontrollers (Nordic nRF52840, ESP32, Heltec T114), mobile devices, and high-throughput server daemons (lnsd) without a fork in the codebase.

What stands out:

• Independent and protocol-first. Not built as a proprietary backend for one hardware vendor or messaging client, it’s neutral, general-purpose infrastructure.
• Full protocol completeness. Complete implementations of packet framing, path discovery, link establishment, cryptographic ratchets, multi-hop routing, channel buffers, and file transfer (lncp), with wire compatibility checked by an automated CI interop suite against reference Python nodes running in Docker.
• Native LXMF and telemetry. leviculum-lxmf provides native LXMF container framing, Proof-of-Work stamp mining on work-stealing runtimes, and a dedicated no_std Telemeter codec for structured FIELD_TELEMETRY sensor frames, directly relevant to the sensor telemetry mechanics this site has covered separately.
• A genuinely modular crate layout: leviculum-core (zero-dependency no_std protocol logic), leviculum-lxmf (messaging, telemetry, stamp mining), leviculum-ffi (a clean C-ABI facade for mobile and cross-language bindings), leviculum-nrf and lnflash (bare-metal firmware and provisioning for RAK4631 and Heltec hardware), and leviculum-cli (native drop-in replacements for rnsd/rnstatus).
• Strong copyleft governance. AGPLv3 protects the codebase from proprietary enclosure.
• Standard hardware support: RNode interfaces, raw LoRa KISS serial, and BLE UART modems.

Where it’s thinner: the application layer around it is smaller than what surrounds Ratspeak, development is currently concentrated in one core maintainer (a real bus-factor risk), and the mobile wrapper layer (Flutter or UniFFI bindings) is still community territory rather than a finished product.

rsReticulum / Ratspeak

• Repositories: GitHub: Ratspeak
• Licence: GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later)
• Key figure: defidude / dude.eth

flowchart TD
    RS["rsReticulum"] --> LXMF["rsLXMF<br/>(messaging core)"]
    RS --> LXST["rsLXST<br/>(voice stream)"]
    RS --> NOMAD["nomadnet-rs<br/>(NomadNet engine)"]
    LXMF --> RAT["Ratspeak<br/>(unified messaging client)"]
    LXST --> RAT
    NOMAD --> RAT
    RAT --> SW["Software<br/>(desktop / web)"]
    RAT --> HW["Hardware<br/>(rsCardputer, rsDeck, ratkey)"]

rsReticulum is the networking core of the broader Ratspeak project. Rather than positioning itself as an abstract protocol library, it’s built as the foundation under an integrated suite of messaging apps, voice tools, and standalone hardware.

What stands out:

• The largest surrounding application set. A family of specialised crates: rsLXMF (messaging), rsLXST (voice streaming), and a nomadnet-rs NomadNet node and browser engine.
• Real hardware, not just software. Deployed to consumer microcontroller hardware including the M5Stack Cardputer (rsCardputer), the LilyGo T-Deck (rsDeck), and hardware key fobs (ratkey).
• Active downstream interoperability. Third-party clients build against it, including Colorado Mesh’s cross-platform desktop app, which targets Ratspeak-compatible peers.
• A genuine security contribution. Credited by the upstream Python Reticulum project for identifying a critical BZ2 decompression-bomb vulnerability.

Where it’s thinner: governance is founder-centric, developed primarily by defidude without an independent foundation or steering committee, the networking stack is closely coupled to Ratspeak’s own product direction (which can create friction for a third-party developer wanting a genuinely neutral protocol engine), and AGPLv3 licensing rules out proprietary device manufacturers embedding it in closed-source firmware.

Beechat Reticulum-rs

• Organisation: GitHub: BeechatNetworkSystemsLtd
• Documentation: docs.beechat.network
• Licence: MIT
• Tie-in: Kaonic tactical radio systems

flowchart TD
    B["Beechat Reticulum-rs"] --> K["Kaonic radios<br/>(embedded hardware)"]
    B --> Y["Yocto Linux layer<br/>(SDR baseband images)"]
    B --> M["MAVLink / tactical<br/>(UAV telemetry mesh)"]

Beechat approaches Reticulum from an embedded-hardware, commercial aerospace and tactical angle: deploy Reticulum onto ruggedised, commercial SDR radio hardware under a permissive licence.

What stands out:

• A permissive MIT licence, uncommon among the major Rust implementations, which lets commercial aerospace, defence, and IoT vendors embed the stack in proprietary products without AGPL copyleft obligations.
• Real commercial systems engineering: tight integration with Kaonic SDR hardware, custom Yocto Linux board support packages, MAVLink drone telemetry, and tactical mesh deployments.
• A transport focus that follows the hardware: high-throughput serial, TCP/UDP, and Kaonic’s own proprietary radio interfaces.

Where it’s thinner: early work concentrated on specific transports (TCP, serial, Kaonic) rather than the full wire specification, though coverage keeps expanding; it’s architected around std for Linux-class embedded systems rather than the ultra-constrained no_std microcontroller targets Leviculum reaches; and feature priority naturally follows Beechat’s own commercial radio lineup.

FreeTAKTeam / LXMF-rs

• Repository: GitHub: FreeTAKTeam/LXMF-rs
• Licence: Eclipse Public License 2.0 (EPL-2.0)
• Focus: situational awareness, TAK (Team Awareness Kit), and public safety

flowchart TD
    F["FreeTAKTeam LXMF-rs"] --> EMB["rns-embedded-core<br/>(bare-metal microcontroller)"]
    F --> CORE["reticulum-rs-core<br/>(transport / RPC engine)"]
    F --> D["reticulumd<br/>(stand-alone daemon)"]
    EMB --> TAK["FreeTAKServer & TAK mesh<br/>(emergency services / CoT)"]
    CORE --> TAK
    D --> TAK

FreeTAKTeam, the team behind FreeTAKServer, moved from an archived standalone Reticulum-rs repository into a comprehensive multi-crate workspace called LXMF-rs, built to deliver an operational, mission-critical Reticulum and LXMF stack for situational awareness, cursor-on-target telemetry, and public-safety mesh networks.

What stands out:

• A genuinely comprehensive multi-crate architecture: reticulum-rs-core, reticulum-rs-transport, rns-embedded-core, rns-embedded-runtime, rns-embedded-ffi, and reticulumd as distinct, purpose-built pieces.
• Dedicated embedded crates built specifically to bridge low-power field microcontrollers into TAK networks.
• Real operational public-safety use: direct downstream integration with TAK systems, emergency disaster mapping, and situational awareness tools.
• EPL-2.0 licensing, a commercially viable, copyleft-per-file middle ground between AGPL and MIT.

Where it’s thinner: maintaining a large multi-crate workspace spanning embedded, FFI, RPC, and daemon components is a genuine ongoing testing burden, and design decisions understandably favour TAK and CoT workflows over consumer chat or general IoT telemetry.

How They Stack Up

The Mobile Architecture Question

For an Android or Flutter developer, the choice of implementation decides the app’s memory footprint, battery behaviour, and long-term stability, not just which crate ends up in Cargo.toml.

The current approach most mobile Reticulum clients (Columba, for example) still use looks like this:

flowchart TD
    UI["Android UI (Kotlin)"] --> J["Chaquopy / Python C-API JNI"]
    J --> CP["CPython runtime<br/>(35 to 50 MB RAM)"]
    CP --> STACK["Python RNS / LXMF reference stack"]

A native Rust core changes the shape entirely:

flowchart TD
    UI["Android UI (Kotlin / Flutter)"] --> BR["flutter_rust_bridge v2 / UniFFI"]
    BR --> ENG["Leviculum Rust engine (2 to 5 MB RAM)<br/>leviculum-core (routing & crypto)<br/>leviculum-lxmf (telemetry & messages)<br/>leviculum-ffi (safe bridge layer)"]
    ENG --> T["Native radio & socket transports (BLE / IP)"]

Three concrete reasons native Rust outperforms embedded Python on a phone:

1. Memory footprint. Roughly 2 to 5 MB of RAM against 40 to 60 MB for Chaquopy/CPython, which matters directly because Android’s low-memory killer targets exactly this kind of oversized background process first.
2. CPU efficiency and battery life. Rust runs as compiled ARM64 machine code. Computing SHA-256 Proof-of-Work stamps or X25519 ratchets happens at hardware speed, with no bytecode interpreter sitting in between.
3. Process lifecycle resilience. A Rust shared library (.so) loaded in-process can run inside an Android foreground service with connectedDevice and dataSync flags and survive deep OS Doze cycles, instead of being the detached daemon Android’s scheduler keeps killing.

Getting Rust Into Kotlin and Dart

Leviculum’s leviculum-ffi crate is built to expose cleanly through modern binding generators:

• flutter_rust_bridge (FRB v2) generates zero-copy, asynchronous Dart streams (StreamSink<MeshEvent>) and typed structs directly from Rust APIs, enabling proper cross-platform UI work on Android and Linux.
• Mozilla’s UniFFI generates idiomatic Kotlin and Swift bindings straight from Rust UDL or procedural macros, for a fully native Jetpack Compose (Android) or SwiftUI (iOS) interface.

flowchart TD
    C["leviculum-core / leviculum-lxmf"] --> FFI["leviculum-ffi"]
    FFI --> FRB["flutter_rust_bridge v2"]
    FFI --> UNI["UniFFI"]
    FRB --> DART["Flutter / Dart<br/>(cross-platform UI)"]
    UNI --> KOT["Kotlin (Android) /<br/>Swift (iOS)"]

The practical upshot: a mobile developer can build a native app without maintaining custom cryptographic or routing code by hand in Kotlin or Dart.

Where the Community Actually Lives

The Rust Reticulum developer community is spread across several collaborative hubs rather than one central home:

• Codeberg hosts Leviculum and its issue tracker, focused on core protocol discussion and embedded firmware.
• GitHub hosts Ratspeak, Beechat, FreeTAKTeam, and most mobile client projects.
• Matrix and Reticulum mesh channels carry active discussion of RNode hardware, AU915/US915/EU868 frequency allocation, and cross-implementation wire testing.

Nobody needs to wait for a single dominant organisation to set the mobile standard here. There’s real room for independent developers to build reusable bridge libraries, a leviculum-android wrapper and similar, that the whole community benefits from rather than any one vendor.

The Real Risk Isn’t Rust. It’s Fragmentation

As multiple independent Rust implementations mature in parallel, the biggest risk to the mesh is no longer “does Rust work here”, it’s protocol fragmentation. Without rigorous shared test suites, small divergences in packet packing, IFAC flag handling, or announcement timing could quietly partition the network into implementations that no longer actually talk to each other.

flowchart TD
    P["RETICULUM PROTOCOL"] --> CTS["Conformance test suite<br/>(automated wire validation)"]
    CTS --> PY["Python RNS<br/>(reference spec)"]
    CTS --> LEV["Leviculum<br/>(AGPL native)"]
    CTS --> RS["rsReticulum<br/>(Ratspeak)"]
    CTS --> FTT["FreeTAKTeam<br/>(EPL TAK / SDK)"]
    PY --> WC["Guaranteed wire compatibility"]
    LEV --> WC
    RS --> WC
    FTT --> WC

What actually closes that gap:

1. Deterministic test vectors for Ed25519 identity derivation, X25519 ECDH key agreement, Fernet-style AES-256-CBC token encoding, and Proof-of-Work stamp hashes, published and shared, not held privately by any one team.
2. Automated wire conformance testbeds: continuous integration running virtualised multi-hop networks (Leviculum’s own leviculum-proxy against Dockerised Python nodes is the current best example) that assert byte-for-byte packet equivalence.
3. Neutral protocol governance: shared documentation and a transparent change-proposal process so Reticulum stays a common standard rather than whatever the largest implementation happens to do this year.

It’s a smaller-scale version of a question this site keeps returning to: decentralised architecture only stays decentralised if the governance around it is deliberately kept that way. Four implementations racing ahead of a shared conformance suite is exactly how a protocol quietly becomes whichever implementation shipped fastest.

Who Each One Is Actually For

• Leviculum: neutral, copyleft, protocol-first infrastructure, embedded microcontrollers (no_std), and clean native mobile wrappers.
• rsReticulum / Ratspeak: turnkey consumer applications, voice streaming (rsLXST), and a ready-to-run desktop and MCU mesh experience today.
• Beechat Reticulum-rs: commercial hardware integrations that need permissive MIT licensing and tactical SDR systems.
• FreeTAKTeam LXMF-rs: situational awareness, public safety, and TAK operational networks.

If You’re Actually Building This

For anyone building an Android, iOS, or Flutter app on Reticulum:

1. Standardise on leviculum-core and leviculum-lxmf as the networking and telemetry engine.
2. Generate type-safe bindings with flutter_rust_bridge (Flutter) or UniFFI (pure Kotlin/Jetpack Compose).
3. Run the networking layer as an Android foreground service with dataSync and connectedDevice service types, to keep mesh connectivity alive in the background.
4. Wrap private identity keys in hardware, the Android Keystore or iOS Keychain, rather than plain storage.
5. Talk to RAK WisBlock and RNode hardware over Bluetooth Low Energy UART with proper exponential-backoff auto-reconnect logic.
6. Contribute conformance tests and mobile abstractions back upstream. A genuinely vendor-neutral mesh only stays that way if the people building on it keep feeding fixes back into the shared test suite, not just their own fork.

This is landscape-mapping, not a build log, I haven’t shipped a Reticulum mobile app on any of these stacks yet. But between the sensor telemetry mechanics covered elsewhere on this site and the mobile-native case Leviculum makes, the pieces for a properly local-first mesh companion app are closer to hand than they were even six months ago.

Related reading: LPWAN Meshes: Reticulum, Where I Landed for the protocol’s original architecture, Sensor Data Over Reticulum for LXMF’s telemetry mechanics in depth, and The Decentralisation Paradox on why decentralised architecture and decentralised governance are not the same guarantee.

Sources

• Reticulum Network Stack, reticulum.network. Mark Qvist’s reference protocol specification and Python implementation.
• Reticulum cryptographic primitives, reticulum.network/crypto.html. X25519, Ed25519, AES-256-CBC, and the Fernet-style token construction.
• Reticulum Changelog. Records the bz2 decompression-bomb fix credited to @defidude (github.com/ratspeak).
• Lew Palm, Leviculum and leviculum.network. Protocol-first Rust implementation.
• Ratspeak, GitHub organisation. rsReticulum, rsLXMF, rsLXST, nomadnet-rs, and the Ratspeak hardware line.
• Beechat Network Systems, GitHub organisation and documentation. MIT-licensed Rust implementation for Kaonic radio hardware.
• FreeTAKTeam, LXMF-rs, successor to the archived Reticulum-rs. Reticulum and LXMF stack for TAK and public-safety mesh networks.

• Reticulum
• Rust
• Lxmf
• Mobile Development
• Android
• Flutter
• Open Source
• Mesh Networking