archy/reticulum-daemon
archipelago e62f911810 fix(mesh): Reticulum resource transfers actually deliver — 4 root causes
E2E-verified both directions dev-box<->x250 over real RF (5KB image ~60s):

1. Sender daemon never called link.identify() — receiver's
   get_remote_identity() was None, so every arrived transfer carried an
   empty source_hash and the Rust side dropped it (now also warns
   instead of silently vanishing it).
2. Receiver treated resource.data as bytes, but RNS hands a concluded
   Resource's data as a file-like BufferedReader — b64encode raised
   TypeError and the transfer was lost even when attributed.
3. Radio twins of merged contacts carry the peer's Archipelago ed25519
   key as pubkey_hex, not an RNS hash — prefix lookup could never match
   ('Unknown Reticulum prefix', observed live). resolve_dest_hash now
   falls back to matching the announce-bound arch_pubkey_hex.
4. The daemon RPC socket kept asyncio's default 64KiB line limit; any
   attachment >~48KB overflowed it and tore down the whole daemon
   connection ('reticulum-daemon is gone'). Raised to 16MiB.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 21:00:44 -04:00
..

reticulum-daemon

Host-supervised Reticulum (RNS) + LXMF bridge for Archipelago's Mesh tab. This is the Python side of the Reticulum transport plan: archipelago spawns one of these per active Reticulum (RNode) radio, it owns the serial port, and the Rust mesh subsystem drives it over a Unix-socket JSON-RPC.

Why a daemon (not the Rust reticulum-rs crate): the canonical Python rns/lxmf guarantees interop with Sideband / NomadNet / MeshChat, and lets us derive the RNS identity from the existing Archy key (proven in spike_identity.py).

Layout

  • archy_rns_identity.py — derive a deterministic RNS Identity from the 32-byte Archy Ed25519 seed (identity_dir/node_key) via domain-separated HKDF. The node's LXMF destination hash is a stable function of the Archy identity.
  • spike_identity.pyPhase-0 gate #1 (no radio): proves that determinism.
  • reticulum_daemon.py — the daemon: RNS bring-up, LXMF router, announce handler, and the Unix-socket RPC. See its module docstring for the wire protocol.
  • requirements.txt — pinned rns==1.3.5, lxmf==1.0.1 (validated on Python 3.13).

Dev setup

python3 -m venv .venv
.venv/bin/pip install -r requirements.txt

Run the spike / smoke tests (no hardware)

.venv/bin/python spike_identity.py                     # gate #1: identity determinism
.venv/bin/python reticulum_daemon.py --check \
    --identity-key /path/to/node_key                   # print this node's dest hash
.venv/bin/python reticulum_daemon.py --selftest \
    --identity-key /path/to/node_key                   # bring up RNS+LXMF, no radio

Run against a real RNode (Phase-0 hardware gate, on .116 / .228)

.venv/bin/python reticulum_daemon.py \
    --identity-key /var/lib/archipelago/identity/node_key \
    --serial-port /dev/reticulum-radio \
    --socket /run/archy/reticulum.sock \
    --display-name "archy-228"

Then verify a two-node LXMF DM over LoRa and interop with a stock Sideband/MeshChat client (Phase-0 gates #2 and #3).

Packaging (Phase 1)

Ship as a PyInstaller single binary in the OTA next to /usr/local/bin/archipelago (no provision-time pip install). archipelago supervises it: start on RNode detect, kill on unplug/disable. The RPC socket and RNS config dir are archipelago-owned, 0600.

./build.sh   # → dist/archy-reticulum-daemon (~16M, fully standalone)

-d noarchive is required, not optional — see the comment in build.sh: RNS computes RNS.Interfaces.__all__ via a glob() against its own __file__ directory at import time, which only works when PyInstaller keeps modules as loose files instead of zipping them into the binary.

Status

Phase-0 gate #1 (identity determinism) passes, verified in both the dev venv and the packaged binary (same dest hash). The signed-identity announce (ARCHY:2:{ed}:{x25519} in _announce_app_data, via --archy-ed-pubkey-hex/--archy-x25519-pubkey-hex) is wired and the Rust side (reticulum.rs) already passes the node's real keys through. Packaging is done and verified standalone. What's left is entirely hardware-dependent: the live LoRa message path (Phase-0 gates #2/#3) needs a real RNode-flashed board.