Discovery: discovering suitable multiaddrs

[jm-clius]

Background

Waku currently specifies two main peer discovery methods:

1. DNS discovery (for static lists/bootstrapping)
2. Waku Discv5 for continuous ambient peer discovery

We also specify Waku Peer Exchange which currently functions as a secondary mechanism for resource-restricted nodes to discover peers via a service node already participating in another ambient peer discovery method (discv5).

All three methods operate on Waku ENRs. 31/WAKU2-ENR specifies how basic connection information for a libp2p node can be encoded into an ENR and converted to/from a multiaddr. It also describes a way to encode multiple alternative multiaddrs into an ENR for nodes that want to advertise alternative listening addresses/transports.

Problem

However:

1. ENR records are limited to 300 bytes in size (cf. EIP-778). This can easily be exceeded by adding more multiaddrs to the ENR record, especially when multiple addresses could be valuable as in the case with circuit-relay.
2. there is currently no way to identify which pubsub topics/shards the discovered nodes belong to before adding them to routing table and attempting connection.

Suggested solution

1. Add/enable libp2p rendezvous discovery as a method more suitable for multiaddrs as it operates on signedPeerRecords.
2. Add a simple negotiation protocol (similar to identify) in which nodes can exchange shard/pubsub topic information on connection.

Note: I understand (2) may be more controversial than (1), so feel free to provide feedback on either.

cc @fryorcraken @kaiserd @richard-ramos

[richard-ramos]

Could a peer exchange like protocol that uses signed records be another alternative?
I was looking at go-libp2p, and looks like I can obtain the signed records for peers in my peerstore with:

	cab, ok := peerstore.GetCertifiedAddrBook(hosts.Peerstore())
        if ok {
               env, _ := cab.GetPeerRecord()
              record, _ := env.Record()

	      // Do something with this record:
            theMultiaddresses := rec.(*peer.PeerRecord).Addrs
	    thePeerId := rec.(*peer.PeerRecord).PeerID

               ...
        }

And identify protocol exchanges signed records according to: libp2p/go-libp2p#747 , so I imagine that the new protocol PeerExchangeResponse protobuffer could look like this:

message PeerExchangeResponse {
     repeated bytes signedPeerRecord = 2;
}

[Menduist]

imo it would be better to directly use rendezvous than create yet-another-discovery-protocol

[alrevuelta]

there is currently no way to identify which pubsub topics/shards the discovered nodes belong to before adding them to routing table and attempting connection.

Not sure this is a problem right now. I mean, its not implemented but we can add to the ENR a field (just couple of bytes) containing the shard(s) index, just like ethereum does. So the ENR will contain both i) the already existing waku field (for protocol) and the shard(s) (for gossipsub topic).

Agree that rendezvous will help a lot when finding peers supporting i) given protocols and ii) given shards (aka pububs topics). I would see waku using rendezvous it in the future, but since we currently have 3 discovery protocols and our resources are limited perhaps we can use what we have by now? With the above change in the ENR it should be enough to solve problem (2).

I acknowledge ENR records are limited to 300 bytes in size though, but the heavy part of it are the multis, not waku field or the suggested shard(s) index.

Out of curiosity, will rendezvouz deprecate peer exchange? Or any of the other discovery meechanisims?

[jm-clius]

Note that nodes behind a restrictive NAT cannot use any of the existing discovery methods to make themselves discoverable (e.g. if they have a circuit-relay address to advertise). This is why rendezvous is considered part of MVP scope.

[fryorcraken]

Pretty sure this is done and delivered in nwaku and go-waku. Please confirm @richard-ramos @jm-clius

[richard-ramos]

Yes. go-waku when used as a library can use rendezvous to advertise all of the node's multiaddresses

[jm-clius]

Done. I'm going ahead and closing this.