-
Notifications
You must be signed in to change notification settings - Fork 294
Description
Having separate multistream endpoints for hop
and stop
allowed to quickly determine if a peer had relay capabilities, with the removal of the separate multistream endpoints this isn't possible anymore.
@vyzo and myself discussed the possibility of adding a new message type that would allow determining if a host is a relay or isn't. This is crucial functionality as it would otherwise require to resort to ugly hacks to know which hosts are relays and which aren't.
A couple I can think of:
- Send a
HOP
message with an invalid peer id (or somesuch) and check for an explicitCANT_SPEAK_RELAY
response code, if its something else then assume it is a relay. - A (arguably) worst way would be to simply dial every peer in the peerbook asking to relay to the desired destination, this is both slow and generates unnecessary load on the network.
In the current js implementation, I was trying over the hop
endpoint on every incoming connection and adding it to an internal relay table that I would use when dialing over a relay address. This is IMO more efficient and cleaner.
This proposal tries to address this shortcomings by adding an explicit CAN_HOP
message that would allow quickly asking a peer if it is a relay.
The CAN_HOP
message either succeeds or fails and doesn't provide any additional information, leaving further capability discovery functionality to the already proposed ls
protocol - ipfs/notes#237.