C01-MT: Yes
Rationale
A Meshtastic destination can retain its NodeID and confirmed public key while losing its old radio adjacency and joining another reachable relay neighborhood. The packet destination is separate from the learned next hop. In the selected firmware, an unsuccessful directed delivery clears the next-hop preference on the final retry and sends through managed flooding, permitting discovery of the same destination through its new adjacency without application address replacement.
Assessment method
Primary documentation and pinned source review; no runtime experiment
Source context
Meshtastic directed/flooded forwarding and NET/ROM destination/neighbor route separation
Outstanding qualification
Bounded documentary witness: the same configured device moves within a connected, compatible LoRa mesh with relaying CLIENT nodes, matching channel/radio settings and sufficient hop budget. The alternative must reach the new neighborhood and allow replies; finite retries, airtime and loss can delay or prevent an individual delivery. A subsequent transmission is allowed. No claim of seamless sessions, recovery through a persistent partition, arbitrary global reachability or automatic authorization. NodeID addressing alone does not authenticate a peer: the selected confirmed-key policy remains necessary. No MQTT, IP bridge or store-and-forward extension is added. No runtime experiment.
Public sources
- https://meshtastic.org/docs/overview/mesh-algo/
- 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.
- round531.html
- round531-sources.json