[identify] Handling of asymetrical protocols

[D4nte]

Given an asymmetrical protocol foo/bar where Alice only supports initiating a query to Bob and Bob only supports responding to a request of said protocol.

Currently, the identify protocol does not include valuable information. Indeed, the specs reads:

protocols This is a list of protocols supported by the peer.

In the case of Carole, who only support initiating query of foo/bar protocol. Once she finishes the identify protocol with Alice, both Carole and Alice may think they can initiate the query with the other, when it is not the fact.

One idea I had was simply for Alice and Carole to not include foo/bar in the Identify message they send. I am not sure of the ramifications of such design.

What are your thoughts on the matter?

[mxinden]

One idea I had was simply for Alice and Carole to not include foo/bar in the Identify message they send. I am not sure of the ramifications of such design.

Yes, this is the libp2p best practice. Implementations doing this today:

• The (go-)libp2p Kademlia implementation differentiates in client mode and server mode. In client mode a node sends queries but does not answer them. In client mode the node would not include /ipfs/kad/1.0.0 in its identify protocol list nor its ls multistream-select responses. See also https://github.com/libp2p/rust-libp2p/issues/2032.

• The circuit relay v2 protocol differentiates nodes in two roles: clients which are at either end of a relayed connection and relays which are in-between relaying the data between two clients. The two clients would advertise the /libp2p/circuit/relay/0.2.0/stop protocol, the relay would advertise the /libp2p/circuit/relay/0.2.0/hop protocol in the identify protocol.

Does the above make sense to you @D4nte? If so, would you mind sending in a patch to update the identify protocol specification in this repository?

[D4nte]

Great answer, thank you very much.

[D4nte]

Closing, will reopen if further questions arise.