New RFC: 34/WAKU2-PEER-EXCHANGE

[kaiserd]

This issue is part of the Waku v2 discv5 Roadmap and tracks the editing of a new RFC specifying a Waku2 peer exchange protocol based on Simple, minimal peer exchange protocol.

Background and Motivation

Ambient peer discovery methods like Waku discovery v5 (#486) allow nodes to learn about other Waku nodes in a decentralized way.
While Waku discovery v5 is very efficient, this discovery still comes at costs in terms of computational power and network bandwidth.
Resource restricted devices might prefer to directly ask known stronger peers for

• a subset of their list of peers this is might have negative implication on anonymity (see comments below)
• querying discv5 for a random node set in their stead

The goal of the WAKU2-PEER-EXCHANGE RFC is specifying a protocol supporting these two types of queries and the respective responses.
Future versions of WAKU2-PEER-EXCHANGE might support more specific queries, e.g. asking for nodes supporting specific Waku2 protocols or holding messages of a certain time interval.

Acceptance criteria

• RFC (in raw status) specifying WAKU2-PEER-EXCHANGE

[oskarth]

Related: #429 and https://forum.vac.dev/t/the-current-state-of-waku-v2-peer-discovery/102

[D4nte]

Please note that by returning a subset list of their own peers a node might expose themselves:

• https://discord.com/channels/613988663034118151/636230707831767054/963707205314547732
• https://discord.com/channels/613988663034118151/636230707831767054/963732828737122324

[kaiserd]

Yes. Thank you for pointing me to that conversation :). My idea was pretty much what you answered in the discord channel:
The nodes that receive peer exchange queries should not answer with peers they use themselves. Caching a random sample for a bit is a good idea as it also mitigates DoS. I will edit this issue to clarify. (As pointed out later in the conversation, the caching should not be for too long to avoid flooding specific sets of peers.)