From 7aec995a0700d85783e90ac1bb44ad76917a5d05 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Wed, 29 Oct 2025 17:21:40 +0530 Subject: [PATCH 1/6] update rendezvous for mix node discovery --- standards/core/rendezvous.md | 99 ++++++++++++++++++++++++------------ 1 file changed, 66 insertions(+), 33 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index 6a42abd..d435ac6 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -1,66 +1,97 @@ --- title: WAKU-RENDEZVOUS name: Waku Rendezvous discovery -editor: Simon-Pierre Vivier -contributors: +editor: Prem Chaitanya Prathi +contributors: Simon-Pierre Vivier --- ## Abstract + This document describes the goal, -strategy and usage of the libp2p rendezvous protocol by Waku. +strategy, usage, and changes to the libp2p rendezvous protocol by Waku. Rendezvous is one of the discovery methods that can be used by Waku. It supplements Discovery v5 and Waku peer exchange. ## Background and Rationale -How do new nodes join the network is the question that discovery answers. -Discovery must be fast, pertinent and resilient to attacks. -Rendezvous is both fast and allow the discovery of relevant peers, -although it design can be easily abused -due to it's lack of protection against denial of service atacks. -The properties of rendezvous complements well the slower but safer methods like Discv5. -To contribute well, a Waku node must know a sufficient number of peers with -a wide variety of capabilities. -By using rendezvous in combination with + +Waku nodes need a discovery mechanism that is both rapid and robust against attacks. Rendezvous enables quick identification of relevant peers, complementing slower but more resilient approaches like Discv5. For healthy network participation, nodes must connect to a diverse set of peers. However, the rendezvous protocol is vulnerable to denial of service attacks and depends on centralized rendezvous points, so it is best used in conjunction with other discovery methods such as Discv5. + +Ethereum Node Record (ENR) size constraints make it impractical to encode additional metadata, such as Mix public keys, in ENRs for Discv5-based discovery. Rendezvous, using a custom peer record (`WakuPeerRecord`), allows nodes to advertise Mix-specific information—including the Mix public key—without being restricted by ENR size. This serves as an interim solution until a comprehensive capability discovery mechanism is available. + +By combining rendezvous with [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) and [34/WAKU2-PEER-EXCHANGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/34/peer-exchange.md#abstract), -Waku nodes will reach a good number of meaningful peers -faster than through a single discovery method. +Waku nodes can more quickly reach a meaningful set of peers +than by relying on a single discovery method. ## Semantics -Waku rendezvous fully inherits the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol). + +Waku rendezvous extends the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol) by using `WakuPeerRecord` instead of the standard libp2p `PeerRecord`. +This allows nodes to advertise additional Waku-specific metadata beyond what is available in the standard libp2p peer record. ## Specifications -The namespaces used to register and request MUST be in the format `rs/cluster-id/shard`. + +**Libp2p Protocol identifier**: `/vac/waku/rendezvous/1.0.0` + +### Namespace Format + +The namespaces used to register and request MUST be in the format `rs//`. + +This allows for discovering peers with specific capabilities within a given cluster. +Currently, this is used for Mix protocol discovery where the capability field specifies `mix`. + Refer to [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) for cluster and shard information. +### Registration and Discovery + Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node SHOULD be initialized as a rendezvous point. Each relay node that participates in discovery MUST register with random rendezvous points at regular intervals. +Nodes supporting the Mix protocol MUST advertise their `WakuPeerRecord`, which includes their multiaddresses, supported protocols, and Mix public key. -We RECOMMEND a registration interval of 10 seconds. -The node SHOULD register once for every shard it supports, -registering only the namespace corresponding to that shard. +We RECOMMEND a registration interval of 10 seconds. -We RECOMMEND that rendezvous points expire registrations after 1 minute, -in order to keep discovered peer records to those recentrly online. +We RECOMMEND that rendezvous points expire registrations after 1 minute (60 seconds TTL) +to keep discovered peer records limited to those recently online. -At startup, every Waku node SHOULD discover peers by -sending requests to random rendezvous points, -once for each shard it supports. +At startup, every Waku node supporting Mix SHOULD discover peers by +sending requests to random rendezvous points for the Mix capability namespace. -We RECOMMEND a maximum of 12 peers will be requested each time. -This number is enough for good GossipSub connectivity and -minimize the load on rendezvous points. +We RECOMMEND a maximum of 12 peers be requested each time. +This number is sufficient for good GossipSub connectivity and +minimizes the load on rendezvous points. + +### Peer Records + +Nodes advertise their information through `WakuPeerRecord`, which includes: + +- Multiaddresses for connectivity +- Supported protocol codecs +- Mix protocol public key (for nodes supporting the Mix protocol) + +When a node discovers peers through rendezvous, it receives the complete `WakuPeerRecord` for each peer, +allowing it to make informed decisions about which peers to connect to based on their advertised information. + +### Operational Recommendations We RECOMMEND that bootstrap nodes participate in rendezvous discovery and -that other discovery methods are used in conjunction and +that other discovery methods are used in conjunction and continue discovering peers for the lifetime of the local node. +For resource-constrained devices or light clients, a client-only mode MAY be used +where nodes only query for peers without acting as rendezvous points themselves +and without advertising their own peer records. + ## Future Work -Namespaces will not contain capabilities yet but may in the future. If the need arise nodes could use rendezvous to discover peers with specific capabilities. +The protocol currently supports advertising Mix-specific capabilities (Mix public keys) through `WakuPeerRecord`. +Future enhancements could include: + +- Extending `WakuPeerRecord` to advertise other Waku protocol capabilities (Relay, Store, Filter, Lightpush, etc.) +- Supporting shard-based namespaces (e.g., `rs//`) for general relay peer discovery without capability filtering +- Batch registration support allowing nodes to register across multiple namespaces in a single request # Copyright @@ -68,7 +99,9 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). # References - - [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) - - [34/WAKU2-PEER-EXCHANGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/34/peer-exchange.md#abstract) - - [Libp2p Rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol) - - [Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) + +- [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) +- [ENR](https://github.com/ethereum/devp2p/blob/master/enr.md) +- [34/WAKU2-PEER-EXCHANGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/34/peer-exchange.md#abstract) +- [Libp2p Rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol) +- [Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) From cd9a10cff1d995b63e7d2191bf6c917786ef3f58 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Wed, 29 Oct 2025 17:29:47 +0530 Subject: [PATCH 2/6] address review comments --- standards/core/rendezvous.md | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index d435ac6..bd999ce 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -41,7 +41,7 @@ The namespaces used to register and request MUST be in the format `rs/ Date: Thu, 30 Oct 2025 09:59:51 +0530 Subject: [PATCH 3/6] address review comments --- standards/core/rendezvous.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index bd999ce..422444e 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -50,23 +50,24 @@ Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/ Each relay node that participates in discovery MUST register with random rendezvous points at regular intervals. -All relay nodes participating in rendezvous discovery SHOULD advertise their information using `WakuPeerRecord`. For nodes supporting the Mix protocol, the `mix_public_key` field MUST be included. For non-Mix relay nodes, the `mix_public_key` field SHOULD be omitted. The standard libp2p PeerRecord is not used for Waku rendezvous; all advertised records MUST conform to the `WakuPeerRecord` specification. +All relay nodes participating in rendezvous discovery SHOULD advertise their information using `WakuPeerRecord`. For nodes supporting the Mix protocol, the `mix_public_key` field MUST be included. For non-Mix relay nodes, the `mix_public_key` field SHOULD be omitted. The standard libp2p PeerRecord is not used for Waku rendezvous; all advertised records MUST conform to the `WakuPeerRecord` definition. -We RECOMMEND a registration interval of 10 seconds. +The RECOMMENDED registration interval is 10 seconds. -We RECOMMEND that rendezvous points expire registrations after 1 minute (60 seconds TTL) +It is RECOMMENDED that rendezvous points expire registrations after 1 minute (60 seconds TTL) to keep discovered peer records limited to those recently online. At startup, every Waku node supporting Mix SHOULD discover peers by sending requests to random rendezvous points for the Mix capability namespace. -We RECOMMEND a maximum of 12 peers be requested each time. +It is RECOMMENDED a maximum of 12 peers be requested each time. This number is sufficient for good GossipSub connectivity and minimizes the load on rendezvous points. ### Peer Records -Nodes advertise their information through `WakuPeerRecord`, a custom peer record structure designed for Waku rendezvous. The specification for `WakuPeerRecord` is as follows: +Nodes advertise their information through `WakuPeerRecord`, a custom peer record structure designed for Waku rendezvous. +The `WakuPeerRecord` is defined as follows: **WakuPeerRecord fields:** @@ -93,7 +94,7 @@ When a node discovers peers through rendezvous, it receives the complete `WakuPe ### Operational Recommendations -We RECOMMEND that bootstrap nodes participate in rendezvous discovery and +It is RECOMMENDED that bootstrap nodes participate in rendezvous discovery and that other discovery methods are used in conjunction and continue discovering peers for the lifetime of the local node. From 234249dc1d1b804fdf6aae1d8b417f6bd624d340 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Fri, 31 Oct 2025 18:26:53 +0530 Subject: [PATCH 4/6] aligning with implementation --- standards/core/rendezvous.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index 422444e..b5999a3 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -67,15 +67,15 @@ minimizes the load on rendezvous points. ### Peer Records Nodes advertise their information through `WakuPeerRecord`, a custom peer record structure designed for Waku rendezvous. +Since this is a customPeerRecord, it uses a private multicodec value of `0x300000` as per [multicodec table](https://github.com/multiformats/multicodec/blob/master/table.csv). The `WakuPeerRecord` is defined as follows: **WakuPeerRecord fields:** - `peer_id`: The libp2p PeerId of the node. +- `seqNo`: The time at which the record was created or last updated (Unix epoch, seconds). - `multiaddrs`: A list of multiaddresses for connectivity. -- `protocols`: A list of supported protocol codecs (e.g., `/vac/waku/mix/1.0.0`). - `mix_public_key`: The Mix protocol public key (only present for nodes supporting Mix). -- `timestamp`: The time at which the record was created or last updated (Unix epoch, seconds). **Encoding:** WakuPeerRecord is encoded as a protobuf message. The exact schema is: @@ -83,10 +83,9 @@ WakuPeerRecord is encoded as a protobuf message. The exact schema is: ```protobuf message WakuPeerRecord { string peer_id = 1; - repeated string multiaddrs = 2; - repeated string protocols = 3; + uint64 seqNo = 2; + repeated string multiaddrs = 3; optional bytes mix_public_key = 4; - uint64 timestamp = 5; } ``` From 29322c5c01268e7789d9fd0dedf5cf573d1a5103 Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Mon, 3 Nov 2025 03:13:29 +0530 Subject: [PATCH 5/6] address review comments --- standards/core/rendezvous.md | 77 ++++++++++++++++++++---------------- 1 file changed, 42 insertions(+), 35 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index b5999a3..7b8af58 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -15,9 +15,11 @@ It supplements Discovery v5 and Waku peer exchange. ## Background and Rationale -Waku nodes need a discovery mechanism that is both rapid and robust against attacks. Rendezvous enables quick identification of relevant peers, complementing slower but more resilient approaches like Discv5. For healthy network participation, nodes must connect to a diverse set of peers. However, the rendezvous protocol is vulnerable to denial of service attacks and depends on centralized rendezvous points, so it is best used in conjunction with other discovery methods such as Discv5. - -Ethereum Node Record (ENR) size constraints make it impractical to encode additional metadata, such as Mix public keys, in ENRs for Discv5-based discovery. Rendezvous, using a custom peer record (`WakuPeerRecord`), allows nodes to advertise Mix-specific information—including the Mix public key—without being restricted by ENR size. This serves as an interim solution until a comprehensive capability discovery mechanism is available. +Waku needs discovery mechanism(s) that are both rapid and robust against attacks. +Fully centralised discovery (such as DNS lookup) may be fast but is not secure. +Fully decentralised discovery (such as discv5) may be robust, but too slow for some bootstrapping use cases +Rendezvous provides a limited, balanced solution that trades off some robustness for speed. +It's meant to complement not replaced fully decentralised discovery mechanisms, like discv5 By combining rendezvous with [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) and @@ -34,40 +36,10 @@ This allows nodes to advertise additional Waku-specific metadata beyond what is **Libp2p Protocol identifier**: `/vac/waku/rendezvous/1.0.0` -### Namespace Format - -The namespaces used to register and request MUST be in the format `rs//`. - -This allows for discovering peers with specific capabilities within a given cluster. -Currently, this is used for Mix protocol discovery where the capability field specifies `mix`. - -Refer to [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) for cluster information. - -### Registration and Discovery - -Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node SHOULD be initialized as a rendezvous point. - -Each relay node that participates in discovery -MUST register with random rendezvous points at regular intervals. - -All relay nodes participating in rendezvous discovery SHOULD advertise their information using `WakuPeerRecord`. For nodes supporting the Mix protocol, the `mix_public_key` field MUST be included. For non-Mix relay nodes, the `mix_public_key` field SHOULD be omitted. The standard libp2p PeerRecord is not used for Waku rendezvous; all advertised records MUST conform to the `WakuPeerRecord` definition. - -The RECOMMENDED registration interval is 10 seconds. - -It is RECOMMENDED that rendezvous points expire registrations after 1 minute (60 seconds TTL) -to keep discovered peer records limited to those recently online. - -At startup, every Waku node supporting Mix SHOULD discover peers by -sending requests to random rendezvous points for the Mix capability namespace. - -It is RECOMMENDED a maximum of 12 peers be requested each time. -This number is sufficient for good GossipSub connectivity and -minimizes the load on rendezvous points. - -### Peer Records +### Wire Protocol Nodes advertise their information through `WakuPeerRecord`, a custom peer record structure designed for Waku rendezvous. -Since this is a customPeerRecord, it uses a private multicodec value of `0x300000` as per [multicodec table](https://github.com/multiformats/multicodec/blob/master/table.csv). +Since this is a customPeerRecord, we define a private multicodec value of `0x300000` as per [multicodec table](https://github.com/multiformats/multicodec/blob/master/table.csv). The `WakuPeerRecord` is defined as follows: **WakuPeerRecord fields:** @@ -91,6 +63,41 @@ message WakuPeerRecord { When a node discovers peers through rendezvous, it receives the complete `WakuPeerRecord` for each peer, allowing it to make informed decisions about which peers to connect to based on their advertised information. +### Namespace Format + +The [rendezvous namespaces](https://github.com/libp2p/specs/blob/69c4fdf5da3a07d2f392df6a892c07256c1885c0/rendezvous/README.md#the-protocol) used to register and request peer records +MUST be in the format `rs//`. +`` is a string representing the individual capability for which a discoverable Waku peer record is registered. +The Waku peer record is separately registered against each capability for which discovery is desired. +The only defined capability for now is `mix`, representing [Waku Mix](https://github.com/waku-org/specs/blob/master/standards/core/mix.md) support. +For example, a Waku peer record for a node supporting mix protocol in cluster `1` will be registered against a namespace: `rs/1/mix`. + +This allows for discovering peers with specific capabilities within a given cluster. +Currently, this is used for Mix protocol discovery where the capability field specifies `mix`. + +Refer to [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) for cluster information. + +### Registration and Discovery + +Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node SHOULD be initialized as a rendezvous point. + +Each relay node that participates in discovery +MUST register with random rendezvous points at regular intervals. +The RECOMMENDED registration interval is 10 seconds. + +All relay nodes participating in rendezvous discovery SHOULD advertise their information using `WakuPeerRecord`. For nodes supporting the Mix protocol, the `mix_public_key` field MUST be included. +All advertised records MUST conform to the `WakuPeerRecord` definition. + +It is RECOMMENDED that rendezvous points expire registrations after 1 minute (60 seconds TTL) +to keep discovered peer records limited to those recently online. + +At startup, every Waku node supporting Mix SHOULD discover peers by +sending requests to random rendezvous points for the Mix capability namespace. + +It is RECOMMENDED a maximum of 12 peers be requested each time. +This number is sufficient for good GossipSub connectivity and +minimizes the load on rendezvous points. + ### Operational Recommendations It is RECOMMENDED that bootstrap nodes participate in rendezvous discovery and From ce9deda4500e1bc926d1afbbe0642d6bd018c79d Mon Sep 17 00:00:00 2001 From: Prem Chaitanya Prathi Date: Tue, 18 Nov 2025 16:42:58 +0530 Subject: [PATCH 6/6] update links with permalinks --- standards/core/rendezvous.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index 7b8af58..292be4c 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -22,14 +22,14 @@ Rendezvous provides a limited, balanced solution that trades off some robustness It's meant to complement not replaced fully decentralised discovery mechanisms, like discv5 By combining rendezvous with -[Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) and -[34/WAKU2-PEER-EXCHANGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/34/peer-exchange.md#abstract), +[Discv5](https://github.com/ethereum/devp2p/blob/bc76b9809a30e6dc5c8dcda996273f0f9bcf7108/discv5/discv5.md#node-discovery-protocol-v5) and +[34/WAKU2-PEER-EXCHANGE](https://github.com/vacp2p/rfc-index/blob/dd397adc594c121ce3e10b7e81b5c2ed4818c0a6/waku/standards/core/34/peer-exchange.md#abstract), Waku nodes can more quickly reach a meaningful set of peers than by relying on a single discovery method. ## Semantics -Waku rendezvous extends the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol) by using `WakuPeerRecord` instead of the standard libp2p `PeerRecord`. +Waku rendezvous extends the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/69c4fdf5da3a07d2f392df6a892c07256c1885c0/rendezvous/README.md#rendezvous-protocol) by using `WakuPeerRecord` instead of the standard libp2p `PeerRecord`. This allows nodes to advertise additional Waku-specific metadata beyond what is available in the standard libp2p peer record. ## Specifications @@ -39,7 +39,7 @@ This allows nodes to advertise additional Waku-specific metadata beyond what is ### Wire Protocol Nodes advertise their information through `WakuPeerRecord`, a custom peer record structure designed for Waku rendezvous. -Since this is a customPeerRecord, we define a private multicodec value of `0x300000` as per [multicodec table](https://github.com/multiformats/multicodec/blob/master/table.csv). +Since this is a customPeerRecord, we define a private multicodec value of `0x300000` as per [multicodec table](https://github.com/multiformats/multicodec/blob/0c6c7d75f1580af329847dbc9900859a445ed980/table.csv). The `WakuPeerRecord` is defined as follows: **WakuPeerRecord fields:** @@ -69,17 +69,17 @@ The [rendezvous namespaces](https://github.com/libp2p/specs/blob/69c4fdf5da3a07d MUST be in the format `rs//`. `` is a string representing the individual capability for which a discoverable Waku peer record is registered. The Waku peer record is separately registered against each capability for which discovery is desired. -The only defined capability for now is `mix`, representing [Waku Mix](https://github.com/waku-org/specs/blob/master/standards/core/mix.md) support. +The only defined capability for now is `mix`, representing [Waku Mix](https://github.com/waku-org/specs/blob/fe5cfdf823085b8c9560df81b38bc342d6b1cb38/standards/core/mix.md) support. For example, a Waku peer record for a node supporting mix protocol in cluster `1` will be registered against a namespace: `rs/1/mix`. This allows for discovering peers with specific capabilities within a given cluster. Currently, this is used for Mix protocol discovery where the capability field specifies `mix`. -Refer to [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) for cluster information. +Refer to [RELAY-SHARDING](https://github.com/waku-org/specs/blob/fe5cfdf823085b8c9560df81b38bc342d6b1cb38/standards/core/relay-sharding.md) for cluster information. ### Registration and Discovery -Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node SHOULD be initialized as a rendezvous point. +Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/dd397adc594c121ce3e10b7e81b5c2ed4818c0a6/waku/standards/core/11/relay.md) node SHOULD be initialized as a rendezvous point. Each relay node that participates in discovery MUST register with random rendezvous points at regular intervals. @@ -124,8 +124,8 @@ Copyright and related rights waived via # References -- [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) -- [ENR](https://github.com/ethereum/devp2p/blob/master/enr.md) -- [34/WAKU2-PEER-EXCHANGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/34/peer-exchange.md#abstract) -- [Libp2p Rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol) -- [Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) +- [Discv5](https://github.com/ethereum/devp2p/blob/bc76b9809a30e6dc5c8dcda996273f0f9bcf7108/discv5/discv5.md#node-discovery-protocol-v5) +- [ENR](https://github.com/ethereum/devp2p/blob/bc76b9809a30e6dc5c8dcda996273f0f9bcf7108/enr.md) +- [34/WAKU2-PEER-EXCHANGE](https://github.com/vacp2p/rfc-index/blob/dd397adc594c121ce3e10b7e81b5c2ed4818c0a6/waku/standards/core/34/peer-exchange.md#abstract) +- [Libp2p Rendezvous](https://github.com/libp2p/specs/blob/69c4fdf5da3a07d2f392df6a892c07256c1885c0/rendezvous/README.md#rendezvous-protocol) +- [Relay](https://github.com/vacp2p/rfc-index/blob/dd397adc594c121ce3e10b7e81b5c2ed4818c0a6/waku/standards/core/11/relay.md)