<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/1/</guid>
<description>This document describes a consensus-oriented specification system (COSS) for building interoperable technical specifications. COSS is based on a lightweight editorial process that seeks to engage the widest possible range of interested parties and move rapidly to consensus through working code.
This specification is based on Unprotocols 2/COSS, used by the ZeromMQ project. It is equivalent except for some areas:
recommending the use of a permissive licenses, such as CC0 (with the exception of this document); miscellaneous metadata, editor, and format/link updates; more inheritance from the [IETF Standards Process][https://www.</description>
<description>Abstract # Waku v2 is family of modular peer-to-peer protocols for secure communication. The protocols are designed to be secure, privacy-preserving, censorship-resistant and being able to run in resource restricted environments. At a high level, it implements Pub/Sub over libp2p and adds a set of capabilities to it. These capabilities are things such as: (i) retrieving historical messages for mostly-offline devices (ii) adaptive nodes, allowing for heterogeneous nodes to contribute to the network (iii) preserving bandwidth usage for resource-restriced devices</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/11/</guid>
<description>11/WAKU2-RELAY specifies a Publish/Subscribe approach to peer-to-peer messaging with a strong focus on privacy, censorship-resistance, security and scalability. Its current implementation is a minor extension of the libp2p GossipSub protocol and prescribes gossip-based dissemination. As such the scope is limited to defining a separate protocol id for 11/WAKU2-RELAY, establishing privacy and security requirements, and defining how the underlying GossipSub is to be interpreted and implemented within the Waku and cryptoeconomic domain.</description>
</item>
<item>
<title>12/WAKU2-FILTER</title>
<link>https://rfc.vac.dev/spec/12/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/12/</guid>
<description>WakuFilter is a protocol that enables subscribing to messages that a peer receives. This is a more lightweight version of WakuRelay specifically designed for bandwidth restricted devices. This is due to the fact that light nodes subscribe to full-nodes and only receive the messages they desire.
Content filtering is a way to do message-based filtering. Currently the only content filter being applied is on contentTopic.</description>
</item>
<item>
<title>13/WAKU2-STORE</title>
<link>https://rfc.vac.dev/spec/13/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/13/</guid>
<description>This specification explains the Waku 13/WAKU2-STORE protocol which enables querying of messages received through relay protocol and stored by other nodes. It also supports pagination for more efficient querying of historical messages.
Design Requirements # Nodes willing to provide storage service using 13/WAKU2-STORE protocol SHOULD provide a complete and full view of message history. As such, they are required to be highly available and in specific have a high uptime to consistently receive and store network messages.</description>
<description>Abstract # Waku v2 is a family of modular peer-to-peer protocols for secure communication. These protocols are designed to be secure, privacy-preserving, and censorship-resistant and can run in resource-restricted environments. At a high level, Waku v2 implements a Pub/Sub messaging pattern over libp2p and adds capabilities.
The present document specifies the Waku v2 message format, a way to encapsulate the messages sent with specific information security goals, and Whisper/Waku v1 backward compatibility.</description>
</item>
<item>
<title>15/WAKU-BRIDGE</title>
<link>https://rfc.vac.dev/spec/15/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/15/</guid>
<description>A bridge between Waku v1 and Waku v2.
Bridge # A bridge requires supporting both Waku versions:
Waku v1 - using devp2p RLPx protocol Waku v2 - using libp2p protocols Packets received on the Waku v1 network SHOULD be published just once on the Waku v2 network. More specifically, the bridge SHOULD publish this through the Waku Relay (PubSub domain).
<description>Introduction # This specification describes the JSON-RPC API that Waku v2 nodes MAY adhere to. Refer to the Waku v2 specification for more information on Waku v2.
Wire Protocol # Transport # Nodes SHOULD expose an accessible JSON-RPC API. The JSON-RPC version SHOULD be 2.0. Below is an example request:
{ &#34;jsonrpc&#34;:&#34;2.0&#34;, &#34;method&#34;:&#34;get_waku_v2_debug_info&#34;, &#34;params&#34;:[], &#34;id&#34;:1 } Fields # Field Description jsonrpc Contains the used JSON-RPC version (Default: 2.0) method Contains the JSON-RPC method that is being called params An array of parameters for the request id The request ID Types # In this specification, the primitive types Boolean, String, Number and Null, as well as the structured types Array and Object, are to be interpreted according to the JSON-RPC specification.</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/17/</guid>
<description>The 17/WAKU2-RLN-RELAY protocol is an extension of 11/WAKU2-RELAY which additionally provides spam protection using Rate Limiting Nullifiers (RLN).
The security objective is to contain spam activity in a GossipSub network by enforcing a global messaging rate to all the peers. Peers that violate the messaging rate are considered spammers and their message is considered spam. Spammers are also financially punished and removed from the system.
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/18/</guid>
<description>This specification outlines how we do accounting and settlement based on the provision and usage of resources, most immediately bandwidth usage and/or storing and retrieving of Waku message. This enables nodes to cooperate and efficiently share resources, and in the case of unequal nodes to settle the difference through a relaxed payment mechanism in the form of sending cheques.
Motivation and Goals # Light nodes with short connection windows and limited bandwidth wish to publish messages into the Waku network. Additionally, there is sometimes a need for confirmation that a message has been received &ldquo;by the network&rdquo; (here, at least one node).
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/2/</guid>
<description>In this specification, we describe a minimum viable protocol for data synchronization inspired by the Bramble Synchronization Protocol1. This protocol is designed to ensure reliable messaging between peers across an unreliable peer-to-peer (P2P) network where they may be unreachable or unresponsive.
We present a reference implementation2 including a simulation to demonstrate its performance.
Definitions # Term Description Peer The other nodes that a node is connected to. Record Defines a payload element of either the type OFFER, REQUEST, MESSAGE or ACK Node Some process that is able to store data, do processing and communicate for MVDS.</description>
Public Key Broadcast: /eth-pm/1/public-key/proto, Private Message: /eth-pm/1/private-message/proto. This specification explains the Toy Ethereum Private Message protocol which enables a peer to send an encrypted message to another peer using the Waku v2 network, and the peer&rsquo;s Ethereum address.
The main purpose of this specification is to demonstrate how Waku v2 can be used for encrypted messaging purposes, using Ethereum accounts for identity. This protocol caters for Web3 wallets restrictions, allowing it to be implemented only using standard Web3 API.</description>
</item>
<item>
<title>21/WAKU2-FAULT-TOLERANT-STORE</title>
<link>https://rfc.vac.dev/spec/21/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/21/</guid>
<description>The reliability of 13/WAKU2-STORE protocol heavily relies on the fact that full nodes i.e., those who persist messages have high availability and uptime and do not miss any messages. If a node goes offline, then it will risk missing all the messages transmitted in the network during that time. In this specification, we provide a method that makes the store protocol resilient in presence of faulty nodes. Relying on this method, nodes that have been offline for a time window will be able to fix the gap in their message history when getting back online.</description>
</item>
<item>
<title>22/TOY-CHAT</title>
<link>https://rfc.vac.dev/spec/22/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
Dogfood Waku v2, Show an example of how to use Waku v2. Currently, all main Waku v2 implementations support the toy chat protocol: nim-waku, js-waku (NodeJS and web) and go-waku.
PubSub topics, used for routing Content topics, used for content-based filtering PubSub topics # PubSub topics are used for routing of messages, see 11/WAKU2-RELAY spec for more details of how this routing works.
It relates to the Waku problem domain version is 2 default-waku indicates that it is the default topic for exchanging WakuMessages that the data field in PubSub is serialized/encoded as protobuf as determined by WakuMessage PubSub topic format # PubSub topics SHOULD follow the following structure:</description>
Motivation # In open p2p protocol there is an issue with voting off-chain as there is much room for malicious peers to only include votes that support their case when submitting votes to chain.
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/25/</guid>
<description>25/LIBP2P-DNS-DISCOVERY specifies a scheme to implement libp2p peer discovery via DNS for Waku v2. The generalised purpose is to retrieve an arbitrarily long, authenticated, updateable list of libp2p peers to bootstrap connection to a libp2p network. Since 10/WAKU2 currently specifies use of libp2p peer identities, this method is suitable for a new Waku v2 node to discover other Waku v2 nodes to connect to.
This specification is largely based on EIP-1459, with the only deviation being the type of address being encoded (multiaddr vs enr).</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/26/</guid>
<description>This specification describes how Waku provides confidentiality, authenticity, and integrity, as well as some form of unlinkability. Specifically, it describes how encryption, decryption and signing works in 6/WAKU1 and in 10/WAKU2 with 14/WAKU-MESSAGE version 1.
This specification effectively replaces 7/WAKU-DATA as well as 6/WAKU1 Payload encryption but written in a way that is agnostic and self-contained for Waku v1 and Waku v2.
Large sections of the specification originate from EIP-627: Whisper spec as well from RLPx Transport Protocol spec (ECIES encryption) with some modifications.</description>
</item>
<item>
<title>27/WAKU2-PEERS</title>
<link>https://rfc.vac.dev/spec/27/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/27/</guid>
<description>27/WAKU2-PEERS describes a recommended minimal set of peer storage and peer management features to be implemented by Waku v2 clients.
In this context, peer storage refers to a client&rsquo;s ability to keep track of discovered or statically-configured peers and their metadata. It also deals with matters of peer persistence, or the ability to store peer data on disk to resume state after a client restart.
Peer management is a closely related concept and refers to the set of actions a client MAY choose to perform based on its knowledge of its connected peers, e.</description>
</item>
<item>
<title>28/STATUS-FEATURING</title>
<link>https://rfc.vac.dev/spec/28/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/28/</guid>
<description>This spec is a proposition of voting on community featuring over waku v2.
Overview # When there is a active community that is seeking new members, current users of community should be able to feature their community so that it will be accessible to larger audience. Status community curation DApp should provide such a tool.
Rules of featuring: - Given community can&rsquo;t be featured twice in a row. - Only one vote per user per community (single user can vote on multiple communities) - Voting will be done off-chain - If community hasn&rsquo;t been featured votes for given community are still valid for the next 4 weeks</description>
</item>
<item>
<title>29/WAKU2-CONFIG</title>
<link>https://rfc.vac.dev/spec/29/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/29/</guid>
<description>29/WAKU2-CONFIG describes the RECOMMENDED values to assign to configurable parameters for Waku v2 clients. Since Waku v2 is built on libp2p, most of the parameters and reasonable defaults are derived from there.
Waku v2 relay messaging is specified in 11/WAKU2-RELAY, a minor extension of the libp2p GossipSub protocol. GossipSub behaviour is controlled by a series of adjustable parameters. Waku v2 clients SHOULD configure these parameters to the recommended values below.</description>
</item>
<item>
<title>3/REMOTE-LOG</title>
<link>https://rfc.vac.dev/spec/3/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/3/</guid>
<description>A remote log is a replication of a local log. This means a node can read data that originally came from a node that is offline.
This specification is complemented by a proof of concept implementation1.
Definitions # Term Definition CAS Content-addressed storage. Stores data that can be addressed by its hash. NS Name system. Associates mutable data to a name. Remote log Replication of a local log at a different location.</description>
Node types - a continuum # We can look at node types as a continuum, from more restricted to less restricted, fewer resources to more resources.
Possible limitations # Connectivity: Not publicly connectable vs static IP and DNS Connectivity: Mostly offline to mostly online to always online Resources: Storage, CPU, Memory, Bandwidth Accessibility and motivation # Some examples:</description>
<description>Abstract # This RFC describes the usage of the ENR (Ethereum Node Records) format for 10/WAKU2 purposes. The ENR format is defined in EIP-778 [3].
<description>Abstract # The following specification covers the RLN construct as well as some auxiliary libraries useful for interacting with it. Rate limiting nullifier (RLN) is a construct based on zero-knowledge proofs that provides an anonymous rate-limited signaling/messaging framework suitable for decentralized (and centralized) environments. Anonymity refers to the unlinkability of messages to their owner.
Motivation # RLN guarantees a messaging rate is enforced cryptographically while preserving the anonymity of the message owners.</description>
<description>Abstract # 33/WAKU2-DISCV5 specifies a modified version of Ethereum&rsquo;s Node Discovery Protocol v5 as a means for ambient node discovery. 10/WAKU2 uses the 33/WAKU2-DISCV5 ambient node discovery network for establishing a decentralized network of interconnected Waku2 nodes. In its current version, the 33/WAKU2-DISCV5 discovery network is isolated from the Ethereum Discovery v5 network. Isolation improves discovery efficiency, which is especially significant with a low number of Waku nodes compared to the total number of Ethereum nodes.</description>
<description>Abstract # This document specifies a simple request-response peer exchange protocol. Responders send information about a requested number of peers. The main purpose of this protocol is providing resource restricted devices with peers.
Background and Motivation # It may not be feasible on resource restricted devices to take part in distributed random sampling ambient peer discovery protocols such as 33/WAKU2-DISCV5. The Waku peer discovery protocol specified in this document allows resource restricted devices to request a list of peers from a service node.</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/35/</guid>
<description>This specification describes how payloads of Waku messages with version 2 can be encrypted in order to achieve confidentiality, authenticity, and integrity as well as some form of identity-hiding on communicating parties.
This specification extends the functionalities provided by 26/WAKU-PAYLOAD, adding support to modern symmetric encryption primitives and asymmetric key-exchange protocols.
Specifically, it adds support to the ChaChaPoly cipher for symmetric authenticated encryption. It further describes how the Noise Protocol Framework can be used to exchange cryptographic keys and encrypt/decrypt messages in a way that the latter are authenticated and protected by strong forward secrecy.</description>
</item>
<item>
<title>36/WAKU2-BINDINGS-API</title>
<link>https://rfc.vac.dev/spec/36/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<description>Introduction # Native applications that wish to integrate Waku may not be able to use nwaku and its JSON RPC API due to constraints on packaging, performance or executables.
<description>Introduction # In 35/WAKU2-NOISE we defined how Waku messages&rsquo; payloads can be encrypted using key material derived from key agreements based on the Noise Protocol Framework.
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/38/</guid>
<description>Abstract # This document specifies Claro: a Byzantine, fault-tolerant, binary decision agreement algorithm that utilizes bounded memory for its execution. Claro is a novel variant of the Snow family providing a probabilistic leaderless BFT consensus algorithm that achieves metastablity via network sub-sampling. We present an application context of the use of Claro in an efficient, leaderless, probabilistic permission-less consensus mechanism. We outline a simple taxonomy of Byzantine adversaries, leaving explicit explorations of to subsequent publication.</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/4/</guid>
<description>In this specification, we describe a method to construct message history that will aid the consistency guarantees of 2/MVDS. Additionally, we explain how data sync can be used for more lightweight messages that do not require full synchronization.
Motivation # In order for more efficient synchronization of conversational messages, information should be provided allowing a node to more effectively synchronize the dependencies for any given message.
Format # We introduce the metadata message which is used to convey information about a message and how it SHOULD be handled.</description>
<description>Abstract # In this document we describe a compound protocol for enabling two devices to mutually authenticate and securely exchange (arbitrary) information over the Waku network.
Background / Rationale / Motivation # In order to implement multi-device communications using one of the Noise session management mechanisms proposed in 37/WAKU2-NOISE-SESSIONS, we require a protocol to securely exchange (cryptographic) information between 2 or more devices possessed by a user.
Since, in this scenario, the devices would be close to each other, authentication can be initialized by exchanging a QR code out-of-band and then securely completed over the Waku network.</description>
</item>
<item>
<title>44/WAKU2-DANDELION</title>
<link>https://rfc.vac.dev/spec/44/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<description>Abstract # This document specifies a deanonymization mitigation technique, based on Dandelion and Dandelion++, for Waku Relay. It mitigates mass deanonymization in the multi-node (botnet) attacker model, even when the number of malicious nodes is linear in the number of total nodes in the network.
Based on the insight that symmetric message propagation makes deanonymization easier, it introduces a probability for nodes to simply forward the message to one select relay node instead of disseminating messages as per usual relay operation.</description>
</item>
<item>
<title>45/WAKU2-ADVERSARIAL-MODELS</title>
<link>https://rfc.vac.dev/spec/45/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<description>Abstract # This document lists adversarial models and attack-based threats relevant in the context of Waku v2.
Motivation and Background # Future versions of this document will serve as a comprehensive list of adversarial models and attack based threats relevant for Waku v2. The main purpose of this document is being a linkable resource for specifications that address protection as well as mitigation mechanisms within the listed models.
Discussing and introducing countermeasures to specific attacks in specific models is out of scope for this document.</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/46/</guid>
<description>Abstract # This document extends the libp2p gossipsub specification specifying gossipsub Tor Push, a gossipsub-internal way of pushing messages into a gossipsub network via Tor. Tor Push adds sender identity protection to gossipsub.
Protocol identifier: /meshsub/1.1.0
Note: Gossipsub Tor Push does not have a dedicated protocol identifier. It uses the same identifier as gossipsub and works with all pubsub based protocols. This allows nodes that are oblivious to Tor Push to process messages received via Tor Push.</description>
</item>
<item>
<title>47/WAKU2-TOR-PUSH</title>
<link>https://rfc.vac.dev/spec/47/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/47/</guid>
<description>Abstract # This document extends the 11/WAKU2-RELAY, specifying Waku Tor Push, which allows nodes to push messages via Tor into the Waku relay network.
Waku Tor Push builds on 46/GOSSIPSUB-TOR-PUSH.
Protocol identifier: /vac/waku/relay/2.0.0
Note: Waku Tor Push does not have a dedicated protocol identifier. It uses the same identifier as Waku relay. This allows Waku relay nodes that are oblivious to Tor Push to process messages received via Tor Push.</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/48/</guid>
<description>Abstract # This spec integrates Interep into the RLN spec. Interep is a group management protocol that allows for the creation of groups of users and the management of their membership. It is used to manage the membership of the RLN group.
Interep ties in web2 identities with reputation, and sorts the users into groups based on their reputation score. For example, a GitHub user with over 100 followers is considered to have &ldquo;gold&rdquo; reputation.</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/5/</guid>
<description>This specification describes the format of Waku messages within the ÐΞVp2p Wire Protocol. This spec substitutes EIP-627. Waku is a fork of the original Whisper protocol that enables better usability for resource restricted devices, such as mostly-offline bandwidth-constrained smartphones. It does this through (a) light node support, (b) historic messages (with a mailserver) (c) expressing topic interest for better bandwidth usage and (d) basic rate limiting.
Motivation # Waku was created to incrementally improve in areas that Whisper is lacking in, with special attention to resource restricted devices.</description>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/6/</guid>
<description>This specification describes the format of Waku packets within the ÐΞVp2p Wire Protocol. This spec substitutes EIP-627. Waku is a fork of the original Whisper protocol that enables better usability for resource restricted devices, such as mostly-offline bandwidth-constrained smartphones. It does this through (a) light node support, (b) historic envelopes (with a mailserver) (c) expressing topic interest for better bandwidth usage and (d) basic rate limiting.
Motivation # Waku was created to incrementally improve in areas that Whisper is lacking in, with special attention to resource restricted devices.</description>
flags auxiliary field payload padding signature In case of symmetric encryption, a salt (a.k.a. AES Nonce, 12 bytes) field MUST be appended.</description>
<description>Abstract # In this specification, we describe Mailservers. These are nodes responsible for archiving envelopes and delivering them to peers on-demand.
Specification # A node which wants to provide mailserver functionality MUST store envelopes from incoming Messages packets (Waku packet-code 0x01). The envelopes can be stored in any format, however they MUST be serialized and deserialized to the Waku envelope format.
A mailserver SHOULD store envelopes for all topics to be generally useful for any peer, however for specific use cases it MAY store envelopes for a subset of topics.</description>
</item>
<item>
<title>9/WAKU-RPC</title>
<link>https://rfc.vac.dev/spec/9/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://rfc.vac.dev/spec/9/</guid>
<description>This specification describes the RPC API that Waku nodes MAY adhere to. The unified API allows clients to easily be able to connect to any node implementation. The API described is privileged as a node stores the keys of clients.
<description>(Info, remove this section) # This section contains meta info about writing RFCs. This section (including its subsections) MUST be removed.
waku/core-protocol for Waku protocol definitions (e.g. store, relay, light push), waku/application for applications built on top of Waku protocol (e.g. eth-dm, toy-chat), Abstract # Background / Rationale / Motivation # This section serves as an introduction providing background information and a motivation/rationale for why the specified protocol is useful.</description>
