C01-RT: Yes
Rationale
A Reticulum SINGLE destination retains its hash when the same identity and destination name are announced through another authorized interface. Destination.announce can select an interface; the pinned Transport code can replace the stored next hop and receiving interface from a fresh valid announcement. Thus a failed destination attachment can be replaced by another serial attachment without the sender substituting the destination hash.
Assessment method
Primary specification review; no runtime experiment
Source context
Tor onion-service protocol and pinned Reticulum 1.5.5 announcement routing
Outstanding qualification
Retain the destination identity/name, provision the alternate serial path and IFAC credentials, and emit an accepted fresh announcement through reachable transport nodes. Update acceptance depends on timestamps, hop count, unresponsive/expired-path state and announce rate limits; propagation is not instantaneous. The sender may discover the path again and establish a fresh Link with the same destination. This is destination-attachment recovery, not merely transit repair, and does not imply survival of an existing Link, simultaneous multipath, an availability deadline or global-scale capacity. Source review only.
Public sources
- https://reticulum.network/manual/networks.html#destinations-not-addresses
- https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Destination.py
- https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round526.html
- round526-sources.json