js-libp2p currently uses peer-info to keep a record of the known protocols and multiaddrs of each peer. With the new peerstore, we intend to use it to map protocols and multiaddrs instead of moving peer-info instances around, as discussed on #453
Currently peer-info is being used on the following modules:
Regarding the discovery modules, they only depend on peer-info because the peer-info is currently used for emitting the peer discovered, which is basically obtained from the peer-id. This way, we can simply emit the peer-info and libp2p will be responsible for adding it to the peerStore and track protocols/multiaddrs.
Regarding pubsub, all modules use peer-info to get data related to the peer-id. However, gossipsub also leverages peer-info to validate if the peer to be connected supports the gossipsub protocol. This is currently guaranteed in the MulticodecTopologyvalidations and we do not need to also do this in gossipsub. The only relevant issue is to support floodsub peers into gossipsub, as gossipsub on publish checks if peers are from floodsub, in order to publish to them. This way, the best solution is to provided the peerStore to the gossipsub, same way as the dht is also receiving it.
js-libp2pcurrently usespeer-infoto keep a record of the known protocols and multiaddrs of each peer. With the newpeerstore, we intend to use it to mapprotocolsandmultiaddrsinstead of movingpeer-infoinstances around, as discussed on #453Currently
peer-infois being used on the following modules:Regarding the discovery modules, they only depend on
peer-infobecause thepeer-infois currently used for emitting the peer discovered, which is basically obtained from thepeer-id. This way, we can simply emit thepeer-infoandlibp2pwill be responsible for adding it to thepeerStoreand track protocols/multiaddrs.Regarding pubsub, all modules use
peer-infoto get data related to thepeer-id. However,gossipsubalso leveragespeer-infoto validate if the peer to be connected supports the gossipsub protocol. This is currently guaranteed in theMulticodecTopologyvalidations and we do not need to also do this in gossipsub. The only relevant issue is to support floodsub peers into gossipsub, as gossipsub on publish checks if peers are from floodsub, in order to publish to them. This way, the best solution is to provided thepeerStoreto thegossipsub, same way as the dht is also receiving it.