jlpoole/reticiulum-specification
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
reticiulum-specification/flows/transport-data.md
John Poole 9c3b628c6a Worked for 4m 50s 
Completed the destination-routed DATA and reverse-PROOF three-tier unit.

Key findings:

Intermediate relays retarget HEADER_2; the final relay delivers HEADER_1.
Each relay records independent reverse-table state.
PROOF destination hashes remain invariant across transport transformations.
A wrong-interface PROOF consumes the reverse entry before being dropped.
REVERSE_TIMEOUT is 480 seconds, not 30 seconds.
Added Tier 1 audit, two-relay flow, deterministic vectors, regenerator, and runtime verifier. Corrected affected specification, flows, playbook, and status documentation.

Verification:

Deterministic regeneration: identical SHA-256
Full pinned suite: 22 passed, 0 failed
git diff --check: passed
No commit created.
2026-06-08 18:32:26 -07:00

2.3 KiB
Raw Blame History

Flow: Destination-Routed DATA Through Transport Relays

This flow follows ordinary DATA and its returning PROOF across two transport relays, pinned to RNS 1.2.4. Opportunistic LXMF is the common example.

Forward DATA

  1. The originator emits HEADER_2 because its path has more than one hop. The transport_id names relay 1; the final destination hash remains in the second address slot.
  2. Relay 1 verifies that transport_id names itself and finds the final destination in path_table.
  3. With more than one remaining hop, relay 1 increments hops, replaces transport_id with relay 2's identity hash, and preserves HEADER_2.
  4. Relay 1 records reverse_table[packet.getTruncatedHash()] with the ingress and egress interfaces.
  5. Relay 2 receives the retargeted HEADER_2 packet. With one remaining hop, it increments hops, strips the transport slot, and emits HEADER_1 toward the destination.
  6. Relay 2 records its own reverse entry under the same truncated packet hash.

The hash is stable because Packet.get_hashable_part() excludes hops, transport type/header type, and the HEADER_2 transport-id slot.

Returning PROOF

  1. The destination emits a HEADER_1 PROOF addressed to the original DATA packet's truncated hash.
  2. Relay 2 pops that hash from reverse_table. If the PROOF arrived on the recorded outbound interface, it increments hops and sends toward relay 1.
  3. Relay 1 repeats the operation and sends toward the originator.
  4. Each entry is one-shot. A duplicate PROOF has no route.

Failure Diagnostics

Observation Meaning
First relay receives DATA but does not forward it Check HEADER_2 transport_id and relay path_table.
Intermediate relay forwards HEADER_2 but final endpoint parser expects HEADER_2 Endpoint receives HEADER_1; the last relay strips the transport slot.
DATA reaches endpoint but no PROOF returns Inspect every relay's reverse entry and recorded interfaces.
PROOF appears first on the wrong interface Upstream drops it after popping the reverse entry; a later correct copy cannot return.
Reverse entry remains indefinitely in a clean-room relay RNS 1.2.4 expires it after 480 seconds or when a recorded interface disappears.

Executable evidence: tools/verify_transport_data.py and test-vectors/transport-data.json.