Any endpoint can request another to act as a router to an endpoint it is attempting to link with. These routing requests are sent in a "type":"peer" unreliable channel. A peer request is typically generated as the result of having a peer path for any endpoint.
A peer open request contains a "peer":"fvif...irkq" where the value is the hashname the sender is trying to reach. In some cases the hashname may not be known yet and the peer request was the result of a router-generated URI, included as the "uri":"..." value.
The BODY of the open request must contain an attached packet with information for the specified peer. The BODY will be relayed by the routing endpoint to that peer who must validate the attached packet before processing or responding to it. The validation requires application trust similarly to processing handshakes.
The recipient of the peer request is called the router and must first qualify the specified peer value to make sure that it is able to establish a channel with it. It must also ensure that either the sender or peer endpoints have an active link and are trusted to provide routing for.
Once validated, the router relays the original BODY in a connect request to the peer.
No response is ever given to the peer channel; it should not error based on any validation so that the requesting endpoint cannot determine any information about the state of the peer. The channel should always silently timeout and clean up.
{
"c":10,
"type":"peer",
"peer":"fvif...irkq"
}
BODY: ...packet...The first time an endpoint is attempting a link with a new peer it might not have any information other than its hashname, so it cannot send encrypted handshakes. Instead, it must attach the handshakes unencrypted, with at least one of them including the sender's CSK. If the sender doesn't know the correct CSID it should open multiple peer channels, one with each key handshake it supports.
When the BODY contains an encrypted handshake packet the router should determine the ROUTING TOKEN value of the handshake and create a mapping of that token to the network path by which the peer request arrived. Any subsequent encrypted channel packets received with this token should be re-delivered to that network path, providing automatic bridging.
If a peer is willing to be a router for another peer to other unknown hashnames, it may generate a unique URI including an opaque session value and send it as a handshake to that peer. When the unknown hashname sends the router a handshake it must include the URI in a handshake so that the router can validate the session and accept correct peer requests from them. When the new hashname generates handshakes for the peer open it must also include a URI handshake again so that it can be re-verified by the destination peer.