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?

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)

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?

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?

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