misc: add a `PeerStore` behaviour

[thomaseizinger]

Description

Other implementations have the concept of a PeerStore, should we add one to rust-libp2p too? I am thinking of a NetworkBehaviour implementation tracks currently connected peers and allows to add / remove addresses.

See related discussions:

• chore(libp2p): expose Behaviour::connected and Behaviour::addresses #4101
• libp2p-kad: provide a way to get known addresses of a peer from address book #3633
• On connection management #2118

Motivation

Users should be able to query the connected peers in a simple way and add known addresses of peers that will contribute to establishing new connections.

Open questions

• Are the two topics connected-peers and adding new addresses related enough to merge them in one behaviour?
• Is storing addresses in-memory fine for now?
• Should we add a persistent address book as well? e.g. an SQL-based one?

Are you planning to do it yourself in a pull request?

No

[mxinden]

In general I am in favor of a PeerStore NetworkBehaviour implementation.

In addition to the above, I suggest adding a new variant to libp2p_swarm::behaviour::ToSwarm, allowing a NetworkBehaviour to inform other NetworkBehaviours of addresses of peers it discovered. Similar to how we have ToSwarm::NewExternalAddressCandidate, but for addresses of remote peers instead of addresses of the local node. libp2p-identify and libp2p-kad can emit these events and PeerStore can consume these events.

We could then deprecate libp2p-identify's discovered_peers cache.

rust-libp2p/protocols/identify/src/behaviour.rs

Lines 53 to 54 in 85a846a

	/// The addresses of all peers that we have discovered.
	discovered_peers: PeerCache,

[thomaseizinger]

Good idea.

That is orthogonal though, correct? We can ship an initial peer store without introducing such a variant (which is a breaking change).

A ToSwarm::NewPeerAddress event should likely also be consumed by libp2p-kad to extend the routing table.

[dariusc93]

Should be simple to do from the behaviour standpoint. Maybe we could do a trait similar to libp2p-kad store that can be used for others to implement their own backend besides the memory backend. Also, I think storing in memory is fine for now, which is what I usually do although storing it elsewhere (eg database, on-disk, etc) is a nice-to-have solution down the road, but dont think it really fits the scope of rust-libp2p.

[thomaseizinger]

The question is, is it worth doing the abstraction of a trait and deal with all the issues of e.g. futures that need to run on a specific executor (thinking tokio-postgresql etc) over just requiring people to implement another NetworkBehaviour for it.

[mxinden]

In addition to the above, I suggest adding a new variant to libp2p_swarm::behaviour::ToSwarm, allowing a NetworkBehaviour to inform other NetworkBehaviours of addresses of peers it discovered. Similar to how we have ToSwarm::NewExternalAddressCandidate, but for addresses of remote peers instead of addresses of the local node. libp2p-identify and libp2p-kad can emit these events and PeerStore can consume these events.

Tracked in #4302.

[thomaseizinger]

Also, I think storing in memory is fine for now, which is what I usually do although storing it elsewhere (eg database, on-disk, etc) is a nice-to-have solution down the road, but dont think it really fits the scope of rust-libp2p.

Another thing to consider is that reading from this store needs to be synchronous and fast because we do it for every outgoing connection. Thus, the entire list needs to be in-memory anyway.

Storing peer addresses in a database or disk does make sense though. I think we can accommodate for that by:

• Adding APIs to the peer store for adding and removing entries
• Adding an API for listing all entries
• Adding an event that gets emitted every time the peer store is updated

The above would allow users to integrate the peer store into an event loop and synchronize its state with another data source or sink. It would only be eventually-consistent but I think that is fine.

[thomaseizinger]

With #4371 approved, this issue is now unblocked.

[guillaumemichel]

Lessons from go-libp2p: libp2p/go-libp2p#2355