F25-MT: Pending
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.
Historical wake-traffic inventory (cutoff retired)
Rationale
The selected Router.cpp supplies a concrete small-message candidate. For a direct PKI message with portnum 1, 128 useful payload bytes, explicit zero bitfield and other optional Data fields unset, protobuf encoding occupies 135 bytes: 2 for portnum, 3+128 for payload and 2 for bitfield. Adding the 16-byte Meshtastic header and 12-byte PKI overhead yields 163 bytes, below 255. perhapsEncode signs normal broadcasts rather than ordinary PKI unicasts; checkXeddsaReceivePolicy explicitly accepts the successfully decoded pki_encrypted branch even under STRICT without an additional XEdDSA signature. Two such messages would carry 256 useful bytes with a 326-byte radio-packet subtotal.
Assessment method
Source-path inspection and independent protobuf size calculation; no protocol execution
Source context
Pinned Meshtastic source and GNUnet 0.20.0 release; reviewed 2026-10-22
Outstanding qualification
Pending workload clarification: the owner has been asked whether 256 useful bytes may be delivered in multiple independent native messages. No answer or criterion change is inferred. The 326-byte subtotal excludes LoRa physical coding/preamble/header/CRC, wake-up broadcasts, node metadata, ACKs and other endpoint-facing traffic. It is not a complete F25 budget, fragmentation/reassembly capability, cryptographic execution or radio measurement. Retain independently verified peer keys and PKI-capable build; trace the complete one-hop wake-up configuration and preserve STRICT. A single 256-byte native message remains too large for the inspected path.
Public sources
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round420-sources.json
- round420-packet.json
- round420.html