2026-06-30 19:57:01 -04:00
# Reticulum mesh transport — progress tracker
Living status doc for the Reticulum (RNS+LXMF) third-transport work. **Update this after every
meaningful step.** If a session is cut off mid-work, read this file first, then the plan, then
resume at "Next up."
Full plan: `.claude/plans/enchanted-strolling-rocket.md` . Memory pointer:
`project_reticulum_transport_plan.md` (auto-memory index).
**Coordination note (2026-06-30):** a separate agent owns concurrent Meshtastic work, scoped to
2026-07-08 17:04:35 -04:00
`mesh/meshtastic.rs` + `mesh/protocol.rs` (see `docs/archive/SESSION-1.8.0-OTA-PROGRESS.md` ) and explicitly
2026-06-30 19:57:01 -04:00
avoiding `mesh/listener/session.rs` transport plumbing + `mesh/mod.rs` routing, which this work
owns. Stay out of `meshtastic.rs` /`protocol.rs` to avoid collisions.
## Status at a glance
| Phase | What | Status |
|---|---|---|
| 0 | Gate #1 — deterministic identity from Archy keys | ✅ **DONE** , verified in venv AND in the PyInstaller binary (same dest hash) |
| 0 | Gate #2 — two-node LXMF-over-LoRa on real hardware | ✅ **PASSED 2026-06-30** — real RF announce + encrypted DM exchanged between .116's Heltec V3 RNode and a phone-flashed second RNode running Sideband |
| 0 | Gate #3 — external Sideband/MeshChat interop | ✅ **PASSED 2026-06-30** — same session as gate #2 ; Sideband is the stock external client this gate calls for |
| 1 | `reticulum-daemon/` (Python rns+lxmf, Unix-socket RPC) | ✅ scaffolded + tested (no radio); signed-identity announce **also done** (see below) |
| 1 | Packaging — PyInstaller single binary | ✅ **DONE + verified** — `reticulum-daemon/build.sh` , 16M standalone binary, selftest passes run from `/tmp` with no venv on PATH |
| 2 | Rust wiring (`DeviceType` , `MeshRadioDevice` , `ReticulumLink` , stamp sites) | ✅ ** `cargo check` /`cargo test -p archipelago` GREEN** (99 mesh tests pass) — still untested on real hardware |
| 2c | `MeshConfig.device_kind` reflashable-board pin | ✅ **DONE** this session (was the one open Phase-2 item) |
| 3 | Frontend (~8 label/CSS spots) | ✅ DONE (scoped down — see note below) |
| 4 | Multi-device (run all 3 radios at once) + per-network channels | ⏳ not started (follow-on, after 0–
2026-07-03 18:08:35 +00:00
| 5 | Aurora interop — optional plain-TCP Reticulum interface (radio-less) | ✅ **DONE + verified 2026-07-03** — see checkpoint below. Real Aurora GUI test still open (manual follow-up). |
2026-06-30 19:57:01 -04:00
## Checkpoint 2026-06-30 (late session — read this first if cut off)
This session picked up after Phase 2/3 were already green, and closed out everything that didn't
need real RNode hardware:
1. **Corrected two stale tracker entries** (both were already done, just not reflected here):
- The `_announce_app_data` "TODO" was actually already implemented:
`reticulum_daemon.py` 's `_announce_app_data()` embeds `ARCHY:2:{ed}:{x25519}` when
`--archy-ed-pubkey-hex` /`--archy-x25519-pubkey-hex` are passed, and `reticulum.rs` 's
`daemon_command()` /`open()` already forward `our_ed_pubkey_hex` /`our_x25519_pubkey_hex` from
`session.rs` (`run_mesh_session` → `auto_detect_and_open` /`open_preferred_path` →
`ReticulumLink::open` ). Confirmed end-to-end by reading the call chain, not just grepping.
- Phase 3 frontend was already done (see prior entry below) — tracker table above said
"not started", now corrected.
2. **Added `MeshConfig.device_kind: Option<DeviceType>`** (plan §2c, the one explicitly-listed
open Phase-2 item) — `mesh/mod.rs` (field + Default + threaded into `start()` 's
`spawn_mesh_listener` call), `listener/mod.rs` (`spawn_mesh_listener` param → `run_mesh_session`
arg), `listener/session.rs` (`run_mesh_session` param; `auto_detect_and_open` skips
non-matching probes per-path via `device_kind.is_none_or(|k| k == ...)` ;
`open_preferred_path` restructured to a `match kind { ... }` that tries **only** the pinned
driver and surfaces its real error, instead of silently falling through to another firmware's
handshake on the same port). `None` (default) preserves today's strict
Meshcore→Meshtastic→Reticulum auto-detect — fully backward compatible, no config migration
needed. `cargo check` + `cargo test -p archipelago` both green after (99 mesh tests, 0 failed).
3. **Built and verified the PyInstaller packaging** (plan's Phase 1 "Packaging" + the file list's
"Ops: release packaging to include the daemon binary" item — previously undone):
- `reticulum-daemon/build.sh` (new) — reproducible build, installs `requirements-build.txt`
(new, `pyinstaller==6.21.0` , build-only/not shipped) into the existing `.venv` , runs
PyInstaller with flags discovered by trial: `--collect-submodules RNS --collect-submodules
LXMF --collect-data RNS -d noarchive` .
- **Non-obvious gotcha, written up in `build.sh` 's comments so it isn't re-discovered:**
`RNS.Interfaces/__init__.py` builds its `__all__` via `glob.glob(os.path.dirname(__file__) +
"/*.py")` at import time (`Reticulum.py` does `from RNS.Interfaces import *` ). PyInstaller's
default `--onefile` zips pure-Python modules into an in-binary PYZ archive, so `__file__`
doesn't point at a real directory and the glob comes back empty → `NameError: name
'Interface' is not defined` the moment `RNS.Reticulum(...)` is constructed. `-d noarchive`
(keep modules as loose `.pyc` files on disk inside the onefile bundle's runtime-extraction
dir) fixes it — confirmed by reproducing the failure first, then fixing it.
- **Verified, not just built:** ran the resulting `dist/archy-reticulum-daemon` binary's
`--check` (dest hash matches the venv-derived `06bb31e16f4f8d46a8ae8eac23a4fd21` for the
test seed) and `--selftest` (full RNS+LXMF bring-up, no radio) **both from `/tmp` with the
binary copied away from the repo and the `.venv` not on `PATH` ** — confirms it's genuinely
self-contained, not accidentally still depending on the dev venv.
- `dist/` /`build/` /`*.spec` are already gitignored (`reticulum-daemon/.gitignore` ); only
`build.sh` + `requirements-build.txt` are new tracked files.
**NOT done this session (still genuinely open):**
- Everything hardware-dependent (Phase 0 gates #2/#3 , real RNode probe/spawn). The .116 Heltec V3
reflash mentioned in the prior session's memory was **not** done in this session — no physical
hardware access was exercised, only software.
- `/dev/reticulum-radio` udev symlink (plan §2c) — **deliberately not added** : the existing
`99-mesh-radio.rules` keys on USB vendor/product ID (e.g. CP2102 0x10c4/0xea60), but the whole
point of `device_kind` is that the *same* chip can run any of the three firmwares — a
vendor/product udev rule can't disambiguate them, and a fabricated rule would just be
misleading. Real fix needs either a per-device `ATTRS{serial}==...` rule the operator fills in
once they know their specific board's serial (no such board exists in-repo to template from
yet), or rely on `device_kind` alone (already done, works regardless of `/dev` path naming).
Revisit once a real RNode-flashed board's serial is known.
- PyInstaller binary not yet wired into the release tarball / `scripts/deploy-to-target.sh` (the
daemon binary path is currently resolved via `ARCHY_RETICULUM_DAEMON_BIN` env or the dev venv
fallback in `reticulum.rs` 's `daemon_command()` — production default
`/usr/local/bin/archy-reticulum-daemon` is a real path convention now that `build.sh` produces
exactly that filename, but nothing copies it there yet). Left undone deliberately — wiring
release-tarball plumbing for a binary that's never been run against real RNS network traffic
felt premature; do this once Phase 0 gates #2/#3 pass.
## Phase 2 — Rust wiring detail (what's done vs left)
**Done — `cargo check -p archipelago` is GREEN:**
- `core/archipelago/src/mesh/types.rs` — `DeviceType::Reticulum` (+ `Display` arm) + a
`radio_transport_label(DeviceType) -> &'static str` helper (`"reticulum"` vs `"lora"` ).
- `core/archipelago/src/mesh/mod.rs` — all 4 outbound stamp sites use
`radio_transport_label(...)` ; `use_typed_envelope` (~1571) extended to
`matches!(device_type, Meshcore | Reticulum)` ; `data_dir` threaded into
`spawn_mesh_listener(...)` call (was: `MeshService::start()` → `spawn_mesh_listener` ).
- `core/archipelago/src/mesh/listener/mod.rs` — `spawn_mesh_listener` takes `data_dir:
PathBuf`, passes ` &data_dir` into ` run_mesh_session`.
- ` core/archipelago/src/mesh/listener/decode.rs:406,639` and ` dispatch.rs:79` — all 3 inbound
stamp sites now use ` radio_transport_label(state.status.read().await.device_type)`.
- ` core/archipelago/src/mesh/listener/session.rs`:
- ` MeshRadioDevice` enum has ` Reticulum(ReticulumLink)`; all 18 method arms wired (no-ops:
` ensure_lora_region`, ` ensure_channel`, ` send_keepalive`, ` send_nodeinfo_advert`, ` reboot`,
` reset_contact_path`; everything else forwards to ` ReticulumLink`).
- ` auto_detect_and_open(data_dir: &Path)` and ` open_preferred_path(path, data_dir: &Path)`
both now try ` ReticulumLink::open(path, data_dir)` **last**, after Meshcore/Meshtastic —
cheap raw-serial KISS-detect probe runs first; the daemon only spawns on a confirmed match.
- ` reticulum_contact_id()` helper added (delegates to the canonical
` reticulum::reticulum_contact_id_from_hash`, masked ` & 0x7FFF_FFFF`, avoids 0).
- ` refresh_contacts()` has an ` is_reticulum` branch parallel to ` is_meshtastic`; ` reachable`
flows through ` contact.path_len != 0` unchanged (` ReticulumLink::get_contacts()` already
encodes daemon-reported reachability into ` path_len`).
- ` data_dir: &Path` threaded through ` run_mesh_session` → both probe functions.
- ` core/archipelago/src/mesh/reticulum.rs` — **created**. ` ReticulumLink`: spawns/supervises the
daemon as a child process, Unix-socket RPC client (matches the tested daemon contract),
` prefix_to_hash: HashMap<[u8;6],[u8;16]>` (mandatory per the plan), synthetic
` InboundFrame` builder byte-matching ` meshtastic.rs`'s layout, ` Drop` impl that kills the
daemon + cleans up the socket. Has unit tests (KISS-detect byte matching, contact-id masking,
synthetic-frame layout) — **passing, see below**.
**Concurrent-edit note:** a separate in-flight change (not mine) added ` MeshPeer.pkc_capable`
and ` ParsedContact.pkc_capable` (Meshtastic PKI-capability tracking) while this work was in
progress. Accounted for: ` reticulum.rs`'s ` ParsedContact` literal sets ` pkc_capable: false`
(Reticulum/LXMF is unconditionally E2E via ` take_rx_encrypted()`, this field has no analogue);
two incomplete ` MeshPeer` literals in ` decode.rs` (lines ~330, ~548) were completed with
` pkc_capable: false` to unblock the build for everyone — not reverted, not worked around.
**Self-review fix applied:** the RPC Unix socket originally lived in the shared system temp
dir; moved to ` {data_dir}/reticulum/` (0700) instead — archipelago-owned, not shared ` /tmp`,
matching the security posture. Re-confirmed ` cargo check -p archipelago` GREEN after the move.
**NOT yet done:**
- ` MeshConfig.device_kind: Option<DeviceType>` hint (optional reflashable-board disambiguator,
plan §2c) — not added. Auto-detect ordering (Meshcore→Meshtastic→Reticulum, strict probes)
is the only disambiguator right now.
- Phase 3 frontend — **DONE**, but **smaller scope than originally inventoried**: only
` Mesh.vue`'s ` transportLabel()` (per-message field) + ` mesh-styles.css` ` .transport-reticulum`
+ the ` mesh.ts` doc comment needed the addition. ` transport.ts` ` TransportKind`,
` federation/types.ts` ` last_transport`, ` NodeList.vue` ` transportBadge`, and ` PeerFiles.vue`
` transportPill` are a COARSER routing-layer category (` mesh`/` lan`/` fips`/` tor`) where
` 'mesh'` already covers any radio (meshcore/meshtastic/reticulum) — adding a separate
` 'reticulum'` there would be inconsistent with how meshcore/meshtastic are handled. Confirmed
via ` vue-tsc --noEmit` (exit 0, zero errors).
- Everything hardware-dependent: real daemon spawn/probe against an actual RNode (the .116
Heltec V3, once reflashed), two-node LXMF-over-LoRa, the ` _announce_app_data` signed-identity
TODO in the daemon (currently carries only the plaintext display name, not a verified Archy
DID/pubkey — needed for ` bind_federation_twins`-style auto-binding across protocols).
## Verified facts to reuse (don't re-derive)
**RNode KISS-detect handshake** (confirmed against the canonical Reticulum source, not guessed):
` ``
constants: FEND=0xC0 FESC=0xDB TFEND=0xDC TFESC=0xDD CMD_DETECT=0x08 DETECT_REQ=0x73 DETECT_RESP=0x46
probe tx: C0 08 73 C0 50 00 C0 48 00 C0 49 00 C0 (detect + fw_version + platform + mcu queries)
success: response contains byte sequence ... C0 08 46 ... (FEND, CMD_DETECT, DETECT_RESP)
` ``
Source: ` RNS/Interfaces/RNodeInterface.py` (Liberated Systems mirror), ` detect()`/` readLoop()`.
**Synthetic ` InboundFrame` layout** for a 1:1 DM, copied exactly from
` meshtastic.rs:1031-1047` (` ReticulumLink` must build the same shape so ` frames::handle_frame`
needs zero changes):
` ``
data = [snr(1)=0][reserved(2)=00,00][sender_prefix(6)][path(1)=0xff][type(1)=0][rx_time(4 LE)][payload…]
code = RESP_CONTACT_MSG_V3_E2E if encrypted else RESP_CONTACT_MSG_V3 (RNS/LXMF is always E2E, so always _E2E)
` ``
Channel/broadcast equivalent (` RESP_MESHTASTIC_CHANNEL_TEXT`, meshtastic.rs:1019-1028) — N/A for
Reticulum in single-device Phase 2 (LXMF has no shared-channel concept); revisit in Phase 4.
**` resolve_peer`** (decode.rs:316) matches inbound ` sender_prefix` against
` peer.pubkey_hex.starts_with(prefix)` — so as long as ` refresh_contacts`/announce-handling
populates ` pubkey_hex` = full 16-byte RNS hash hex BEFORE a message arrives (same precondition
meshtastic relies on via its ` peer_pubkeys` map), no Reticulum-specific fallback is needed there.
**` ParsedContact.public_key_hex`** for Reticulum = hex of the 16-byte RNS dest hash (32 hex
chars, NOT 32 bytes) — the ` hex::decode(...).len()==32` checks elsewhere (e.g. the auto-heal
` reset_contact_path` loop in ` refresh_contacts`) will naturally skip Reticulum contacts since
their key decodes to 16 bytes, not 32. That's fine — no special-casing needed, just don't "fix"
it to be 32 bytes.
**` data_dir.join("identity").join("node_key")`** is the 32-byte raw Ed25519 seed file — this is
exactly what ` reticulum_daemon.py --identity-key <path>` expects (confirmed against
` identity.rs` ` NODE_KEY_FILE`/` load_or_create`). The daemon reads the file itself — Rust should
pass the **path**, not pipe the raw key bytes through more hops than already exist.
## Hardware update (2026-06-30)
**.116 has a Heltec V3 available to reflash with RNode firmware.** This unblocks Phase 0 gates
#2/#3 (previously marked blocked — ` .198`'s radio is dead, but .116's Heltec V3 is a real path
forward without needing new hardware). Next concrete step once reflashed: run
` reticulum-daemon/reticulum_daemon.py` pointed at the RNode's serial path, confirm ` --check`
hash matches ` --selftest`, then bring up two instances (.116 + .228, after .228 also gets an
RNode-capable board) for the real two-node LXMF-over-LoRa gate.
## Daemon contract (already built + tested — Phase 2 codes against this, no changes needed)
` reticulum-daemon/reticulum_daemon.py`, RPC over Unix socket (0600), one JSON object per line:
- in: ` {"cmd":"send","dest_hash":hex16,"content":...}` / ` {"cmd":"announce"}` /
` {"cmd":"status"}` / ` {"cmd":"shutdown"}`
- out: ` {"event":"ready",...}` / ` {"event":"recv",...}` / ` {"event":"announce",...}` /
` {"event":"delivered",...}` / ` {"event":"status",...}`
Verified: ` --check` (hash only), ` --selftest` (boots real RNS+LXMF, no radio), and a live
socket round-trip (` ready`→` status`→` shutdown`, clean exit) — see ` reticulum-daemon/README.md`.
## Checkpoint 2026-06-30 (hardware session — gates #2/#3 PASSED)
Picked up after a session pipe-break; the live system (archipelago.service + the spawned
` archy-reticulum-daemon`) had kept running uninterrupted the whole time, so nothing was lost.
**What happened, in order:**
1. .116's Heltec V3 (CP2102, USB vendor/product ` 10c4:ea60`, serial ` 0001`) was reflashed with
RNode firmware and plugged into ` /dev/mesh-radio` (generic udev symlink → ` ttyUSB0`, not a
per-serial rule). ` mesh-config.json` has ` device_path: null` — pure auto-detect, no
` device_kind` pin needed.
2. Auto-detect correctly tried Meshcore → Meshtastic → Reticulum and found it: journal shows
` Found Reticulum (RNode) device via auto-detect path=/dev/mesh-radio` — but only **after**
~4 min of ` Failed to spawn reticulum-daemon — is it installed/packaged?` retries, because
` /usr/local/bin/archy-reticulum-daemon` hadn't been copied into place yet from
` reticulum-daemon/dist/` (built via ` ./build.sh`). Once copied (sha256-verified match to the
` dist/` build), auto-detect succeeded on the very next retry.
3. ` mesh.status` RPC confirmed live: ` device_type: "reticulum"`, ` device_connected: true`,
` dest_hash: 5d146f6e1c9707f89468b5016ed6dfad`. Periodic self-advert (` send_self_advert` →
` {"cmd":"announce"}` → real RNS ` Identity.announce()`) firing every ~30s — confirmed this is
**not** the ` send_nodeinfo_advert` no-op arm (that one's still legitimately a no-op for
Reticulum; the real announce path is ` send_self_advert`, wired correctly).
4. Second RNode flashed onto a phone running **Sideband**. First attempt showed RF energy
(` interference_last_dbm` climbing) but ` rxb: 0` — a parameter mismatch, **not** a frequency
problem (energy was detected, just not demodulated). Root cause: Spreading Factor mismatch
in Sideband's manual RNode interface config (frequency display rounds to one decimal so
"869.5" silently passed at first glance — bandwidth/SF/CR are separate fields and SF was
wrong). Once SF was corrected to match (freq ` 869525000`, BW ` 125000`, **SF ` 8`**, CR ` 5`),
` rxb` went non-zero immediately and a real ` {"event":"announce","dest_hash":"1870744d...",
"app_data":"7a617a61"}` (hex for "zaza") arrived over the air.
5. **Gate #2 + gate #3 both passed in the same exchange**: ` zaza` shows up as a real, reachable
` mesh.peers` contact; an inbound encrypted LXMF message ("Yoooo") arrived and was correctly
stamped ` encrypted: true, transport: "reticulum"`; a reply was sent back and round-tripped.
Sideband is exactly the stock external client gate #3 calls for, so one real RNode-to-RNode
LoRa link covered both gates — no need for a second dedicated archy node.
6. **Two real bugs found from this, both fixed:**
- ` record_sent_typed`'s ` encrypted` flag was hardcoded ` false`/` archy || pkc_capable` on the
Reticulum send path (both the native-text path in ` send_message` and the typed-envelope
path in ` send_typed_wire`) — correct for Meshcore/Meshtastic (where E2E really is
conditional on PKI/session state not yet threaded through), **wrong** for Reticulum: LXMF
encrypts every send to the destination identity key unconditionally, archy peer or not.
Fixed: both call sites now OR in ` device_type == DeviceType::Reticulum`.
- ` radio_transport_label()` collapsed Meshcore **and** Meshtastic into one generic ` "lora"`
string, so the per-message pill couldn't distinguish them. User asked for 3 distinct pill
colors (Meshtastic mint, Meshcore orange, Reticulum blue) — extended the label fn to
return ` "meshtastic"`/` "meshcore"`/` "reticulum"` distinctly, updated ` Mesh.vue`'s
` transportLabel()` switch and ` mesh-styles.css` (` .transport-meshtastic` ` #3eb489 `,
` .transport-meshcore` ` #fb923c `, ` .transport-reticulum` ` #60a5fa `; kept ` .transport-lora`
` #f59e0b ` as a fallback for any already-stored legacy-labelled messages). ` cargo check` +
` vue-tsc --noEmit` both green after.
**NOT yet done:**
- The Rust-side fix above (` encrypted` flag, transport-label split) is built but **not yet
deployed to .116's running binary** — the live daemon/auto-detect verification above was all
against the binary already running before this session's edits. Rebuild + redeploy to see the
fix live.
- ` tests/lifecycle/run-gate.sh` not re-run after these mesh changes yet (project convention:
run after backend changes land).
- Multi-device (3 radios at once, Phase 4) and the release-tarball/udev-rule wiring (originally
"Next up" #6 below) are both still untouched.
## Next up (resume here)
Phase 0 gates #1–
1. Rebuild the backend + frontend and redeploy to .116 so the ` encrypted`-flag fix and the
3-way transport-pill color split actually take effect on the live node (currently only
checked in with ` cargo check`/` vue-tsc`, not deployed).
2. Re-verify on-device after redeploy: send another Sideband↔archy DM, confirm the Sent bubble
now shows E2E + a blue "Reticulum" pill, and confirm Meshtastic/Meshcore pills (if any
messages exist) render mint/orange instead of the old generic amber "LoRa".
3. Exercise the rest of the plan's "Verification (definition of done)" items: hot-swap
detection (unplug the RNode mid-session, confirm fallback to FIPS/Tor on the same contact;
replug, confirm it picks Reticulum back up), and ` device_kind: Some(Reticulum)` pin path
(currently only auto-detect has been exercised on real hardware).
4. Run ` tests/lifecycle/run-gate.sh` to confirm no regression from the mesh changes landing.
5. Only after the above: wire ` dist/archy-reticulum-daemon` into the release tarball /
` scripts/deploy-to-target.sh` (target path ` /usr/local/bin/archy-reticulum-daemon`, matching
` reticulum.rs`'s default) and add a per-serial-number ` /dev/reticulum-radio` udev rule now
that a real board's serial number (` 0001` on the CP2102, .116's board) is known — though a
second board will likely report the same ` 0001` stock serial since CP2102 modules commonly
ship with an unprogrammed default, so this may still need a different disambiguator.
6. Phase 4 (run all 3 radios at once) — still not started, follow-on after the above.
2026-07-03 18:08:35 +00:00
## Checkpoint 2026-07-03 — Phase 5: Aurora interop via plain-TCP Reticulum (radio-less)
**Why:** ` ~/aurora` (a separate Flutter off-grid messenger) already runs real RNS + LXMF
(` LxmfRouter`, comment "interop with Sideband/NomadNet/MeshChat" in ` rns_service.dart`), and its
**default** connectivity mode is plain TCP (` RnsTcpInterface`/` RnsTcpServerInterface`), not radio —
it ships a static bootstrap list of public RNS hubs on port 4242. Archy's daemon could previously
only bring up a serial-RNode interface, so it was unreachable by Aurora (or any TCP-based RNS/LXMF
client) at all, and every interop proof was bottlenecked on scarce LoRa hardware. This phase adds
an **optional, additive, loopback-only plain-TCP interface**, proves interop with a scripted
RNS/LXMF stand-in (the same class of proof the Sideband gate already established), and leaves the
serial/RNode path completely unchanged.
**Done, all verified:**
1. ` reticulum-daemon/reticulum_daemon.py` — ` _write_rns_config()` gained a third branch
(` --tcp-listen HOST:PORT` → ` TCPServerInterface`, ` --tcp-connect HOST:PORT` repeatable →
` TCPClientInterface`), mutually exclusive with ` --serial-port`. ` --tcp-listen` is hard-gated to
loopback (` _require_loopback`) — archy is otherwise Tor-first for inter-node traffic, so a
WAN/LAN-exposed Reticulum port is a deliberate future decision, not something this phase does
silently. Verified: ` --selftest` regression still passes; two daemon processes (server +
client, throwaway identities) reached ` connected: true` on both sides via ` mesh.status`-daemon
RPC, live ` TCPServerInterface`/` TCPClientInterface` visible in ` get_interface_stats()`.
2. **Bidirectional LXMF DM gate against a scripted Aurora stand-in** (Python RNS+LXMF client
dialing as a ` TCPClientInterface` + running its own ` LXMRouter` — a legitimate protocol-level
proxy for Aurora's Dart stack, same wire format): forward (stand-in → archy daemon) and reverse
(archy daemon → stand-in) both delivered with matching content and correct source/dest hashes,
confirmed via the daemon's own ` recv`/` delivered` RPC events. Direct TCP analogue of the
already-passed Sideband gate (RF → TCP, Sideband → scripted stand-in).
3. **Rust wiring**, fully additive — the serial/RNode path is byte-for-byte unchanged:
- ` mesh/reticulum.rs`: new ` ReticulumInterface` enum (` Serial`/` TcpServer`/` TcpClient`) threads
through ` daemon_command()`/` spawn()`; ` open()` (serial) now just wraps
` ReticulumInterface::Serial` — same ` probe_rnode` gate as before. New
` open_tcp_server()`/` open_tcp_client()` associated fns skip ` probe_rnode` entirely (the
"spawn without a physical RNode" path); ` open_tcp_server` hard-enforces
` is_loopback_host()` (mirrors the Python-side guard).
- ` mesh/types.rs`: new ` ReticulumTcpConfig` enum (` Server { bind }` / ` Client { connect }`).
- ` mesh/mod.rs`: ` MeshConfig.reticulum_tcp: Option<ReticulumTcpConfig>` (` #[serde(default)]`,
` None` by default — no migration, zero behavior change when unset); threaded into
` start()` → ` spawn_mesh_listener`.
- ` listener/mod.rs` / ` listener/session.rs`: ` reticulum_tcp` param threaded through
` spawn_mesh_listener`/` run_mesh_session`; new leading branch — if set, a new
` open_reticulum_tcp()` helper dispatches to ` open_tcp_server`/` open_tcp_client`; otherwise
falls through to the **untouched** existing ` preferred_path`/` auto_detect_and_open` logic.
- Deliberately **not** wired into ` mesh.configure`/the frontend — dev/verification-only surface
for now (hand-edit ` mesh-config.json`), consistent with how narrowly scoped this phase is.
- ` cargo check -p archipelago` + ` cargo test -p archipelago` (mesh module): **108 passed, 0
failed, 1 ignored** (the pre-existing hardware-gated ` probe_rnode_detects_real_hardware`) —
zero regression to the serial/RNode path, provable without any hardware.
4. **End-to-end Rust integration test** (` mesh::tests::mesh_service_connects_over_reticulum_tcp_client`,
` #[ignore]`d — spawns real subprocesses, skipped in the default ` cargo test` run the same way
the rest of the mesh suite skips hardware-gated tests): a real ` MeshService::start()` spawns the
daemon in TCP **client** mode (no serial probe at all), dials a second stand-alone daemon
instance in TCP **server** mode (the Aurora-side role), and reaches ` device_connected: true` /
` device_type: Reticulum` via the exact ` MeshService::status()` call the ` mesh.status` RPC uses.
Passed in ~2.6s. Run manually: ` cargo test -p archipelago -- --ignored
mesh_service_connects_over_reticulum_tcp` (needs ` reticulum-daemon/.venv`, see below).
**Environment note:** this session's Rust toolchain drift — system ` rustc` (apt, 1.85.0) is too
old for code already on ` main` (` u32::is_multiple_of` in ` health_monitor.rs`, stabilized upstream
after 1.85); a pre-installed rustup toolchain at
` ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu` (1.96.0) builds clean. Not something this
phase's changes caused — pre-existing, just newly hit. Put that toolchain's ` bin/` first on ` PATH`
if ` cargo check`/` test` reports ` E0658 unsigned_is_multiple_of`.
**Explicitly NOT done (out of scope for this phase, see plan non-goals):**
- Real Aurora Flutter GUI verification — this dev sandbox has no ` flutter`, no ` $DISPLAY`, and no
` reticulum-dart` sibling checked out (Aurora's actual RNS implementation lives in that separate
repo; Aurora's CI clones it fresh at build time). The scripted-stand-in gate above is the
protocol-level substitute. **Manual follow-up**: point a real Aurora build's TCP hub list (or an
ad hoc connect) at an archy node's ` --tcp-listen` address and confirm an LXMF DM in the actual
app UI.
- Any non-loopback (LAN/WAN) TCP bind — hard-gated off on purpose; a real "Aurora hub" deployment
needs its own security review given archy's Tor-first posture for inter-node traffic.
- LXMF propagation-node / always-on-hub role for archy (bridging Aurora's offline BLE peers) —
bigger architectural + storage commitment.
- Identity unification between archy's and Aurora's independent Nostr/secp256k1 keys — both
already have separate Nostr identities with no derivation link; out of scope here.
- ` mesh.configure` RPC / frontend exposure of ` reticulum_tcp` — stays hand-edit-only until/unless
it becomes user-facing.
