Include Protocols in PeerInfo Broadcast

[justin0mcateer]

The service is broadcasting a PeerInfo event, but not populating the 'protocols' attribute. This information is available and could be used to proactively update the PeerStore with protocols as we discover Peers. This would seem to speed up the overall process of learning about a Peer and what protocols it supports, very similarly to Identify 'Push'.

This could be implemented with a very small PR, which I would be happy to provide. Is there any reason this couldn't/shouldn't be done?

[maschad]

This information is available

Where would you retrieve it from? A peer would only know what protocols to advertise during negotiation which is after initiating a new stream.

[justin0mcateer]

The PeerStore has a list of the supported protocols for the local peer in the PeerInfo.protocols attribute. This is the same source the Identify protocol uses to return the list of protocols supported by the node.

[maschad]

A few things to note:

The service is broadcasting a PeerInfo event

This discovery module actually broadcasts an encoded protobuf RPC message to all other peers subscribed to that topic.

This information is available and could be used to proactively update the PeerStore with protocols as we discover Peers.

When a peer that is subscribed to the topic receives such an RPC message, the message is decoded and the peerID is derived from the public key but at that point the node running this discovery service does not have access to that newly discovered peer's PeerStore, and so it cannot dispatch a PeerInfo Event containing the protocols, thus identify/identify push is used to discover these.

[justin0mcateer]

The node doing the broadcasting would send its own protocols, in the GossipSub message. Are you suggesting that a peer receiving the broadcast is not capable of storing the protocols for the remote peer at the time the broadcast is received?

…

________________________________ From: Chad Nehemiah ***@***.***> Sent: Thursday, August 10, 2023 8:54:13 PM To: libp2p/js-libp2p-pubsub-peer-discovery ***@***.***> Cc: justin0mcateer ***@***.***>; Author ***@***.***> Subject: Re: [libp2p/js-libp2p-pubsub-peer-discovery] Include Protocols in PeerInfo Broadcast (Issue #106) A few things to note: The service is broadcasting a PeerInfo event This discovery module actually broadcasts<https://github.com/libp2p/js-libp2p-pubsub-peer-discovery/blob/master/src/index.ts#L157-L162> an encoded<https://github.com/libp2p/js-libp2p-pubsub-peer-discovery/blob/master/src/peer.ts#L19-L70> protobuf RPC message<https://github.com/libp2p/specs/blob/d2106f43e878ae4c3a1c6465a7c329835290fe22/pubsub/README.md?plain=1#L111-L125> to all other peers subscribed to that topic. This information is available and could be used to proactively update the PeerStore with protocols as we discover Peers. When a peer that is subscribed to the topic receives such an RPC message<https://github.com/libp2p/js-libp2p-pubsub-peer-discovery/blob/master/src/index.ts#L178>, the message is decoded and the peerID is derived from the public key<https://github.com/libp2p/js-libp2p-pubsub-peer-discovery/blob/master/src/index.ts#L191-L205> but at that point the node running this discovery service does not have access to that newly discovered peer's PeerStore, and so it cannot dispatch a PeerInfo Event containing the protocols, thus identify/identify push is used to discover these. — Reply to this email directly, view it on GitHub<#106 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAT4Q7KASH5Q4RZBOEFXSD3XUWGELANCNFSM6AAAAAA3LLXFLM>. You are receiving this because you authored the thread.Message ID: ***@***.***>