F35-YG: 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
A configured peering between intermediate Yggdrasil nodes can join previously disconnected mesh regions while existing endpoints retain their node keys, native IPv6 addresses and application software. The pinned Ironwood peer-addition path registers the new port and peer and exchanges routing announcements and Bloom information, allowing existing routing logic to use the added connectivity.
Assessment method
Primary specification review; no runtime experiment
Source context
Pinned Yggdrasil/Ironwood and cjdns peering/forwarding sources
Outstanding qualification
Before/after witness: join two provisioned regions by adding an adjacent private-IPv4 TCP/TLS peering between transit nodes; endpoint attachments and software remain unchanged. Configure numeric contacts, pinned keys, listening permissions and reachable underlay links. The benefit is new inter-region connectivity after routing discovery, not a guaranteed preferred shortcut or uninterrupted sessions. No public peer, Internet transit, routed-subnet gateway, extra transport or global-capacity result is introduced. Existing endpoints already run Yggdrasil; this does not install the overlay transparently on legacy hosts. No runtime experiment.
Public sources
- https://yggdrasil-network.github.io/configuration.html
- https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/router.go
- https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/peers.go
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round523.html
- round523-sources.json