Peer Exchange Protocol

[Stebalien]

Not to be confused with #3.

We should have a global peer exchange protocol for exchanging information on peers wiling to perform some service and/or speak some protocol. This would implement the discovery (https://github.com/libp2p/go-libp2p-discovery/) interface and could be run in parallel to a dht-based discovery service to widen a search.

Basic protocol proposal:

message Request {
    // Service descriptions (arbitrary strings).
    repeated string services = 0;

    // Number of peers to return (0 means unlimited).
    int32 limit = 1;
}

message Response {
    repeated Peer peers = 0
}

message Peer {
    // Peer id
    bytes id = 0;

    // Addresses for the peer.
    repeated string addresses = 1

    // List of services the peer supports. Empty means "unspecified".
    //
    // TODO: Should we use numbers and index into some table? Maybe index
    // into the table from the request?
    repeated string services = 2
    
    // Timestamp when the peer was last seen.
    // 0 for currently connected
    uint64 lastSeen = 3;
}

[aschmahmann]

This seems similar to the rendezvous protocol (https://github.com/libp2p/specs/tree/master/rendezvous and libp2p/go-libp2p-rendezvous#1). A few clarifying questions about peer exchange and rendezvous:

• Is the main difference that rendezvous has a client-server setup and you're looking for a p2p equivalent?
• If so couldn't the TBD federation protocol for rendezvous be used to accomplish a similar task?
• If the concern is that federated rendezvous should be more opt-in/controlled than an ambient p2p discovery protocol then does this problem effectively revolve around the same discussion as Closed DHT Based Routing #10 ?

If we were to implement such a proposal do you have any thoughts on whether we should blindly trust peers to relay the services of other peers, or if they should be relaying signed records detailing the provided services?

[Stebalien]

I'm proposing a complementary service with different pros/cons.

• A rendezvous protocol may not include all peers participating in some topic. The protocol proposed here can be used to widen the set of peers.
  • If two peers share no common rendezvous server, they'd need a protocol like this one to find each other.
  • Rendezvous servers may not be able to keep (or return) information on all peers. They'll likely have to prune to a random subset. A peer exchange protocol can be used to find peers of peers to widen this set.
• Anything federated won't work in disconnected networks. This protocol will work well on, e.g., a LAN.

If we were to implement such a proposal do you have any thoughts on whether we should blindly trust peers to relay the services of other peers, or if they should be relaying signed records detailing the provided services?

Absolutely signed records (we should be doing the same for content routing). The randezvous servers should have signed records as well. However, we may need to mandate ed25519 to get signature sizes down.

(however, I'd be fine with a first version that doesn't sign anything as this won't be making anything worse than it is)

[liamsi]

Is there a prototype implementation of this already? Or some further design considerations? I see that a peer exchange protocol is now part of the roadmap but there the focus seems to be local networks only?

We, over at @celestiaorg are considering implementing a pex ontop of libp2p as well. There is also the idea to extract the pex mechanism that is used inside of gossipssub (as part of the v1.1 extensions) but I'm not really convinced this would be a good idea. Is there a way to be involved in the pex efforts?

[TheRook]

I think this is also important for the IoT part of the roadmap. Do you have a working RPC call? Or is your implamenation using pex as a side-channel?

Is there a prototype implementation of this already? Or some further design considerations? I see that a peer exchange protocol is now part of the roadmap but there the focus seems to be local networks only?

We, over at @celestiaorg are considering implementing a pex ontop of libp2p as well. There is also the idea to extract the pex mechanism that is used inside of gossipssub (as part of the v1.1 extensions) but I'm not really convinced this would be a good idea. Is there a way to be involved in the pex efforts?

[thomaseizinger]

I've started a new discussion that is related to this: libp2p/specs#587