b43d735d97
receive-opportunistic-lxmf.md mirrors the send flow on the recipient side: KISS/HDLC deframe -> Transport.inbound -> packet_filter dedup -> DATA/SINGLE branch -> Destination.receive -> Identity.decrypt with the ratchet ring + long-term-key fallback -> LXMRouter.delivery_packet (which fires the PROOF receipt before parsing) -> LXMessage.unpack_from_bytes with msgpack stamp-strip -> ticket/stamp/dedup checks -> __delivery_callback to the app. Notes upstream's narrower variant tolerance vs SPEC.md §5.6 and the missing clockless-sender fix-up vs §9.6. send-link-lxmf.md walks the DIRECT method end-to-end: process_outbound DIRECT branch decides reuse-vs-establish, RNS.Link.__init__ builds the unencrypted LINKREQUEST body (initiator_X25519_pub || initiator_Ed25519_pub || optional signalling), link_id derived from get_hashable_part, LRPROOF arrives back and validate_proof verifies signature against the responder's long-term Ed25519 pub recalled from a prior announce, handshake() does ECDH+HKDF over the shared secret with salt=link_id, lxmessage.send sends the full LXMF body (with dest_hash, per §5.2) over the link with Token encryption that omits the eph_pub prefix per §3.1, mandatory PROOF receipts per §6.5 resolve the PacketReceipt. Sketches the RESOURCE representation for oversize bodies and the backchannel-identify trick that makes the link bidirectional. flows/README.md status table updated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.3 KiB
2.3 KiB
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-link-lxmf.md (inverse of send-link-lxmf, including responder side of the handshake) |
⏳ |
send-propagated-lxmf.md (PROPAGATED method, via a propagation node) |
⏳ |
announce.md (build, sign, transmit, ratchet rotation) |
⏳ |
path-discovery.md (request, response, path-table population) |
⏳ |
Conventions
- Each flow targets one specific upstream operation.
send-opportunistic-lxmf.mddocuments whatLXMRouter.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 lxmfinstall 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.