mirror of https://github.com/vacp2p/rfc.git
658 lines
48 KiB
XML
658 lines
48 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
|
|
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
|
<channel>
|
|
<title>Docs on Vac RFC</title>
|
|
<link>https://rfc.vac.dev/docs/</link>
|
|
<description>Recent content in Docs on Vac RFC</description>
|
|
<generator>Hugo -- gohugo.io</generator>
|
|
<language>en-us</language><atom:link href="https://rfc.vac.dev/docs/index.xml" rel="self" type="application/rss+xml" />
|
|
<item>
|
|
<title>1/COSS</title>
|
|
<link>https://rfc.vac.dev/spec/1/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>10/WAKU2</title>
|
|
<link>https://rfc.vac.dev/spec/10/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/10/</guid>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>11/WAKU2-RELAY</title>
|
|
<link>https://rfc.vac.dev/spec/11/</link>
|
|
<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 # Protocol identifier*: /vac/waku/filter/2.0.0-beta1
|
|
Content filtering is a way to do message-based filtering. Currently the only content filter being applied is on contentTopic.</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>previous versions: 00
|
|
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 # Protocol identifiers:
|
|
filter-subscribe: /vac/waku/filter-subscribe/2.0.0-beta1 filter-push: /vac/waku/filter-push/2.0.0-beta1 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.
|
|
Protocol identifier*: /vac/waku/store/2.0.0-beta4
|
|
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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>14/WAKU2-MESSAGE</title>
|
|
<link>https://rfc.vac.dev/spec/14/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/14/</guid>
|
|
<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).
|
|
Publishing such packet will require the creation of a new Message with a new WakuMessage as data field.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>16/WAKU2-RPC</title>
|
|
<link>https://rfc.vac.dev/spec/16/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/16/</guid>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>17/WAKU2-RLN-RELAY</title>
|
|
<link>https://rfc.vac.dev/spec/17/</link>
|
|
<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.
|
|
Motivation # In open and anonymous p2p messaging networks, one big problem is spam resistance.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>18/WAKU2-SWAP</title>
|
|
<link>https://rfc.vac.dev/spec/18/</link>
|
|
<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.
|
|
Protocol identifier*: /vac/waku/swap/2.0.0-beta1
|
|
Motivation # The Waku network makes up a service network, and some nodes provide a useful service to other nodes.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>19/WAKU2-LIGHTPUSH</title>
|
|
<link>https://rfc.vac.dev/spec/19/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/19/</guid>
|
|
<description>Protocol identifier: /vac/waku/lightpush/2.0.0-beta1
|
|
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).
|
|
19/WAKU2-LIGHTPUSH is a request/response protocol for this.
|
|
Payloads # syntax = &#34;proto3&#34;; message PushRequest { string pubsub_topic = 1; WakuMessage message = 2; } message PushResponse { bool is_success = 1; // Error messages, etc string info = 2; } message PushRPC { string request_id = 1; PushRequest request = 2; PushResponse response = 3; } Message Relaying # Nodes that respond to PushRequests MUST either relay the encapsulated message via 11/WAKU2-RELAY protocol on the specified pubsub_topic, or forward the PushRequest via 19/LIGHTPUSH on a 44/WAKU2-DANDELION stem.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>2/MVDS</title>
|
|
<link>https://rfc.vac.dev/spec/2/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>20/TOY-ETH-PM</title>
|
|
<link>https://rfc.vac.dev/spec/20/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/20/</guid>
|
|
<description>Content Topics:
|
|
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>
|
|
|
|
<guid>https://rfc.vac.dev/spec/22/</guid>
|
|
<description>Content Topic: /toy-chat/2/huilong/proto.
|
|
This specification explains a toy chat example using Waku v2. This protocol is mainly used to:
|
|
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.
|
|
Note that this is completely separate from the protocol the Status app is using for its chat functionality.
|
|
Design # The chat protocol enables sending and receiving messages in a chat room.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>23/WAKU2-TOPICS</title>
|
|
<link>https://rfc.vac.dev/spec/23/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/23/</guid>
|
|
<description>This document outlines recommended usage of topic names in Waku v2. In 10/WAKU2 spec there are two types of topics:
|
|
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), and can be named implicitly by Waku sharding (see 51/WAKU2-RELAY-SHARDING). This document comprises recommendations for explicitly naming pubsub topics (e.g. when choosing named sharding as specified in 51/WAKU2-RELAY-SHARDING).</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>24/STATUS-CURATION</title>
|
|
<link>https://rfc.vac.dev/spec/24/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/24/</guid>
|
|
<description>Abstract # This specification is a voting protocol for peers to submit votes to a smart contract. Voting is immutable, this will help avoid sabotage from malicious peers.
|
|
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.
|
|
Proposed solution is to aggregate votes over waku and allow users to submit votes to smart contract that aren&rsquo;t already submitted.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>25/LIBP2P-DNS-DISCOVERY</title>
|
|
<link>https://rfc.vac.dev/spec/25/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>26/WAKU2-PAYLOAD</title>
|
|
<link>https://rfc.vac.dev/spec/26/</link>
|
|
<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>Abstract # This specification describes a voting method to feature different active Status Communities.
|
|
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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>30/ADAPTIVE-NODES</title>
|
|
<link>https://rfc.vac.dev/spec/30/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/30/</guid>
|
|
<description>This is an informational spec that show cases the concept of adaptive nodes.
|
|
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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>31/WAKU2-ENR</title>
|
|
<link>https://rfc.vac.dev/spec/31/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/31/</guid>
|
|
<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].
|
|
This RFC is an extension of EIP-778, ENR used in Waku v2 MUST adhere to both EIP-778 and 31/WAKU2-ENR.
|
|
Motivation # EIP-1459 with the usage of ENR has been implemented [1] [2] as a discovery protocol for Waku v2.
|
|
EIP-778 specifies a number of pre-defined keys.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>32/RLN-V1</title>
|
|
<link>https://rfc.vac.dev/spec/32/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/32/</guid>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>33/WAKU2-DISCV5</title>
|
|
<link>https://rfc.vac.dev/spec/33/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/33/</guid>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>34/WAKU2-PEER-EXCHANGE</title>
|
|
<link>https://rfc.vac.dev/spec/34/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/34/</guid>
|
|
<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.
|
|
Protocol identifier: /vac/waku/peer-exchange/2.0.0-alpha1
|
|
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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>35/WAKU2-NOISE</title>
|
|
<link>https://rfc.vac.dev/spec/35/</link>
|
|
<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>
|
|
|
|
<guid>https://rfc.vac.dev/spec/36/</guid>
|
|
<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.
|
|
An alternative is to link existing Waku implementation as a static or dynamic library in their application.
|
|
This specification describes the C API that SHOULD be implemented by native Waku library and that SHOULD be used to consume them.
|
|
Design requirements # The API should be generic enough, so:</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>37/WAKU2-NOISE-SESSIONS</title>
|
|
<link>https://rfc.vac.dev/spec/37/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/37/</guid>
|
|
<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.
|
|
Once two users complete a Noise handshake, an encryption/decryption session - or a Noise session - would be instantiated.
|
|
This post provides an overview on how we can possibly implement and manage one or multiple Noise sessions in Waku.
|
|
Preliminaries # We assume that two users, e.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>38/CONSENSUS-CLARO</title>
|
|
<link>https://rfc.vac.dev/spec/38/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>4/MVDS-META</title>
|
|
<link>https://rfc.vac.dev/spec/4/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>43/WAKU2-DEVICE-PAIRING</title>
|
|
<link>https://rfc.vac.dev/spec/43/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/43/</guid>
|
|
<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>
|
|
|
|
<guid>https://rfc.vac.dev/spec/44/</guid>
|
|
<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>
|
|
|
|
<guid>https://rfc.vac.dev/spec/45/</guid>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>46/GOSSIPSUB-TOR-PUSH</title>
|
|
<link>https://rfc.vac.dev/spec/46/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>48/RLN-INTEREP-SPEC</title>
|
|
<link>https://rfc.vac.dev/spec/48/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>5/WAKU0</title>
|
|
<link>https://rfc.vac.dev/spec/5/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>51/WAKU2-RELAY-SHARDING</title>
|
|
<link>https://rfc.vac.dev/spec/51/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/51/</guid>
|
|
<description>Abstract # This document describes ways of sharding the Waku relay topic, allowing Waku networks to scale in the number of content topics.
|
|
Note: Scaling in the size of a single content topic is out of scope for this document.
|
|
Background and Motivation # Unstructured P2P networks are more robust and resilient against DoS attacks compared to structured P2P networks). However, they do not scale to large traffic loads. A single libp2p gossipsub mesh, which carries messages associated with a single pubsub topic, can be seen as a separate unstructured P2P network (control messages go beyond these boundaries, but at its core, it is a separate P2P network).</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>52/WAKU2-RELAY-STATIC-SHARD-ALLOC</title>
|
|
<link>https://rfc.vac.dev/spec/52/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/52/</guid>
|
|
<description>Abstract # This document lists static shard flag index assignments (see 51/WAKU2-RELAY-SHARDING.
|
|
Background # Similar to the IANA port allocation, this document lists static shard index assignments (see 51/WAKU2-RELAY-SHARDING.
|
|
Assingment Process # Note: Future versions of this document will specify the assignment process.
|
|
List of Cluster Ids # index Protocol/App Description 0 global global use 1 reserved The Waku Network 2 reserved 3 reserved 4 reserved 5 reserved 6 reserved 7 reserved 8 reserved 9 reserved 10 reserved 11 reserved 12 reserved 13 reserved 14 reserved 15 reserved 16 Status Status main net 17 Status 18 Status Copyright # Copyright and related rights waived via CC0.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>53/WAKU2-X3DH</title>
|
|
<link>https://rfc.vac.dev/spec/53/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/53/</guid>
|
|
<description>Abstract # This document describes a method that can be used to provide a secure channel between two peers, and thus provide confidentiality, integrity, authenticity and forward secrecy. It is transport-agnostic and works over asynchronous networks.
|
|
It builds on the X3DH and Double Ratchet specifications, with some adaptations to operate in a decentralized environment.
|
|
Motivation # Nodes on a network may want to communicate with each other in a secure manner, without other nodes network being able to read their messages.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>54/WAKU2-X3DH-SESSIONS</title>
|
|
<link>https://rfc.vac.dev/spec/54/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/54/</guid>
|
|
<description>Abstract # This document specifies how to manage sessions based on an X3DH key exchange. This includes how to establish new sessions, how to re-establish them, how to maintain them, and how to close them.
|
|
53/WAKU2-X3DH specifies the Waku X3DH protocol for end-to-end encryption. Once two peers complete an X3DH handshake, they SHOULD establish an X3DH session.
|
|
Session Establishment # A node identifies a peer by their installation-id which MAY be interpreted as a device identifier.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>55/STATUS-1TO1-CHAT</title>
|
|
<link>https://rfc.vac.dev/spec/55/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/55/</guid>
|
|
<description>Abstract # This specification describes how the Status 1-to-1 chat protocol is implemented on top of the Waku v2 protocol. This protocol can be used to send messages to a single recipient.
|
|
Terminology # Participant: A participant is a user that is able to send and receive messages. 1-to-1 chat: A chat between two participants. Public chat: A chat where any participant can join and read messages. Private chat: A chat where only invited participants can join and read messages.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>56/STATUS-COMMUNITIES</title>
|
|
<link>https://rfc.vac.dev/spec/56/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/56/</guid>
|
|
<description>Abstract # This document describes the design of Status Communities over Waku v2, allowing for multiple users to communicate in a group chat. This is a key feature for the Status messaging app.
|
|
Background and Motivation # The purpose of Status communities, as specified in this document, is allowing for large group chats. Communities can have further substructure, e.g. specific channels.
|
|
Smaller group chats, on the other hand, are out of scope for this document and can be built over 55/STATUS-1TO1-CHAT.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>57/STATUS-Simple-Scaling</title>
|
|
<link>https://rfc.vac.dev/spec/57/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/57/</guid>
|
|
<description>Abstract # This document describes how to scale 56/STATUS-COMMUNITIES as well as 55/STATUS-1TO1-CHAT using existing Waku v2 protocols and components. It also adds a few new aspects, where more sophisticated components are not yet researched and evaluated.
|
|
Note: (Parts of) this RFC will be deprecated in the future as we continue research to scale specific components in a way that aligns better with our principles of decentralization and protecting anonymity.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>58/RLN-V2</title>
|
|
<link>https://rfc.vac.dev/spec/58/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/58/</guid>
|
|
<description>Abstract # The protocol specified in this document is an improvement of 32/RLN-V1, being more general construct, that allows to set various limits for an epoch (it&rsquo;s 1 message per epoch in 32/RLN-V1) while remaining almost as simple as it predecessor. Moreover, it allows to set different rate-limits for different RLN app users based on some public data, e.g. stake or reputation.
|
|
Motivation # The main goal of this RFC is to generalize 32/RLN-V1 and expand its applications.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>6/WAKU1</title>
|
|
<link>https://rfc.vac.dev/spec/6/</link>
|
|
<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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>61/STATUS-Community-History-Archives</title>
|
|
<link>https://rfc.vac.dev/spec/61/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/61/</guid>
|
|
<description>Abstract # Messages are stored permanently by store nodes (13/WAKU2-STORE) for up to a certain configurable period of time, limited by the overall storage provided by a store node. Messages older than that period are no longer provided by store nodes, making it impossible for other nodes to request historical messages that go beyond that time range. This raises issues in the case of Status communities, where recently joined members of a community are not able to request complete message histories of the community channels.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>63/STATUS-Keycard-Usage</title>
|
|
<link>https://rfc.vac.dev/spec/63/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/63/</guid>
|
|
<description>Terminology # Account: A valid BIP-32 compliant key. Multiaccount: An account from which multiple Accounts can be derived. Abstract # This specification describes how an application can use the Status Keycard to -
|
|
Create Multiaccounts Store Multiaccounts Use Multiaccounts for transaction or message signing Derive Accounts from Multiaccounts More documentation on the Status Keycard can be found here
|
|
Motivation # The Status Keycard is a hardware wallet that can be used to store and sign transactions.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>64/WAKU2-NETWORK</title>
|
|
<link>https://rfc.vac.dev/spec/64/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/64/</guid>
|
|
<description>Abstract # This RFC specifies an opinionated deployment of 10/WAKU2 protocols to form a coherent and shared decentralized messaging network that is open-access, useful for generalized messaging, privacy-preserving, scalable and accessible even to resource-restricted devices. We&rsquo;ll refer to this opinionated deployment simply as the public Waku Network, the Waku Network or, if the context is clear, the network in the rest of this document.
|
|
Theory / Semantics # Routing protocol # The Waku Network is built on the 17/WAKU2-RLN-RELAY routing protocol, which in turn is an extension of 11/WAKU2-RELAY with spam protection measures.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>65/STATUS-ACCOUNTS</title>
|
|
<link>https://rfc.vac.dev/spec/65/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/65/</guid>
|
|
<description>Abstract # This specification explains what a Status account is, and how it is created and used.
|
|
Background # The core concept of an account in Status is a set of cryptographic keypairs. Namely, the combination of the following:
|
|
a Waku chat identity keypair a set of cryptocurrency wallet keypairs The Status node verifies or derives everything else associated with the contact from the above items, including:
|
|
Ethereum address (future verification, currently the same base keypair) identicon message signatures Initial Key Generation # Public/Private Keypairs # An ECDSA (secp256k1 curve) public/private keypair MUST be generated via a BIP43 derived path from a BIP39 mnemonic seed phrase.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>66/WAKU2-METADATA</title>
|
|
<link>https://rfc.vac.dev/spec/66/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/66/</guid>
|
|
<description>Metadata Protocol # Waku specifies a req/resp protocol that provides information about the node&rsquo;s medatadata. Such metadata is meant to be used by the node to decide if a peer is worth connecting or not. The node that makes the request, includes its metadata so that the receiver is aware of it, without requiring an extra interaction. The parameters are the following:
|
|
clusterId: Unique identifier of the cluster that the node is running in.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>7/WAKU-DATA</title>
|
|
<link>https://rfc.vac.dev/spec/7/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/7/</guid>
|
|
<description>This specification describes the encryption, decryption and signing of the content in the data field used in Waku.
|
|
Specification # The data field is used within the waku envelope, the field MUST contain the encrypted payload of the envelope.
|
|
The fields that are concatenated and encrypted as part of the data field are:
|
|
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>
|
|
</item>
|
|
|
|
<item>
|
|
<title>70/ETH-SECPM</title>
|
|
<link>https://rfc.vac.dev/spec/70/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/70/</guid>
|
|
<description>Abstract # This document specifies an Ethereum-based private messaging service. This proposal is built upon this model and amends the limitations of the latter concerning forward privacy and authentication. The document is still work in progress. Next steps will include a description of how to implement the different functions and algorithms in terms of the Noise framework.
|
|
Background # Alice wants to send an encrypted message to Bob. Here Bob is the only individual able to decrypt the message.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>8/WAKU-MAIL</title>
|
|
<link>https://rfc.vac.dev/spec/8/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/8/</guid>
|
|
<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.
|
|
Introduction # This API is based off the Whisper V6 RPC API.
|
|
Wire Protocol # Transport # Nodes SHOULD expose a JSON RPC API that can be accessed. The JSON RPC version SHOULD be 2.</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>XX/(WAKU2|LOGOS|CODEX|*)-TEMPLATE</title>
|
|
<link>https://rfc.vac.dev/spec/xx/</link>
|
|
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
|
|
|
<guid>https://rfc.vac.dev/spec/xx/</guid>
|
|
<description>(Info, remove this section) # This section contains meta info about writing RFCs. This section (including its subsections) MUST be removed.
|
|
COSS explains the Vac RFC process.
|
|
Tags # The tags metadata SHOULD contain a list of tags if applicable.
|
|
Currently identified tags comprise
|
|
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>
|
|
</item>
|
|
|
|
</channel>
|
|
</rss>
|