reticiulum-specification/flows
Rob cfd0d8249b Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift
Upstream RNS 1.2.4 (2026-05-07) announces it is "probably the last
release that is also published to GitHub" — pip continues until rnpkg
is complete and RNS is self-hosting. All 13 verifiers pass against
1.2.4 / 0.9.7; no wire-format, signing, or protocol behavior changed
between 1.2.0 and 1.2.4, so the changes here are purely currency:

- Pin tools/requirements.txt to rns==1.2.4 / lxmf==0.9.7 so the
  verifier stays reproducible if upstream stops mirroring to PyPI
  before the migration is ready.
- Add an "Upstream distribution shift" watch-list to todo.md (local
  Reticulum node, repo destination hash, rnpkg install/upgrade
  commands, rsg signature verification, mirroring source citations).
- Bump SPEC.md frontmatter and re-anchor ~50 line citations across
  Identity.py, Transport.py, Resource.py, Link.py, Reticulum.py,
  Packet.py, and LXMF/* (Identity.py drift was the heaviest at +13
  to +31 lines; Transport.py was variable). Fix one numeric
  (MAX_RANDOM_BLOBS = 32 → 64) and one semantic (§6.6.3 LRPROOF MTU
  clamp citation pointed at the wrong location — corrected to point
  at the transit-relay clamp at Transport.py:1539-1556).
- Update §10.4 decompression-bomb hazard to note upstream's 1.1.9 cap
  adoption, with citations to Resource.py:686-691 and Buffer.py:95-97
  plus a "do not use one-shot bz2.decompress()" warning.
- Re-anchor 11 flows/ files (version pins + ~30 line citations).
- Bump version labels in tools/README.md, test-vectors/README.md, and
  4 verifier docstrings + 2 hardcoded print strings.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-08 07:42:25 -04:00
..
forward-announce.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
path-discovery.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
README.md Add four more verifiers + receive-propagated flow + frontmatter version 2026-05-03 12:54:34 -04:00
receive-announce.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
receive-link-lxmf.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
receive-opportunistic-lxmf.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
receive-propagated-lxmf.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
receive-resource.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
send-announce.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
send-link-lxmf.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
send-opportunistic-lxmf.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
send-propagated-lxmf.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00
send-resource.md Re-anchor against RNS 1.2.4 / LXMF 0.9.7 + track upstream distribution shift 2026-05-08 07:42:25 -04:00

Flows

End-to-end chronological narratives for common Reticulum operations. Where SPEC.md is organized by layer (identity, header, token crypto, announce, LXMF, link, transport, framing), the documents here are organized by operation and walk through what each layer contributes in order — app-call → wire bytes.

The two views are complementary: SPEC.md tells you what each piece looks like; the flows tell you when each piece runs and what calls what. A flow document should not introduce new normative claims — every byte-level detail should be a cross-reference to the relevant SPEC.md section. If you find yourself describing wire bytes here that aren't in SPEC.md, that's a sign the spec has a gap to fill.

Status

Flow Status
send-opportunistic-lxmf.md
receive-opportunistic-lxmf.md
send-link-lxmf.md (DIRECT method, over a Reticulum Link)
receive-announce.md
send-resource.md (Resource fragmentation over a Link)
path-discovery.md (path? request, path-response wire detail, path-table population)
receive-resource.md (inverse of send-resource: ADV ingestion, part assembly, proof emission)
receive-link-lxmf.md (inverse of send-link-lxmf, including responder side of the handshake)
send-announce.md (build, sign, transmit, ratchet rotation, periodic re-announce)
forward-announce.md (transport-node rebroadcast logic, announce_cap, queue)
send-propagated-lxmf.md (PROPAGATED method, via a propagation node)
receive-propagated-lxmf.md (recipient pulling messages via /get)

Conventions

  • Each flow targets one specific upstream operation. send-opportunistic-lxmf.md documents what LXMRouter.handle_outbound(lxm) does for an opportunistic message; it does not also cover Link or propagation paths — those get their own docs so the chronology stays linear.
  • Numbered steps are chronological. Each step that produces wire bytes cross-references the SPEC.md section that defines those bytes.
  • Source citations use the standard pip install rns lxmf install layout (RNS/, LXMF/) with file + line. Line numbers are pinned to the RNS / LXMF version named at the top of each flow; out-of-date line numbers should be fixed in a PR.
  • "Verified" claims must be backed by a tools/ script per ../agent.md §1. Flow docs inherit the verification status of the SPEC.md sections they reference — if a flow step relies on an unverified SPEC.md callout, the flow should mark that step as inheriting the unverified status rather than silently treat it as fact.