Closed jm-clius closed 10 months ago
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: https://github.com/libp2p/go-libp2p/pull/747 , so I imagine that the new protocol PeerExchangeResponse
protobuffer could look like this:
message PeerExchangeResponse {
repeated bytes signedPeerRecord = 2;
}
imo it would be better to directly use rendezvous than create yet-another-discovery-protocol
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?
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.
Pretty sure this is done and delivered in nwaku and go-waku. Please confirm @richard-ramos @jm-clius
Yes. go-waku when used as a library can use rendezvous to advertise all of the node's multiaddresses
Done. I'm going ahead and closing this.
Background
Waku currently specifies two main peer discovery methods:
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 alternativemultiaddrs
into an ENR for nodes that want to advertise alternative listening addresses/transports.Problem
However:
multiaddrs
to the ENR record, especially when multiple addresses could be valuable as in the case with circuit-relay.Suggested solution
multiaddrs
as it operates onsignedPeerRecords
.identify
) in which nodes can exchange shard/pubsub topic information on connection.cc @fryorcraken @kaiserd @richard-ramos