# 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
`mesh/meshtastic.rs` + `mesh/protocol.rs` (see `docs/SESSION-1.8.0-OTA-PROGRESS.md`) and explicitly
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–3) |
| 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). |

## 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–#3 are now **all passed**. What's left:

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.

## 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.