F35-MT: Yes
Archived previous-definition assessment — revision 5.73. Retired in 5.82; excluded from the active matrix and counts. This historical verdict is not a current assessment.
Rationale
The selected Meshtastic firmware can relay packets at an intermediate CLIENT node. Adding a compatible LoRa relay between existing endpoints extends the reachable radio path while their firmware, identities and serial-client applications remain unchanged. Initial direct-message discovery can use managed flooding before learning a next hop.
Assessment method
Primary specification review; no runtime experiment
Source context
Official Tor and SCION documentation and pinned Meshtastic firmware
Outstanding qualification
Before/after witness: deploy one intermediate CLIENT/ALL node where each radio leg is viable, with matching radio parameters and sufficient preconfigured hop budget. Preserve private-channel provisioning, STRICT policy and independently verified endpoint keys; provision needed trust records on the added node. Firmware suppression, next-hop state, airtime and bidirectional ACK reachability still affect delivery. No MQTT/IP bridge, store-and-forward service, unlimited range, lossless delivery or endpoint firmware upgrade is included. Real LoRa hardware remains required. This uses the existing CLIENT/ALL witness, not a change to the separate F16 KNOWN_ONLY policy.
Public sources
- https://meshtastic.org/docs/overview/mesh-algo/
- https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/FloodingRouter.cpp
- https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round524.html
- round524-sources.json