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 explicit CANT_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.

@diasdavid @whyrusleeping @lgierth