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>
24 lines
2.3 KiB
Markdown
24 lines
2.3 KiB
Markdown
# Flows
|
|
|
|
End-to-end chronological narratives for common Reticulum operations. Where [`SPEC.md`](../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`](send-opportunistic-lxmf.md) | ✅ |
|
|
| [`receive-opportunistic-lxmf.md`](receive-opportunistic-lxmf.md) | ✅ |
|
|
| [`send-link-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.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`](../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.
|