It’d be useful to understand more precise requirements from e.g. Desktop to prioritize work here.
The current state of Waku v2 peer discovery - #3 by oskarth
For proper usage of WakuV2 in desktop I require guidance in the following topics:
Should we support DNS Discovery for bootstrapping nodes? If so, what kind of nodes should we expect to be returned by this?, my concern is that dns discovery only returns the node multiaddresses, but then I’d have to rely on the identify protocol to know the node capabilities.
Currently we hardcode the nodes in the configuration in different categories so we know before starting status-go the protocols supported by a node, but to achieve something similar with DNS Discovery we’d need that the url had something to identify the type of node. i.e. store.test.status.im, filter.test.status.im
Are there plans to support rendezvous in nim-waku? for mobile devices I understand we need a lightweight discovery mechanism, so I implemented in go-waku the rendezvous protocol with multiaddresses instead of ENRs, as well as enabling peer exchange for gossipsub.
I read somewhere that DiscV5 was being worked on nim-waku. While I see this discovery mechanism being used in desktop succesfully, would it be the same case for mobile devices? I’m worried about bandwith restrictions.
What’s the latest status on peer selection? Currently selecting a peer is done by asking the peerstore to return the first peer it has that supports a protocol, but IMO a ‘smarter’ peer selection algorithm is needed, specially If we want to use Lightpush and Filter protocols.
Should we only use waku-relay? status-go and desktop support the usage of filter and lightpush when running in light client mode (just selecting the first node that supports these protocols). Since status-go is shared by both desktop and mobile, and filter and lightpush are still in Draft, is it acceptable if mobile uses relay only?