Salem Data Blog

Reticulum on Rust: Comparison Of Two Projects

—

by

John Poole
in , , , ,

highly technical

There are two projects that came to my attention where the Reticulum implementation1 is built using the Rust programming language. I know very little Rust, but I have been impressed with everything so far. Scott Lamb of the Moonfire NVR project has been suggesting I learn Rust since 2018, and a top-notch Perl maven, Gabor Szabo, has been branching out into Rust. I built in Rust a UDP extension in Thomas Habets rustradio project (similar to the GNU Radio project) and it took a lot of time and consideration, Habets leverages a variety of Rust’s powerful features in designing his crate. My conclusion was that Rust offers a huge panoply of ways to extend and integrate components, so much so that trying to extend an existing project can be a very daunting task.

My practical question is whether either Rust project could eventually become useful for constrained Reticulum work on ESP32-class hardware, particularly the LilyGO T-Beam Supreme.  So, as a preliminary step, I thought I’d set the stage for Open AI’s Codex to evaluate and contrast both projects and then relate what they may offer vis-a-vis my work with the LilyGO T-Beam Supreme.

I downloaded and staged these two projects on my workstation:

Beechcraft Network Systems Ltd.’s Reticulum-rs (https://github.com/BeechatNetworkSystemsLtd/Reticulum-rs)

Lew Palm’s leviculum (https://codeberg.org/Lew_Palm/leviculum)

With OpenAI’s Codex, I gave it the task to compare and contrast.  Here’s the prompt I used:

I have staged two Rust Reticulum projects under /usr/local/src/reticulum/rust Would you please compare and contrast both projects and provide me a list pros & cons for each? I would like to know how they may differ.

Here’s Codex’s conclusion.  My take-away is that Reticulum-rs appears easier to understand and reuse, but is not close to an embedded transport. Leviculum is much more ambitious and architecturally closer to embedded use, but its size, AGPL license, and current nRF52840 focus make it a porting project rather than a drop-in T-Beam solution.

Rust Reticulum Project Comparison

Scope and basis

/usr/local/src/reticulum/rust was empty on June 7, 2026. This comparison
therefore covers the two Rust projects staged beside it2:

  • /usr/local/src/reticulum/Reticulum-rs, commit
    d68c4f5a22f12915004fb38dcc8e15c596d89edf
  • /usr/local/src/reticulum/leviculum, commit
    6f366ca04f64075acf4dc3d90e1dda88b23d325d

The findings below are based on the checked-out source, manifests, tests, and
repository history. Project README claims are not treated as proof unless the
corresponding implementation or test infrastructure is present.

Executive summary

These projects target different levels of the stack.

  • Reticulum-rs is a compact, permissively licensed Rust library for core
    Reticulum packet, identity, destination, link, routing, and TCP/UDP/Kaonic
    behavior. It is much easier to understand and embed into a conventional
    Tokio application, but it does not currently provide a complete Reticulum
    operational environment.
  • Leviculum is a much larger independent implementation intended to replace
    Python Reticulum operationally. It includes a no_std protocol core, daemon,
    shared-instance compatibility, CLI tools, persistence, resource transfer,
    ratchets, RNode/LoRa support, embedded firmware, Debian packaging, and a large
    interoperability test system. Its costs are complexity, a larger maintenance
    surface, unfinished edges, and AGPL licensing.

For a full Rust Reticulum node or daemon, Leviculum is substantially closer
to the goal. For a smaller library, prototype, or permissively licensed
commercial integration, Reticulum-rs is the easier starting point, provided
its missing protocol and operational features are acceptable.

Comparison matrix

Area Reticulum-rs Leviculum
Repository shape One crate Multi-crate workspace plus embedded firmware
Version 0.1.0 Workspace 0.6.3
License MIT AGPL-3.0-or-later
Rust source size About 7,548 lines About 130,925 lines
Checked-out Git commits 181 652
Main authorship Several contributors Almost entirely one contributor
Protocol architecture Tokio-coupled Transport and interfaces Sans-I/O no_std + alloc core plus platform drivers
Genuine no_std core No Yes, reticulum-core
Included interfaces TCP client/server, UDP, Kaonic gRPC; HDLC framing TCP, UDP, serial, RNode, AutoInterface, local/shared instance; HDLC, KISS, BLE framing
Routing and links Implemented, with remaining TODOs Broad implementation with extensive interop scenarios
Channels Packet context exists; no channel subsystem found Implemented
Resource transfer Packet context exists; no resource subsystem found Implemented, including segmented transfer and compression
Ratchets Not found Implemented with storage support
Persistence abstraction Not found Storage trait with memory, embedded, and file-backed implementations
Daemon and native CLI None lnsd, lns, and lncp
Python shared-instance compatibility Not found Implemented and tested
Embedded deliverable No firmware; Tokio/tonic dependencies nRF52840 firmware for T114 and RAK4631
FFI None Present, but explicitly incomplete
Packaging None Nightly static Debian packages and systemd service
Test surface in source 11 plain tests and 8 Tokio tests found 1,735 plain tests and 322 Tokio tests found
Project maturity statement No explicit production warning Explicitly says not production-ready

Reticulum-rs

Pros

  • Small and understandable. The single-crate design and roughly 7.5K lines
    of Rust make code review, experimentation, and focused modification practical.
  • Permissive MIT license. This is materially easier for proprietary,
    embedded-product, and commercial use than Leviculum’s AGPL license.
  • Conventional Tokio integration. Applications already using Tokio can
    instantiate Transport, spawn interfaces, and consume broadcast channels
    without building a separate driver layer.
  • Useful core coverage. Source implements identities, destinations,
    announces, packets, links, path requests, routing tables, announce rate
    limiting, TCP, UDP, and Kaonic gRPC support.
  • Multiple contributors. The checked-out history shows meaningful work from
    at least three primary contributors, reducing total dependence on one author.
  • Clean low-level safety profile. No unsafe blocks were found in its Rust
    source.
  • CI includes Python interoperability. GitHub Actions clones Python
    Reticulum and runs the feature-gated Python test along with Clippy and tests.

Cons

  • Not a full Reticulum replacement. There is no daemon, shared-instance
    server, Reticulum-compatible configuration loader, native CLI, persistence
    layer, packaging, or RNode implementation.
  • Embedded claim is not currently supported by the crate design. The crate
    has an empty alloc feature but no #![no_std]; it unconditionally depends
    on Tokio full, tonic, prost, and OS randomness. Using it on a bare-metal
    target would require substantial restructuring.
  • Important protocol subsystems appear absent. Resource and channel packet
    contexts are defined, but no resource-transfer or channel implementation was
    found. Ratchets were not found.
  • Interface coverage is narrow. The README mentions serial, but the source
    contains HDLC framing without a serial interface implementation.
  • Some claims exceed implementation. Crate docs say resources can send
    arbitrary amounts of data, but no resource API or module exists.
  • Limited test depth compared with Leviculum. The repository has a small
    unit/integration suite and only one Python interoperability test file.
  • Remaining implementation TODOs affect behavior. Examples include announce
    queue/cap handling, proof strategy checks, active-link timeout cleanup, and
    generic packet handling.
  • Verification concern. In this environment, 12 unit tests and three hop
    tests passed, but message_proof_over_remote_link ran for more than three
    minutes without completing and had to be terminated. The full test run
    therefore did not pass.
  • Build-time dependency on protoc. Kaonic gRPC generation is unconditional
    in build.rs, increasing setup burden even for users not using Kaonic.

Leviculum

Pros

  • Much broader implementation coverage. Source includes routing, path
    discovery, links, encrypted channels, requests, receipts, segmented resource
    transfer, BZ2 compression, ratchets, IFAC, RNode handling, and persistence.
  • Strong architecture for portability. reticulum-core is explicitly
    #![no_std], uses a sans-I/O design, and injects clocks, storage, randomness,
    and interfaces through traits. The protocol core is not tied to Tokio.
  • Operationally useful deliverables. It provides lnsd, lns, and lncp,
    Reticulum-style configuration, shared-instance support, Python CLI RPC
    compatibility, systemd packaging, and static Linux builds.
  • Concrete embedded implementation. The repository includes nRF52840
    firmware, LoRa/SX1262 support, BLE framing, board support, and hardware test
    scenarios rather than only claiming embedded suitability.
  • Extensive verification infrastructure. It has unit tests, property tests,
    generated Python-derived vectors, Python rnsd interoperability tests,
    Docker topology tests, fault injection, cross-implementation LoRa tests, and
    hardware test tiers.
  • Storage is a first-class design concern. Protocol state is abstracted
    behind a typed Storage trait with no-op, memory, embedded, and file-backed
    implementations.
  • Deployment work is unusually complete for a pre-production project.
    Static musl builds, Debian packaging, systemd units, nightly releases, and
    diagnostic tooling are present.
  • Documentation is significantly deeper. Architecture, configuration,
    testing tiers, CLI manuals, structured event logs, and hardware protocol notes
    are included.

Cons

  • AGPL-3.0-or-later licensing. Network use and distribution can impose
    source-sharing obligations. This may rule it out for some commercial or
    closed-source deployments; obtain legal advice for the intended use.
  • Much larger complexity and audit surface. At roughly 131K Rust lines plus
    scripts, packaging, docs, and hardware support, it is far harder to fully
    understand, audit, or maintain than Reticulum-rs.
  • High single-maintainer concentration. Nearly all checked-out commits are
    attributed to one author. That creates bus-factor and continuity risk despite
    the project’s high activity.
  • Explicitly not production-ready. The project says this directly. Its
    changelog also shows frequent fixes to routing, links, resources, shared
    instance behavior, and LoRa reliability.
  • Some public-facing pieces remain incomplete. The FFI crate describes
    itself as a stub/orphaned crate and only exposes identity operations. Several
    fallback lns command paths print “not implemented yet,” and two integration
    executor step types use unimplemented!.
  • Default build setup adds friction. .cargo/config.toml defaults host
    builds to x86_64-unknown-linux-musl. The first core test attempt failed here
    because that target was not installed; a GNU-target override was required.
  • Workspace boundaries are less simple than advertised. reticulum-nrf is
    excluded from the workspace and must be built separately. Full verification
    also depends on Docker, vendored Python Reticulum, system services, and
    physical LoRa hardware.
  • One-author velocity can increase regression risk. The large test suite
    mitigates this, but the rapid sequence of protocol bug fixes indicates that
    broad feature coverage should not be confused with stable production maturity.

Key architectural difference

Reticulum-rs puts networking and protocol state into a Tokio-oriented
Transport object. This is straightforward for a normal async Rust program,
but makes bare-metal reuse and deterministic protocol testing difficult.

Leviculum separates protocol decisions from I/O. Its core consumes packets and
timeouts, then returns actions and events. Tokio, embedded firmware, or another
runtime performs the actual I/O. This adds abstraction and code volume, but it
is the stronger architecture for running the same protocol implementation
across Linux daemons and microcontrollers.

Recommendation by use case

  • Full replacement for Python rnsd, interoperability testing, LoRa/RNode,
    file transfer, or embedded firmware:     choose Leviculum as the evaluation
    baseline.
  • Small Rust application needing only core packet/link/routing behavior:
    Reticulum-rs may be sufficient and is much easier to integrate.
  • Closed-source or commercially sensitive use: Reticulum-rs has the simpler
    license. Leviculum’s AGPL implications need legal review.
  • Protocol research or implementation-derived specification work: Leviculum
    currently provides much more observable behavior and many more reproducible
    interop scenarios, but claims still need comparison against upstream Python
    source and traces.
  • Production deployment today: neither project should be accepted solely on
    repository claims. Leviculum is closer functionally but explicitly
    pre-production; Reticulum-rs has a narrower scope and an observed hanging
    integration test.

Verification notes

  • Reticulum-rs: cargo test --all-targets
    • 12 unit tests passed.
    • Three hop tests passed.
    • message_proof_over_remote_link did not complete after more than three
      minutes and was terminated.
    • The Python interop feature was not enabled in this run.
  • Leviculum: cargo test -p reticulum-core --lib
    • The default attempt failed because the configured
      x86_64-unknown-linux-musl target was not installed.
    • Verification was rerun against x86_64-unknown-linux-gnu.
    • All 1,109 reticulum-core library tests passed in 1.81 seconds.
  • Docker, Python interop, embedded cross-builds, and hardware tests were not run.

I then asked:

I’ve been using microreticulum for work on the T-Beam SUPREMES. Would either of these be easily configured to work on the ESP32-S of the T-Beam? Can you also assess some memory metrics as I wonder if leviculum would need some paring down and removing features not needed for a T-Beam (in transport mode).
Here’s Codex’s response.

Recommendation

  • Continue using microReticulum for the shortest path to a working T-Beam Supreme transport.
  • Use Leviculum if you want to develop a Rust-based transport implementation.
  • Do not use Reticulum-rs for the T-Beam unless you are prepared for a substantial redesign.

ESP32-S3 Suitability

Project ESP32-S3 effort Assessment
microReticulum Already operational Best current option
Leviculum Moderate porting project Suitable Rust foundation
Reticulum-rs Major architectural rewrite Poor embedded starting point

Leviculum’s reticulum-core is genuinely no_std, uses a sans-I/O design, and abstracts its clock, RNG, storage, and interfaces. However, it currently only has an embedded runtime for nRF52840 boards. An ESP32-S3 runtime, T-Beam board definition, and SX1262 interface would need to be implemented.

Reticulum-rs currently depends directly on Tokio, tonic, host networking, and the standard library. Its empty alloc feature does not make it an embedded-ready crate.

Memory Findings

Leviculum’s existing T114 firmware provides the best available embedded measurement:

  • Approximately 189 KB flash
  • Approximately 232 KB application RAM
  • Approximately 48–50 KB steady/peak heap usage
  • Current configured heap: 64 KB

This full firmware includes LoRa, BLE, USB, logging, and other functionality. A transport-only ESP32-S3 build should be feasible within the T-Beam Supreme’s nominal 320 KB internal RAM, without requiring aggressive removal of protocol features.

The current T-Beam PlatformIO profiles report no PSRAM enabled, even though the Supreme hardware may include PSRAM. Existing heavier microReticulum test logs still showed roughly 197–243 KB free heap, suggesting memory is not presently the primary constraint.

Recommended Leviculum Transport Configuration

Start with Leviculum’s existing T114 transport configuration as the model:

NodeCoreBuilder::new()
    .enable_transport(true)
    .max_incoming_resource_size(8 * 1024)
    .max_queued_announces(32)
    .max_random_blobs(8)

For an initial T-Beam transport-only build, I would reduce it further:

  • One SX1262 LoRa interface
  • max_queued_announces: 8–16
  • max_random_blobs: 4–8
  • Disable probe responses initially
  • Keep compression disabled
  • Exclude BLE, Wi-Fi, GPS, display, SD, USB shared-instance support, and application destinations
  • Use internal RAM for protocol state; reserve PSRAM for large buffers or logs

Leviculum’s EmbeddedStorage consumes approximately 20–30 KB inline, but its table capacities are currently hard-coded. Making those capacities configurable would be the most useful memory-reduction change. Removing channels, resources, links, and ratchets at compile time would require more invasive feature-gating and probably is not necessary merely to fit the ESP32-S3.

The main Leviculum work is therefore an ESP32-S3 board/runtime port and capacity tuning, not wholesale protocol removal. Exact memory margin remains undetermined until that ESP32 firmware is built and measured on the T-Beam.

  1. As of June 7, 2026, there is no generally accepted Specification for Reticulum, the protocol is a reference protocol which means, in practical terms: look at the code.
  2. I staged the projects in a higher directory when I pulled them thinking I was in the /usr/local/src/reticulum/rust subdirectory. Any references in the report should have the “rust” subdirectory added.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *