2024-08-13 10:47:55 -04:00
---
title: WAKU-RENDEZVOUS
2024-10-22 10:50:34 -04:00
name: Waku Rendezvous discovery
2025-10-29 17:21:40 +05:30
editor: Prem Chaitanya Prathi < premprathi @proton .me >
contributors: Simon-Pierre Vivier < simvivier @status .im >
2024-08-13 10:47:55 -04:00
---
## Abstract
2025-10-29 17:21:40 +05:30
2024-10-22 10:50:34 -04:00
This document describes the goal,
2025-10-29 17:21:40 +05:30
strategy, usage, and changes to the libp2p rendezvous protocol by Waku.
2024-08-13 10:47:55 -04:00
2024-10-22 10:50:34 -04:00
Rendezvous is one of the discovery methods that can be used by Waku.
It supplements Discovery v5 and Waku peer exchange.
2024-08-13 10:47:55 -04:00
2024-08-29 17:14:31 -04:00
## Background and Rationale
2025-10-29 17:21:40 +05:30
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
2024-08-13 10:47:55 -04:00
[Discv5 ](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5 ) and
2024-12-03 08:32:55 -05:00
[34/WAKU2-PEER-EXCHANGE ](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/34/peer-exchange.md#abstract ),
2025-10-29 17:21:40 +05:30
Waku nodes can more quickly reach a meaningful set of peers
than by relying on a single discovery method.
2024-08-13 10:47:55 -04:00
2024-08-29 17:14:31 -04:00
## Semantics
2025-10-29 17:21:40 +05:30
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.
2024-08-13 10:47:55 -04:00
2024-08-29 17:14:31 -04:00
## Specifications
2025-10-29 17:21:40 +05:30
**Libp2p Protocol identifier**: `/vac/waku/rendezvous/1.0.0`
### Namespace Format
The namespaces used to register and request MUST be in the format `rs/<cluster-id>/<capability>` .
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` .
2025-10-29 17:29:47 +05:30
Refer to [RELAY-SHARDING ](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md ) for cluster information.
2024-08-14 11:24:52 -04:00
2025-10-29 17:21:40 +05:30
### Registration and Discovery
2024-10-22 10:50:34 -04:00
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.
2024-08-29 17:14:31 -04:00
2024-10-22 10:50:34 -04:00
Each relay node that participates in discovery
MUST register with random rendezvous points at regular intervals.
2025-10-29 17:29:47 +05:30
2025-10-30 09:59:51 +05:30
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.
2025-10-29 17:21:40 +05:30
2025-10-30 09:59:51 +05:30
The RECOMMENDED registration interval is 10 seconds.
2025-10-29 17:21:40 +05:30
2025-10-30 09:59:51 +05:30
It is RECOMMENDED that rendezvous points expire registrations after 1 minute (60 seconds TTL)
2025-10-29 17:21:40 +05:30
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.
2025-10-30 09:59:51 +05:30
It is RECOMMENDED a maximum of 12 peers be requested each time.
2025-10-29 17:21:40 +05:30
This number is sufficient for good GossipSub connectivity and
minimizes the load on rendezvous points.
2024-08-29 17:14:31 -04:00
2025-10-29 17:21:40 +05:30
### Peer Records
2024-10-22 10:50:34 -04:00
2025-10-30 09:59:51 +05:30
Nodes advertise their information through `WakuPeerRecord` , a custom peer record structure designed for Waku rendezvous.
The `WakuPeerRecord` is defined as follows:
2025-10-29 17:29:47 +05:30
**WakuPeerRecord fields:**
- `peer_id` : The libp2p PeerId of the node.
- `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:
2024-10-22 10:50:34 -04:00
2025-10-29 17:29:47 +05:30
```protobuf
message WakuPeerRecord {
string peer_id = 1;
repeated string multiaddrs = 2;
repeated string protocols = 3;
optional bytes mix_public_key = 4;
uint64 timestamp = 5;
}
```
2024-08-13 10:47:55 -04:00
2025-10-29 17:29:47 +05:30
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.
2025-10-29 17:21:40 +05:30
### Operational Recommendations
2024-10-22 10:50:34 -04:00
2025-10-30 09:59:51 +05:30
It is RECOMMENDED that bootstrap nodes participate in rendezvous discovery and
2025-10-29 17:21:40 +05:30
that other discovery methods are used in conjunction and
2024-10-22 10:50:34 -04:00
continue discovering peers for the lifetime of the local node.
2024-08-13 10:47:55 -04:00
2025-10-29 17:21:40 +05:30
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.
2024-08-14 11:24:52 -04:00
## Future Work
2024-08-13 10:47:55 -04:00
2025-10-29 17:21:40 +05:30
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/<cluster-id>/<shard>` ) for general relay peer discovery without capability filtering
- Batch registration support allowing nodes to register across multiple namespaces in a single request
2024-09-04 11:16:29 -04:00
# Copyright
Copyright and related rights waived via
[CC0 ](https://creativecommons.org/publicdomain/zero/1.0/ ).
# References
2025-10-29 17:21:40 +05:30
- [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 )