From 276328e60b08dc14a13256ef4de3e868519cf2ac Mon Sep 17 00:00:00 2001 From: Filip Pajic Date: Thu, 25 Apr 2024 09:32:56 +0200 Subject: [PATCH] chore: MD content updates --- nomos/{ => 38}/claro.md | 1 - status/{ => 24}/curation.md | 1 - status/{ => 28}/featuring.md | 1 - status/{ => 55}/1to1-chat.md | 27 +- status/{ => 56}/communities.md | 51 ++-- status/{ => 61}/community-history-service.md | 37 ++- status/{ => 62}/payloads.md | 7 +- status/{ => 63}/keycard-usage.md | 1 - status/{ => 65}/account-address.md | 17 +- status/{ => 71}/push-notification-server.md | 57 ++-- status/{ => raw}/simple-scaling.md | 108 +++---- status/{ => raw}/status-waku-usage.md | 1 - vac/{ => 1}/coss.md | 11 +- vac/{ => 2}/mvds.md | 3 +- vac/{ => 25}/libp2p-dns-discovery.md | 5 +- vac/{ => 3}/remote-log.md | 3 +- vac/{ => 32}/rln-v1.md | 3 +- vac/{ => 4}/mvds-meta.md | 11 +- vac/{ => 46}/gossipsub-tor-push.md | 17 +- vac/{ => 48}/rln-interep-spec.md | 11 +- vac/{ => 58}/rln-v2.md | 23 +- vac/{ => 70}/eth-secpm.md | 3 +- vac/raw/README.md | 2 +- vac/{ => raw}/rln-stealth-commitments.md | 21 +- vac/template.md | 1 - waku/README.md | 2 +- waku/deprecated/{ => 16}/rpc.md | 57 ++-- waku/deprecated/{ => 18}/swap.md | 5 +- waku/deprecated/{ => 5}/waku0.md | 17 +- waku/deprecated/README.md | 2 +- waku/informational/{ => 22}/toy-chat.md | 1 - waku/informational/{ => 23}/topics.md | 51 ++-- waku/informational/{ => 27}/peers.md | 19 +- waku/informational/{ => 29}/config.md | 19 +- waku/informational/{ => 30}/adaptive-nodes.md | 15 +- .../application/{ => 20}/toy-eth-pm.md | 17 +- .../{ => 21}/fault-tolerant-store.md | 17 +- .../standards/application/{ => 26}/payload.md | 23 +- waku/standards/application/{ => 53}/x3dh.md | 7 +- .../application/{ => 54}/x3dh-sessions.md | 7 +- waku/standards/core/{ => 10}/waku2.md | 155 +++++----- waku/standards/core/{ => 11}/relay.md | 41 ++- waku/standards/core/12/filter.md | 207 +++++++++---- .../core/12/previous-versions00/filter.md | 182 ++++++++++++ waku/standards/core/{ => 13}/store.md | 23 +- waku/standards/core/{ => 14}/message.md | 19 +- waku/standards/core/{ => 15}/bridge.md | 1 - waku/standards/core/{ => 17}/rln-relay.md | 31 +- waku/standards/core/{ => 19}/lightpush.md | 13 +- waku/standards/core/{ => 33}/discv5.md | 45 ++- waku/standards/core/{ => 36}/bindings-api.md | 27 +- waku/standards/core/{ => 66}/metadata.md | 5 +- waku/standards/core/filter.md | 279 ------------------ waku/standards/legacy/{ => 6}/waku1.md | 21 +- waku/standards/legacy/{ => 7}/data.md | 3 +- waku/standards/legacy/{ => 8}/mail.md | 5 +- waku/standards/legacy/{ => 9}/rpc.md | 3 +- 57 files changed, 845 insertions(+), 897 deletions(-) rename nomos/{ => 38}/claro.md (99%) rename status/{ => 24}/curation.md (99%) rename status/{ => 28}/featuring.md (99%) rename status/{ => 55}/1to1-chat.md (91%) rename status/{ => 56}/communities.md (89%) rename status/{ => 61}/community-history-service.md (93%) rename status/{ => 62}/payloads.md (99%) rename status/{ => 63}/keycard-usage.md (99%) rename status/{ => 65}/account-address.md (90%) rename status/{ => 71}/push-notification-server.md (92%) rename status/{ => raw}/simple-scaling.md (89%) rename status/{ => raw}/status-waku-usage.md (99%) rename vac/{ => 1}/coss.md (97%) rename vac/{ => 2}/mvds.md (99%) rename vac/{ => 25}/libp2p-dns-discovery.md (95%) rename vac/{ => 3}/remote-log.md (96%) rename vac/{ => 32}/rln-v1.md (99%) rename vac/{ => 4}/mvds-meta.md (86%) rename vac/{ => 46}/gossipsub-tor-push.md (95%) rename vac/{ => 48}/rln-interep-spec.md (96%) rename vac/{ => 58}/rln-v2.md (85%) rename vac/{ => 70}/eth-secpm.md (99%) rename vac/{ => raw}/rln-stealth-commitments.md (86%) rename waku/deprecated/{ => 16}/rpc.md (86%) rename waku/deprecated/{ => 18}/swap.md (98%) rename waku/deprecated/{ => 5}/waku0.md (98%) rename waku/informational/{ => 22}/toy-chat.md (98%) rename waku/informational/{ => 23}/topics.md (78%) rename waku/informational/{ => 27}/peers.md (88%) rename waku/informational/{ => 29}/config.md (90%) rename waku/informational/{ => 30}/adaptive-nodes.md (85%) rename waku/standards/application/{ => 20}/toy-eth-pm.md (96%) rename waku/standards/application/{ => 21}/fault-tolerant-store.md (71%) rename waku/standards/application/{ => 26}/payload.md (86%) rename waku/standards/application/{ => 53}/x3dh.md (98%) rename waku/standards/application/{ => 54}/x3dh-sessions.md (97%) rename waku/standards/core/{ => 10}/waku2.md (80%) rename waku/standards/core/{ => 11}/relay.md (88%) create mode 100644 waku/standards/core/12/previous-versions00/filter.md rename waku/standards/core/{ => 13}/store.md (97%) rename waku/standards/core/{ => 14}/message.md (95%) rename waku/standards/core/{ => 15}/bridge.md (99%) rename waku/standards/core/{ => 17}/rln-relay.md (93%) rename waku/standards/core/{ => 19}/lightpush.md (86%) rename waku/standards/core/{ => 33}/discv5.md (87%) rename waku/standards/core/{ => 36}/bindings-api.md (98%) rename waku/standards/core/{ => 66}/metadata.md (93%) delete mode 100644 waku/standards/core/filter.md rename waku/standards/legacy/{ => 6}/waku1.md (98%) rename waku/standards/legacy/{ => 7}/data.md (95%) rename waku/standards/legacy/{ => 8}/mail.md (98%) rename waku/standards/legacy/{ => 9}/rpc.md (99%) diff --git a/nomos/claro.md b/nomos/38/claro.md similarity index 99% rename from nomos/claro.md rename to nomos/38/claro.md index aebf54143..39a300a2c 100644 --- a/nomos/claro.md +++ b/nomos/38/claro.md @@ -10,7 +10,6 @@ uri: \ contributors: - Álvaro Castro-Castilla - Mark Evenson -sidebar_position: 38 --- - Status: raw - Category: Standards Track diff --git a/status/curation.md b/status/24/curation.md similarity index 99% rename from status/curation.md rename to status/24/curation.md index e7eed383d..0788848ba 100644 --- a/status/curation.md +++ b/status/24/curation.md @@ -4,7 +4,6 @@ name: Status Community Directory Curation Voting using Waku v2 status: draft description: A voting protocol for SNT holders to submit votes to a smart contract. Voting is immutable, which helps avoid sabotage from malicious peers. editor: Szymon Szlachtowicz \ -sidebar_position: 24 --- - Status: draft - Editor: Szymon Szlachtowicz \ diff --git a/status/featuring.md b/status/28/featuring.md similarity index 99% rename from status/featuring.md rename to status/28/featuring.md index ef9d17061..f08a830a7 100644 --- a/status/featuring.md +++ b/status/28/featuring.md @@ -4,7 +4,6 @@ name: Status community featuring using waku v2 status: draft description: To gain new members, current SNT holders can vote to feature an active Status community to the larger Status audience. editor: Szymon Szlachtowicz \ -sidebar_position: 28 --- - Status: draft - Editor: Szymon Szlachtowicz \ diff --git a/status/1to1-chat.md b/status/55/1to1-chat.md similarity index 91% rename from status/1to1-chat.md rename to status/55/1to1-chat.md index 4c42d14a4..7490293a8 100644 --- a/status/1to1-chat.md +++ b/status/55/1to1-chat.md @@ -11,7 +11,6 @@ contributors: - Corey Petty \ - Oskar Thorén \ - Dean Eigenmann \ -sidebar_position: 55 --- - Status: draft - Category: Standards Track @@ -43,8 +42,8 @@ This document describes how 2 peers communicate with each other to send messages This protocol MAY use any key-exchange mechanism previously discussed - -1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) -2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md) +1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) +2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise) This protocol can provide end-to-end encryption to give peers a strong degree of privacy and security. Public chat messages are publicly readable by anyone since there's no permission model for who is participating in a public chat. @@ -58,7 +57,7 @@ There are two phases in the initial negotiation of a 1:1 chat: A QR code serves two purposes simultaneously - identity verification and initial key material retrieval; 1. **Asynchronous initial key exchange** -For more information on account generation and trust establishment, see [65/ACCOUNT-ADDRESS](../65/account-address.md) +For more information on account generation and trust establishment, see [65/ACCOUNT-ADDRESS](../65/account-address) ### Post Negotiation @@ -69,9 +68,9 @@ After the peers have shared their public key material, a 1:1 chat can be establi The 1:1 chat is made robust by having sessions between peers. It is handled by the key-exchange protocol used. For example, -1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md), the session management is described in [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md) +1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh), the session management is described in [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions) -2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md), the session management is described in [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md) +2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise), the session management is described in [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions) ## Negotiation of a 1:1 chat amongst multiple participants (group chat) @@ -83,7 +82,7 @@ However, this method does not scale as the number of participants increases, for 1. The number of messages sent over the network increases with the number of participants. 2. Handling the X3DH key exchange for each participant is computationally expensive. -The above issues are addressed in [56/STATUS-COMMUNITIES](../56/communities.md), with other trade-offs. +The above issues are addressed in [56/STATUS-COMMUNITIES](../56/communities), with other trade-offs. ### Flow @@ -209,7 +208,7 @@ To change the display image of the group chat, group admins MUST use an `IMAGE_C ## Security Considerations -1. Inherits the security considerations of the key-exchange mechanism used, e.g., [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) or [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md) +1. Inherits the security considerations of the key-exchange mechanism used, e.g., [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) or [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise) ## Copyright @@ -217,11 +216,11 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) -2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md) -3. [65/STATUS-ACCOUNT](../65/account-address.md) -4. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md) -5. [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md) -6. [56/STATUS-COMMUNITIES](../56/communities.md) +1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) +2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise) +3. [65/STATUS-ACCOUNT](../65/account-address) +4. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions) +5. [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions) +6. [56/STATUS-COMMUNITIES](../56/communities) 7. [chat_message.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/chat_message.proto#L1) 8. [emoji_reaction.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/emoji_reaction.proto) diff --git a/status/communities.md b/status/56/communities.md similarity index 89% rename from status/communities.md rename to status/56/communities.md index 639a59879..76afb92a5 100644 --- a/status/communities.md +++ b/status/56/communities.md @@ -7,7 +7,6 @@ description: Status Communities allow multiple users to communicate in a discuss editor: Aaryamann Challani \ contributors: - Andrea Piana \ -sidebar_position: 56 --- - Status: draft - Category: Standards Track @@ -25,10 +24,10 @@ This is a key feature for the Status messaging app. 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](../55/1to1-chat.md). +Smaller group chats, on the other hand, are out of scope for this document and can be built over [55/STATUS-1TO1-CHAT](../55/1to1-chat). We refer to these smaller group chats simply as "group chats", to differentiate them from Communities. -For group chats based on [55/STATUS-1TO1-CHAT](../55/1to1-chat.md), the key exchange mechanism MUST be X3DH, as described in [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md). +For group chats based on [55/STATUS-1TO1-CHAT](../55/1to1-chat), the key exchange mechanism MUST be X3DH, as described in [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh). However, this method does not scale as the number of participants increases, for the following reasons - 1. The number of messages sent over the network increases with the number of participants. @@ -59,7 +58,7 @@ This extends to banning and kicking members. 8. The public key of the Community is shared out of band. 9. The metadata of the Community can be found by listening on a content topic derived from the public key of the Community. 10. Community members run their own Waku nodes, with the configuration described in [Waku-Protocols](#waku-protocols). -Light nodes solely implementing [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) may not be able to run their own Waku node with the configuration described. +Light nodes solely implementing [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush) may not be able to run their own Waku node with the configuration described. ## Design @@ -293,7 +292,7 @@ Note: The usage of the clock is described in the [Clock](#clock) section. ### Content topic usage -"Content topic" refers to the field in [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md/#message-attributes), further elaborated in [10/WAKU2](../../waku/standards/core/10/waku2.md/#overview-of-protocol-interaction). +"Content topic" refers to the field in [14/WAKU2-MESSAGE](../../waku/standards/core/14/message#message-attributes), further elaborated in [10/WAKU2](../../waku/standards/core/10/waku2#overview-of-protocol-interaction). #### Advertising a Community @@ -378,7 +377,7 @@ The Community metadata SHOULD be sent every time the Community metadata is updat #### Community Join Flow (peer requests to join a Community) -1. A peer and the Community owner establish a 1:1 chat as described in [55/STATUS-1TO1-CHAT](../55/1to1-chat.md). +1. A peer and the Community owner establish a 1:1 chat as described in [55/STATUS-1TO1-CHAT](../55/1to1-chat). 2. The peer requests to join a Community by sending a "CommunityRequestToJoin" message to the Community. At this point, the peer MAY send a "CommunityCancelRequestToJoin" message to cancel the request. 3. The Community owner MAY accept or reject the request. @@ -387,7 +386,7 @@ At this point, the peer MAY send a "CommunityCancelRequestToJoin" message to can #### Community Join Flow (peer is invited to join a Community) -1. The Community owner and peer establish a 1:1 chat as described in [55/STATUS-1TO1-CHAT](../55/1to1-chat.md). +1. The Community owner and peer establish a 1:1 chat as described in [55/STATUS-1TO1-CHAT](../55/1to1-chat). 2. The peer is invited to join a Community by the Community owner, by sending a "CommunityInvitation" message. 3. The peer decrypts the "CommunityInvitation" message, and verifies the signature. 4. The peer requests to join a Community by sending a "CommunityRequestToJoin" message to the Community. @@ -410,23 +409,23 @@ At this point, the peer MAY send a "CommunityCancelRequestToJoin" message to can The following Waku protocols SHOULD be used to implement Status Communities - -1. [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) - To send and receive messages -2. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) - To encrypt and decrypt messages -3. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md) - To handle session keys -4. [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md) - To wrap community messages in a Waku message -5. [13/WAKU2-STORE](../../waku/standards/core/13/store.md) - To store and retrieve messages for offline devices +1. [11/WAKU2-RELAY](../../waku/standards/core/11/relay) - To send and receive messages +2. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) - To encrypt and decrypt messages +3. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions) - To handle session keys +4. [14/WAKU2-MESSAGE](../../waku/standards/core/14/message) - To wrap community messages in a Waku message +5. [13/WAKU2-STORE](../../waku/standards/core/13/store) - To store and retrieve messages for offline devices The following Waku protocols MAY be used to implement Status Communities - -1. [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md) - Content filtering for resource restricted devices -2. [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) - Allows Light clients to participate in the network +1. [12/WAKU2-FILTER](../../waku/standards/core/12/filter) - Content filtering for resource restricted devices +2. [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush) - Allows Light clients to participate in the network ### Backups The member MAY back up their local settings, by encrypting it with their public key, and sending it to a given content topic. The member MAY then rely on this backup to restore their local settings, in case of a data loss. -This feature relies on [13/WAKU2-STORE](../../waku/standards/core/13/store.md) for storing and retrieving messages. +This feature relies on [13/WAKU2-STORE](../../waku/standards/core/13/store) for storing and retrieving messages. ### Clock @@ -438,7 +437,7 @@ This allows ordering of messages in an asynchronous network where messages may b 1. The Community owner is a single point of failure. If the Community owner is compromised, the Community is compromised. -2. Follows the same security considerations as the [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) protocol. +2. Follows the same security considerations as the [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) protocol. ## Future work @@ -454,16 +453,16 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -- [55/STATUS-1TO1-CHAT](../55/1to1-chat.md) -- [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) -- [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) -- [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md) -- [10/WAKU2](../../waku/standards/core/10/waku2.md) -- [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) -- [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md) -- [13/WAKU2-STORE](../../waku/standards/core/13/store.md) -- [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md) +- [55/STATUS-1TO1-CHAT](../55/1to1-chat) +- [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) +- [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush) +- [14/WAKU2-MESSAGE](../../waku/standards/core/14/message) +- [10/WAKU2](../../waku/standards/core/10/waku2) +- [11/WAKU2-RELAY](../../waku/standards/core/11/relay) +- [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions) +- [13/WAKU2-STORE](../../waku/standards/core/13/store) +- [12/WAKU2-FILTER](../../waku/standards/core/12/filter) ### informative - [community.go](https://github.com/status-im/status-go/blob/6072bd17ab1e5d9fc42cf844fcb8ad18aa07760c/protocol/communities/community.go) -- [organisation-channels.md](https://github.com/status-im/specs/blob/403b5ce316a270565023fc6a1f8dec138819f4b0/docs/raw/organisation-channels.md) +- [organisation-channels.md](https://github.com/status-im/specs/blob/403b5ce316a270565023fc6a1f8dec138819f4b0/docs/raw/organisation-channels) diff --git a/status/community-history-service.md b/status/61/community-history-service.md similarity index 93% rename from status/community-history-service.md rename to status/61/community-history-service.md index e5fdd9451..634f17b74 100644 --- a/status/community-history-service.md +++ b/status/61/community-history-service.md @@ -8,7 +8,6 @@ editor: r4bbit \ contributors: - Sanaz Taheri \ - John Lea \ -sidebar_position: 61 --- - Status: draft - Category: Standards Track @@ -19,7 +18,7 @@ sidebar_position: 61 ## Abstract -Messages are stored permanently by store nodes ([13/WAKU2-STORE](../../waku/standards/core/13/store.md)) for up to a certain configurable period of time, limited by the overall storage provided by a store node. +Messages are stored permanently by store nodes ([13/WAKU2-STORE](../../waku/standards/core/13/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. @@ -32,9 +31,9 @@ The following terminology is used throughout this specification. Notice that som | Name | References | | -------------------- | --- | -| Waku node | An Waku node ([10/WAKU2](../../waku/standards/core/10/waku2.md)) that implements [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)| -| Store node | A Waku node that implements [13/WAKU2-STORE](../../waku/standards/core/13/store.md) | -| Waku network | A group of Waku nodes forming a graph, connected via [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) | +| Waku node | An Waku node ([10/WAKU2](../../waku/standards/core/10/waku2)) that implements [11/WAKU2-RELAY](../../waku/standards/core/11/relay)| +| Store node | A Waku node that implements [13/WAKU2-STORE](../../waku/standards/core/13/store) | +| Waku network | A group of Waku nodes forming a graph, connected via [11/WAKU2-RELAY](../../waku/standards/core/11/relay) | | Status user | An Status account that is used in a Status consumer product, such as Status Mobile or Status Desktop | | Status node | A Status client run by a Status application | | Control node | A Status node that owns the private key for a Status community | @@ -49,7 +48,7 @@ The following terminology is used throughout this specification. Notice that som This specification has the following assumptions: -- Store nodes([13/WAKU2-STORE](../../waku/standards/core/13/store.md)) are available 24/7, ensuring constant live message availability. +- Store nodes([13/WAKU2-STORE](../../waku/standards/core/13/store)) are available 24/7, ensuring constant live message availability. - The storage time range limit is 30 days. - Store nodes have enough storage to persist historical messages for up to 30 days. - No store nodes have storage to persist historical messages older than 30 days. @@ -96,10 +95,10 @@ If the control node goes offline (where "offline" means, the control node's main Community member nodes go through the following (high level) process to fetch and restore community message histories: -1. User joins community and becomes community member (see [org channels spec](../56/communities.md)) +1. User joins community and becomes community member (see [org channels spec](../56/communities)) 2. By joining a community, member nodes automatically subscribe to special channel for message archive metadata exchange provided by the community 3. Member node requests live message history (last 30 days) of all the community channels including the special channel from store nodes -4. Member node receives Waku message ([14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md)) that contains the metadata magnet link from the special channel +4. Member node receives Waku message ([14/WAKU2-MESSAGE](../../waku/standards/core/14/message)) that contains the metadata magnet link from the special channel 5. Member node extracts the magnet link from the Waku message and passes it to torrent client 6. Member node downloads [message archive index](#message-history-archive-index) file and determines which message archives are not downloaded yet (all or some) 7. Member node fetches missing message archive data via torrent @@ -107,7 +106,7 @@ Community member nodes go through the following (high level) process to fetch an ## Storing live messages -For archival data serving, the control node MUST store live messages as [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md). +For archival data serving, the control node MUST store live messages as [14/WAKU2-MESSAGE](../../waku/standards/core/14/message). This is in addition to their database of application messages. This is required to provide confidentiality, authenticity, and integrity of message data distributed via the BitTorrent layer, and later validated by community members when they unpack message history archives. @@ -125,7 +124,7 @@ The `timestamp` is determined by the context in which the control node attempts 1. The control node attempts to create an archive periodically for the past seven days (including the current day). In this case, the `timestamp` has to lie within those 7 days. 2. The control node has been offline (control node's main process has stopped and needs restart) and attempts to create archives for all the live messages it has missed since it went offline. In this case, the `timestamp` has to lie within the day the latest message was received and the current day. -Exported messages MUST be restored as [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md) for bundling. Waku messages that are older than 30 days and have been exported for bundling can be removed from the control node's database (control nodes still maintain a database of application messages). +Exported messages MUST be restored as [14/WAKU2-MESSAGE](../../waku/standards/core/14/message) for bundling. Waku messages that are older than 30 days and have been exported for bundling can be removed from the control node's database (control nodes still maintain a database of application messages). ## Message history archives @@ -135,7 +134,7 @@ Message history archives are implemented using the following protocol buffer. ### WakuMessageHistoryArchive The `from` field SHOULD contain a timestamp of the time range's lower bound. -The type parallels the `timestamp` of [WakuMessage](../../waku/standards/core/14/message.md/#payloads). +The type parallels the `timestamp` of [WakuMessage](../../waku/standards/core/14/message#payloads). The `to` field SHOULD contain a timestamp of the time range's the higher bound. @@ -295,7 +294,7 @@ The topic of that special channel follows the following format: /{application-name}/{version-of-the-application}/{content-topic-name}/{encoding} ``` -All messages sent with this topic MUST be instances of `ApplicationMetadataMessage` ([62/STATUS-PAYLOAD](../62/payload.md)) with a `payload` of `CommunityMessageArchiveIndex`. +All messages sent with this topic MUST be instances of `ApplicationMetadataMessage` ([62/STATUS-PAYLOAD](../62/payload)) with a `payload` of `CommunityMessageArchiveIndex`. Only the control node MAY post to the special channel. Other messages on this specified channel MUST be ignored by clients. Community members MUST NOT have permission to send messages to the special channel. @@ -327,7 +326,7 @@ There are two scenarios in which member nodes can receive such a magnet link mes 2. The member node requests messages for a time range of up to 30 days from store nodes (this is the case when a new community member joins a community) ### Downloading message archives -When member nodes receive a message with a `CommunityMessageHistoryArchive` ([62/STATUS-PAYLOADS](../62/payloads.md)) from the aforementioned channnel, they MUST extract the `magnet_uri` and pass it to their underlying BitTorrent client so they can fetch the latest message history archive index, which is the `index` file of the torrent (see [Creating message archive torrents](#creating-message-archive-torrents)). +When member nodes receive a message with a `CommunityMessageHistoryArchive` ([62/STATUS-PAYLOADS](../62/payloads)) from the aforementioned channnel, they MUST extract the `magnet_uri` and pass it to their underlying BitTorrent client so they can fetch the latest message history archive index, which is the `index` file of the torrent (see [Creating message archive torrents](#creating-message-archive-torrents)). Due to the nature of distributed systems, there's no guarantee that a received message is the "last" message. This is especially true when member nodes request historical messages from store nodes. @@ -384,15 +383,15 @@ Even if just a single message is missing in one of the histories, the hashes pre Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). ## References -* [13/WAKU2-STORE](../../waku/standards/core/13/store.md) +* [13/WAKU2-STORE](../../waku/standards/core/13/store) * [BitTorrent](https://bittorrent.org) -* [10/WAKU2](../../waku/standards/core/10/waku2.md) -* [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) +* [10/WAKU2](../../waku/standards/core/10/waku2) +* [11/WAKU2-RELAY](../../waku/standards/core/11/relay) * [Magnet URI scheme](https://en.wikipedia.org/wiki/Magnet_URI_scheme) * [forum discussion](https://forum.vac.dev/t/status-communities-protocol-and-product-point-of-view/114) * [org channels](https://github.com/status-im/specs/pull/151) * [UI feature spec](https://github.com/status-im/feature-specs/pull/36) * [Extensions for Peers to Send Metadata Files](https://www.bittorrent.org/beps/bep_0009.html) -* [org channels spec](../56/communities.md) -* [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md) -* [62/STATUS-PAYLOADS](../62/payloads.md) +* [org channels spec](../56/communities) +* [14/WAKU2-MESSAGE](../../waku/standards/core/14/message) +* [62/STATUS-PAYLOADS](../62/payloads) diff --git a/status/payloads.md b/status/62/payloads.md similarity index 99% rename from status/payloads.md rename to status/62/payloads.md index 5e9cd707d..a17378f9f 100644 --- a/status/payloads.md +++ b/status/62/payloads.md @@ -8,7 +8,6 @@ contributors: - Andrea Maria Piana \ - Oskar Thoren \ - Samuel Hawksby-Robinson \ -sidebar_position: 62 --- - Status: draft - Editor: r4bbit \ @@ -284,7 +283,7 @@ message DiscordMessageAttachment { #### Message types A node requires message types to decide how to encrypt a particular message and what metadata needs to be attached when passing a message to the transport layer. -For more on this, see [10/WAKU2](../../waku/standards/core/10/waku2.md). +For more on this, see [10/WAKU2](../../waku/standards/core/10/waku2). @@ -442,7 +441,7 @@ This specification RECOMMENDS that the UI/UX implementation of retracting an `Em ### MembershipUpdateMessage and MembershipUpdateEvent `MembershipUpdateEvent` is a message used to propagate information about group membership changes in a group chat. -The details are in the [Group chats specs](../56/communities.md). +The details are in the [Group chats specs](../56/communities). ```protobuf @@ -828,7 +827,7 @@ message DeleteMessage { ### CommunityMessageArchiveLink -A `CommunityMessageArchiveLink` contains a magnet uri for a community's message archive, created using [61/STATUS-Community-History-Archives](../61/community-history-service.md). +A `CommunityMessageArchiveLink` contains a magnet uri for a community's message archive, created using [61/STATUS-Community-History-Archives](../61/community-history-service). ```protobuf message CommunityMessageArchiveMagnetlink { diff --git a/status/keycard-usage.md b/status/63/keycard-usage.md similarity index 99% rename from status/keycard-usage.md rename to status/63/keycard-usage.md index 3cdac9cd6..332f79dc8 100644 --- a/status/keycard-usage.md +++ b/status/63/keycard-usage.md @@ -7,7 +7,6 @@ description: Describes how an application can use the Status Keycard to create, editor: Aaryamann Challani \ contributors: - Jimmy Debe \ -sidebar_position: 63 --- - Status: draft - Category: Standards Track diff --git a/status/account-address.md b/status/65/account-address.md similarity index 90% rename from status/account-address.md rename to status/65/account-address.md index 9d78bfc07..2d488be11 100644 --- a/status/account-address.md +++ b/status/65/account-address.md @@ -9,7 +9,6 @@ contributors: - Corey Petty \ - Oskar Thorén \ - Samuel Hawksby-Robinson \ -sidebar_position: 65 --- - Status: draft - Category: Standards Track @@ -37,7 +36,7 @@ The Status node verifies or derives everything else associated with the contact - An ECDSA (secp256k1 curve) public/private keypair MUST be generated via a [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) derived path from a [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) mnemonic seed phrase. - The default paths are defined as such: - Waku Chat Key (`IK`): `m/43'/60'/1581'/0'/0` (post Multiaccount integration) - - following [EIP1581](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1581.md) + - following [EIP1581](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1581) - Status Wallet paths: `m/44'/60'/0'/0/i` starting at `i=0` - following [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) - NOTE: this (`i=0`) is also the current (and only) path for Waku key before Multiaccount integration @@ -46,7 +45,7 @@ The Status node verifies or derives everything else associated with the contact - A user is responsible for broadcasting certain information publicly so that others may contact them. ### X3DH Prekey bundles -- Refer to [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) for details on the X3DH prekey bundle broadcasting, as well as regeneration. +- Refer to [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) for details on the X3DH prekey bundle broadcasting, as well as regeneration. ## Optional Account additions @@ -99,7 +98,7 @@ The above payload is broadcasted when 2 devices that belong to a user need to be ## Security Considerations -- This specification inherits security considerations of [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) and [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md). +- This specification inherits security considerations of [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) and [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions). ## Copyright @@ -109,15 +108,15 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ### normative -- [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) -- [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md) -- [55/STATUS-1TO1-CHAT](../55/1to1-chat.md) +- [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) +- [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions) +- [55/STATUS-1TO1-CHAT](../55/1to1-chat) ## informative - [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) - [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) -- [EIP1581](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1581.md) +- [EIP1581](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1581) - [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) - [Ethereum Name System](https://ens.domains/) -- [Status Multiaccount](../63/account-address.md) +- [Status Multiaccount](../63/account-address) diff --git a/status/push-notification-server.md b/status/71/push-notification-server.md similarity index 92% rename from status/push-notification-server.md rename to status/71/push-notification-server.md index 738c8aa37..c6ae34a47 100644 --- a/status/push-notification-server.md +++ b/status/71/push-notification-server.md @@ -7,7 +7,6 @@ description: A set of methods to allow Status clients to use push notification s editor: Jimmy Debe \ contributors: - Andrea Maria Piana \ -sidebar_position: 71 --- - Status: draft - Category: Standards Track @@ -45,7 +44,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL | client | A node that implements the Status specifications. | | user | The owner of a device that runs a client. | | server | A service that performs push notifications. | -| Waku-Store | A Waku node that decides to provide functionality to store messages permanently and deliver the messages to requesting clients. As described in [13/WAKU-STORE](../../waku/standards/core/13/store.md) specification.| +| Waku-Store | A Waku node that decides to provide functionality to store messages permanently and deliver the messages to requesting clients. As described in [13/WAKU-STORE](../../waku/standards/core/13/store) specification.| ### Server Components @@ -67,11 +66,11 @@ The party releasing the app MUST run its own [gorush](https://github.com/applebo ### Push Notification Server Flow #### Registration Process: -![registration](./71/images/registration.png) +![registration](./images/registration.png) #### Sending and Receiving Notification Process: -![notification](./71/images/notification.png) +![notification](./images/notification.png) ### Registering Client @@ -82,9 +81,9 @@ Registering a client with a push notification service. - A client SHOULD make sure that all the notification services they registered with have the same information about their tokens. - A `PNR message` (Push Notification Registration) MUST be sent to the -[partitioned topic](../../waku/standards/application/54/x3dh-sessions.md) for the public key of the node, encrypted with this key. +[partitioned topic](../../waku/standards/application/54/x3dh-sessions) for the public key of the node, encrypted with this key. -- The message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads.md) with type set to `PUSH_NOTIFICATION_REGISTRATION`. +- The message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads) with type set to `PUSH_NOTIFICATION_REGISTRATION`. - The marshaled protobuf payload MUST also be encrypted with AES-GCM using the Diffie–Hellman key generated from the client and server identity. This is done in order to ensure that the extracted key from the signature will be considered invalid if it can’t decrypt the payload. @@ -132,7 +131,7 @@ A push notification server will handle the message according to the following ru - it MUST verify that `apn_topic` is set if token_type is APN_TOKEN. -- The message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads.md) with type set to `PUSH_NOTIFICATION_REGISTRATION_RESPONSE`. +- The message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads) with type set to `PUSH_NOTIFICATION_REGISTRATION_RESPONSE`. The payload of the response is: @@ -153,7 +152,7 @@ message PushNotificationRegistrationResponse { ``` -A client SHOULD listen for a response sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions.md) that the key used to register. +A client SHOULD listen for a response sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions) that the key used to register. If success is true the client has registered successfully. If `success` is `false`: @@ -175,7 +174,7 @@ If `success` is `false`: - `request_id` SHOULD be set to the [`SHAKE-256`](https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf) of the encrypted payload. -- The response MUST be sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions.md) of the sender and +- The response MUST be sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions) of the sender and MUST not be encrypted using the secure transport to facilitate the usage of ephemeral keys. - If no response is returned, the request SHOULD be considered failed and @@ -235,17 +234,17 @@ message ContactCodeAdvertisement { ``` #### Handle Advertisement Message: -- The message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads.md) with type set to `PUSH_NOTIFICATION_QUERY_INFO`. +- The message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads) with type set to `PUSH_NOTIFICATION_QUERY_INFO`. - If no filtering is done based on public keys, the access token SHOULD be included in the advertisement. Otherwise it SHOULD be left empty. -- This SHOULD be advertised on the [contact code topic](../../waku/standards/application/53/x3dh.md) and +- This SHOULD be advertised on the [contact code topic](../../waku/standards/application/53/x3dh) and SHOULD be coupled with normal contact-code advertisement. - When a user register or re-register with a push notification service, their contact-code SHOULD be re-advertised. - Multiple servers MAY be advertised for the same installation_id for redundancy reasons. #### Discovering a Server: To discover a push notification service for a given user, their  -[contact code topic](../../waku/standards/application/53/x3dh.md) SHOULD be listened to. +[contact code topic](../../waku/standards/application/53/x3dh) SHOULD be listened to. A Waku-Store node can be queried for the specific topic to retrieve the most up-to-date contact code. #### Querying a Server: @@ -261,10 +260,10 @@ message PushNotificationQuery { ``` #### Handle Query Message: -- The message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads.md) with type set to `PUSH_NOTIFICATION_QUERY`. +- The message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads) with type set to `PUSH_NOTIFICATION_QUERY`. - it MUST be sent to the server on the topic derived from the hashed public key of the key we are querying, [as described above](#query-topic). -- An ephemeral key SHOULD be used and SHOULD NOT be encrypted using the [secure transport](../../waku/standards/application/53/x3dh.md). +- An ephemeral key SHOULD be used and SHOULD NOT be encrypted using the [secure transport](../../waku/standards/application/53/x3dh). If the server has information about the client a response MUST be sent: @@ -289,7 +288,7 @@ message PushNotificationQueryResponse { #### Handle Query Response: - A `PushNotificationQueryResponse` message MUST be wrapped in a -[`ApplicationMetadataMessage`](../62/payloads.md) with type set to `PUSH_NOTIFICATION_QUERY_RESPONSE`. +[`ApplicationMetadataMessage`](../62/payloads) with type set to `PUSH_NOTIFICATION_QUERY_RESPONSE`. Otherwise a response MUST NOT be sent. - If `allowed_key_list` is not set `access_token` MUST be set and `allowed_key_list` MUST NOT be set. @@ -302,8 +301,8 @@ Otherwise a response MUST NOT be sent. If AES decryption succeeds it will return a valid `uuid` which is what is used for access_token. The token SHOULD be used to send push notifications. -- The response MUST be sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions.md) of the sender and -MUST NOT be encrypted using the [secure transport](../../waku/standards/application/53/x3dh.md) to facilitate the usage of ephemeral keys. +- The response MUST be sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions) of the sender and +MUST NOT be encrypted using the [secure transport](../../waku/standards/application/53/x3dh) to facilitate the usage of ephemeral keys. - On receiving a response a client MUST verify `grant` to ensure that the server has been authorized to send push notification to a given client. @@ -346,7 +345,7 @@ message PushNotificationRequest { ``` #### Handle Notification Request: - A `PushNotificationRequest` message MUST be wrapped in a -[`ApplicationMetadataMessage`](../62/payloads.md) with type set to `PUSH_NOTIFICATION_REQUEST`. +[`ApplicationMetadataMessage`](../62/payloads) with type set to `PUSH_NOTIFICATION_REQUEST`. - Where `message` is the encrypted payload of the message and `chat_id` is the `SHAKE-256` of the `chat_id`. `message_id` is the id of the message `author` is the `SHAKE-256` of the public key of the sender. @@ -411,10 +410,10 @@ message PushNotificationResponse { Where `message_id` is the `message_id` sent by the client. #### Handle Notification Response: -- A `PushNotificationResponse` message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads.md) with type set to `PUSH_NOTIFICATION_RESPONSE`. +- A `PushNotificationResponse` message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads) with type set to `PUSH_NOTIFICATION_RESPONSE`. -- The response MUST be sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions.md) of the sender and -MUST not be encrypted using the [secure transport](../../waku/standards/application/53/x3dh.md) to facilitate the usage of ephemeral keys. +- The response MUST be sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions) of the sender and +MUST not be encrypted using the [secure transport](../../waku/standards/application/53/x3dh) to facilitate the usage of ephemeral keys. - If the request is accepted `success` MUST be set to `true`. Otherwise `success` MUST be set to `false`. @@ -505,7 +504,7 @@ Data disclosed #### PushNotificationRequest: `requests`: a list of PushNotification\
-`message_id`: the [Status message id](../62/payloads.md) +`message_id`: the [Status message id](../62/payloads) Data disclosed - The status `message_id` for which the notification is for @@ -526,7 +525,7 @@ A client in anonymous mode can register with the server using a key that is diff This will hide their real chat key. This public key is effectively a secret and SHOULD only be disclosed to clients approved to notify a user. -- A client MAY advertise the access token on the [contact-code topic](../../waku/standards/application/53/x3dh.md) of the key generated. +- A client MAY advertise the access token on the [contact-code topic](../../waku/standards/application/53/x3dh) of the key generated. - A client MAY share their public key contact updates in the [protobuf record](https://developers.google.com/protocol-buffers/). @@ -534,7 +533,7 @@ SHOULD only be disclosed to clients approved to notify a user. The method described above effectively does not share the identity of the sender nor the receiver to the server, but MAY result in missing push notifications as the propagation of the secret is left to the client. -This can be mitigated by [device syncing](../62/payloads.md), but not completely addressed. +This can be mitigated by [device syncing](../62/payloads), but not completely addressed. ## Security/Privacy Considerations If anonymous mode is not used, when registering with a push notification service a client will disclose: @@ -559,13 +558,13 @@ When sending a push notification a client will disclose: Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). ## References -1. [PUSH-NOTIFICATION-SERVER, Initial Specification](https://github.com/status-im/specs/blob/master/docs/raw/push-notification-server.md) +1. [PUSH-NOTIFICATION-SERVER, Initial Specification](https://github.com/status-im/specs/blob/master/docs/raw/push-notification-server) 2. [Push Notification, Apple Developer](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1) 3. [Firebase](https://firebase.google.com) -4. [13/WAKU2-STORE](../../waku/standards/core/13/store.md) +4. [13/WAKU2-STORE](../../waku/standards/core/13/store) 5. [gorush](https://github.com/appleboy/gorush) -6. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md) -7. [62/PAYLOAD](../62/payloads.md) +6. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions) +7. [62/PAYLOAD](../62/payloads) 8. [SHAKE-256](https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf) 9. [Protocol Buffers](https://developers.google.com/protocol-buffers) -10. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) +10. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh) diff --git a/status/simple-scaling.md b/status/raw/simple-scaling.md similarity index 89% rename from status/simple-scaling.md rename to status/raw/simple-scaling.md index 152283162..545ea5628 100644 --- a/status/simple-scaling.md +++ b/status/raw/simple-scaling.md @@ -1,4 +1,5 @@ --- + title: 57/STATUS-Simple-Scaling name: Status Simple Scaling status: raw @@ -7,7 +8,6 @@ description: Describes how to scale Status Communities and Status 1-to-1 chats u editor: Daniel Kaiser \ contributors: - Alvaro Revuelta \ -sidebar_position: 57 --- - Status: raw - Category: Informational @@ -17,7 +17,7 @@ sidebar_position: 57 ## Abstract -This document describes how to scale [56/STATUS-COMMUNITIES](../56/communities.md) as well as [55/STATUS-1TO1-CHAT](../55/1to1-chat.md) +This document describes how to scale [56/STATUS-COMMUNITIES](../56/communities) as well as [55/STATUS-1TO1-CHAT](../55/1to1-chat) using Waku v2 protocol and components. It also adds a few new aspects, where more sophisticated components are not yet researched and evaluated. @@ -29,8 +29,8 @@ We believe in incremental improvement, i.e. having a working decentralized scali ## Background and Motivation -[56/STATUS-COMMUNITIES](../56/communities.md) as well as [55/STATUS-1TO1-CHAT](../55/1to1-chat.md) use Waku v2 protocols. -Both use Waku content topics (see [23/WAKU2-TOPICS](../../waku/informational/23/topics.md)) for content based filtering. +[56/STATUS-COMMUNITIES](../56/communities) as well as [55/STATUS-1TO1-CHAT](../55/1to1-chat) use Waku v2 protocols. +Both use Waku content topics (see [23/WAKU2-TOPICS](../../waku/informational/23/topics)) for content based filtering. Waku v2 currently has scaling limitations in two dimensions: @@ -50,14 +50,14 @@ Splitting content topics in a more sophisticated and efficient way will be part ## Relay Shards -Sharding the [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) network is an integral part of scaling the Status app. +Sharding the [11/WAKU2-RELAY](../../waku/standards/core/11/relay) network is an integral part of scaling the Status app. -[51/WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md) specifies shards clusters, which are sets of `1024` shards (separate pubsub mesh networks). +[51/WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding) specifies shards clusters, which are sets of `1024` shards (separate pubsub mesh networks). Content topics specified by application protocols can be distributed over these shards. The Status app protocols are assigned to shard cluster `16`, -as defined in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md). +as defined in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc). -[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md) specifies three sharding methods. +[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding) specifies three sharding methods. This document uses *static sharding*, which leaves the distribution of content topics to application protocols, but takes care of shard discovery. @@ -73,7 +73,7 @@ The 1024 shards within the main Status shard cluster are allocated as follows. | 768 - 895 | 1:1 chat | | 896 - 1023 | media and control msgs | -Shard indices are mapped to pubsub topic names as follows (specified in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)). +Shard indices are mapped to pubsub topic names as follows (specified in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding)). `/waku/2/rs/\/\` @@ -136,19 +136,19 @@ message CommunityDescription { } ``` -\> *Note*: Currently, Status app has allocated shared cluster `16` in [52/WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md). +\> *Note*: Currently, Status app has allocated shared cluster `16` in [52/WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc). Status app could allocate more shard clusters, for instance to establish a test net. We could add the shard cluster index to the community description as well. The recommendation for now is to keep it as a configuration option of the Status app. -\> *Note*: Once this RFC moves forward, the new community description protobuf fields should be mentioned in [56/STATUS-COMMUNITIES](../56/communities.md). +\> *Note*: Once this RFC moves forward, the new community description protobuf fields should be mentioned in [56/STATUS-COMMUNITIES](../56/communities). Status communities can be mapped to shards in two ways: static, and owner-based. #### Static Mapping With static mapping, communities are assigned a specific shard index within the Status shard cluster. -This mapping is similar in nature to the shard cluster allocation in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md). +This mapping is similar in nature to the shard cluster allocation in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc). Shard indices allocated in that way are in the range `16 - 127`. The Status CC community uses index `16` (not to confuse with shard cluster index `16`, which is the Status shard cluster). @@ -160,7 +160,7 @@ Community owners can choose to map their communities to any shard within the ind ### 1:1 Chat -[55/STATUS-1TO1-CHAT](../55/1to1-chat.md) uses partitioned topics to map 1:1 chats to a set of 5000 content topics. +[55/STATUS-1TO1-CHAT](../55/1to1-chat) uses partitioned topics to map 1:1 chats to a set of 5000 content topics. This document extends this mapping to 8192 content topics that are, in turn, mapped to 128 shards in the index range of `768 - 895`. ``` @@ -177,7 +177,7 @@ shardIndex = 768 + mod(publicKey, shardNum) ## Infrastructure Nodes -As described in [30/ADAPTIVE-NODES](../../waku/informational/30/adaptive-nodes.md), +As described in [30/ADAPTIVE-NODES](../../waku/informational/30/adaptive-nodes), Waku supports a continuum of node types with respect to available resources. Infrastructure nodes are powerful nodes that have a high bandwidth connection and a high up-time. @@ -215,7 +215,7 @@ We could improve on this in the future, and research the applicability of PIR (p ## Infrastructure Shards -Waku messages are typically relayed in larger mesh networks comprised of nodes with varying resource profiles (see [30/ADAPTIVE-NODES](../../waku/informational/30/adaptive-nodes.md). +Waku messages are typically relayed in larger mesh networks comprised of nodes with varying resource profiles (see [30/ADAPTIVE-NODES](../../waku/informational/30/adaptive-nodes). To maximise scaling, relaying of specific message types can be dedicated to shards where only infrastructure nodes with very strong resource profiles relay messages. This comes as a trade-off to decentralization. @@ -262,15 +262,15 @@ and devices that (temporarily) have a low bandwidth connection or a connection w Light protocols comprise -* [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) for sending messages -* [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md) for requesting messages with specific attributes -* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md) for discovering peers +* [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush) for sending messages +* [12/WAKU2-FILTER](../../waku/standards/core/12/filter) for requesting messages with specific attributes +* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange) for discovering peers ## Waku Archive -Archive nodes are Waku nodes that offer the Waku archive service via the Waku store protocol ([13/WAKU2-STORE](../../waku/standards/core/13/store.md)). +Archive nodes are Waku nodes that offer the Waku archive service via the Waku store protocol ([13/WAKU2-STORE](../../waku/standards/core/13/store)). They are part of a set of shards and store all messages disseminated in these shards. -Nodes can request history messages via the [13/WAKU2-STORE](../../waku/standards/core/13/store.md). +Nodes can request history messages via the [13/WAKU2-STORE](../../waku/standards/core/13/store). The store service is not limited to a Status fleet. Anybody can run a Waku Archive node in the Status shards. @@ -284,17 +284,17 @@ In fact, the archive service can be offered by infrastructure nodes. ## Discovery -Shard discovery is covered by [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md). +Shard discovery is covered by [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding). This allows the Status app to abstract from the discovery process and simply address shards by their index. ### Libp2p Rendezvous and Circuit-Relay To make nodes behind restrictive NATs discoverable, -this document suggests using [libp2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md). -Nodes can check whether they are behind a restrictive NAT using the [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md). +this document suggests using [libp2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README). +Nodes can check whether they are behind a restrictive NAT using the [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README). -\> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md), or [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md): -Nodes behind restrictive NATs SHOULD not announce their publicly unreachable address via [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) discovery. +\> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding), or [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5): +Nodes behind restrictive NATs SHOULD not announce their publicly unreachable address via [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5) discovery. It is RECOMMENDED that nodes that are part of the relay network also act as rendezvous points. This includes accepting register queries from peers, as well as answering rendezvous discover queries. @@ -302,17 +302,17 @@ Nodes MAY opt-out of the rendezvous functionality. To allow nodes to initiate connections to peers behind restrictive NATs (after discovery via rendezvous), it is RECOMMENDED that nodes that are part of the Waku relay network also offer -[libp2p circuit relay](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md) functionality. +[libp2p circuit relay](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2) functionality. To minimize the load on circuit-relay nodes, nodes SHOULD -1) make use of the [limiting](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md#reservation) +1) make use of the [limiting](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2##reservation) functionality offered by the libp2p circuit relay protocols, and -2) use [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md) to upgrade to a direct connection. +2) use [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR) to upgrade to a direct connection. Nodes that do not announce themselves at all and only plan to use light protocols, -MAY use rendezvous discovery instead of or along-side [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md). -For these nodes, rendezvous and [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md) offer the same functionality, +MAY use rendezvous discovery instead of or along-side [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange). +For these nodes, rendezvous and [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange) offer the same functionality, but return node sets sampled in different ways. Using both can help increasing connectivity. @@ -322,7 +322,7 @@ Such nodes SHOULD, however, not register at circuit relays. ### Announcing Shard Participation -Registering a namespace via [lib-p2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#interaction) +Registering a namespace via [lib-p2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README##interaction) is done via a register query: ``` @@ -336,10 +336,10 @@ The app name, `my-app` contains the encoding of a single shard in string form: ``` The string conversion SHOULD remove leading zeros. -\> *Note:* Since the [ns](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#protobuf) field is of type string, +\> *Note:* Since the [ns](https://github.com/libp2p/specs/blob/master/rendezvous/README##protobuf) field is of type string, a more efficient byte encoding is not utilized. -Registering shard 2 in the Status shard cluster (with shard cluster index 16, see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md), +Registering shard 2 in the Status shard cluster (with shard cluster index 16, see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc), the register query would look like ``` @@ -412,7 +412,7 @@ Requirements on the gossipsub validator: Other requirements: * The node shall keep metrics on the messages validation output, `Accept` or `Reject`. -* (Optional). To further strengthen DoS protection, gossipsub [scoring](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) can be used to trigger disconnections from peers sending multiple invalid messages. See `P4` penalty. +* (Optional). To further strengthen DoS protection, gossipsub [scoring](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1##extended-validators) can be used to trigger disconnections from peers sending multiple invalid messages. See `P4` penalty. This protects each peer from DoS, since this score is used to trigger disconnections from nodes attempting to DoS them. @@ -470,7 +470,7 @@ It could be rate-limited with RLN. This document makes several trade-offs to privacy and anonymity. Todo: elaborate. -See [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/waku-RFC/informational/adversarial-models.md) for information on Waku Anonymity. +See [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/waku-RFC/informational/adversarial-models) for information on Waku Anonymity. ## Copyright @@ -478,27 +478,27 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -* [56/STATUS-COMMUNITIES](../56/communities.md) -* [55/STATUS-1TO1-CHAT](.../55/1to1-chat.md) +* [56/STATUS-COMMUNITIES](../56/communities) +* [55/STATUS-1TO1-CHAT](.../55/1to1-chat) * [23/WAKU2-TOPICS](../../waku/informational/23/) -* [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) -* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md) -* [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md) -* [30/ADAPTIVE-NODES](../../waku/informational/30/adaptive-nodes.md) -* [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) -* [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md) -* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md) -* [13/WAKU2-STORE](../../waku/standards/core/13/store.md) -* [libp2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md) -* [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md) -* [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) -* [libp2p circuit relay](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md) -* [limiting](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md#reservation) -* [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md) -* [scoring](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) +* [11/WAKU2-RELAY](../../waku/standards/core/11/relay) +* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding) +* [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc) +* [30/ADAPTIVE-NODES](../../waku/informational/30/adaptive-nodes) +* [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush) +* [12/WAKU2-FILTER](../../waku/standards/core/12/filter) +* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange) +* [13/WAKU2-STORE](../../waku/standards/core/13/store) +* [libp2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README) +* [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README) +* [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5) +* [libp2p circuit relay](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2) +* [limiting](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2##reservation) +* [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR) +* [scoring](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1##extended-validators) * [Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/) -* [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/waku-RFC/informational/adversarial-models.md) +* [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/waku-RFC/informational/adversarial-models) ## Informative * [Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/) -* [WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md) +* [WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr) diff --git a/status/status-waku-usage.md b/status/raw/status-waku-usage.md similarity index 99% rename from status/status-waku-usage.md rename to status/raw/status-waku-usage.md index d29e377a7..0ff2cce66 100644 --- a/status/status-waku-usage.md +++ b/status/raw/status-waku-usage.md @@ -8,7 +8,6 @@ editor: Aaryamann Challani \ contributors: - Jimmy Debe \ -sidebar_position: 1 --- - Status: raw - Category: Best Current Practice diff --git a/vac/coss.md b/vac/1/coss.md similarity index 97% rename from vac/coss.md rename to vac/1/coss.md index 4d605e6ee..616c611c8 100644 --- a/vac/coss.md +++ b/vac/1/coss.md @@ -11,7 +11,6 @@ contributors: - Chris Puttick \ - Yurii Rashkovskii \ - Daniel Kaiser \ -sidebar_position: 1 --- - Status: draft - Category: Best Current Practice @@ -27,7 +26,7 @@ sidebar_position: 1 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](https://github.com/unprotocols/rfc/blob/master/2/README.md), used by the [ZeromMQ](https://rfc.zeromq.org/) project. +This specification is based on [Unprotocols 2/COSS](https://github.com/unprotocols/rfc/blob/master/2/README), used by the [ZeromMQ](https://rfc.zeromq.org/) project. It is equivalent except for some areas: - recommending the use of a permissive licenses, such as CC0 (with the exception of this document); @@ -55,7 +54,7 @@ if not, see http://www.gnu.org/licenses. ## Change Process -This document is governed by the [1/COSS](./coss.md) (COSS). +This document is governed by the [1/COSS](./coss) (COSS). ## Language @@ -114,7 +113,7 @@ Every specification has an independent lifecycle that documents clearly its curr A specification has six possible states that reflect its maturity and contractual weight: -![Lifecycle diagram](./1/images/lifecycle.png) +![Lifecycle diagram](./images/lifecycle.png) ### Raw Specifications @@ -160,7 +159,7 @@ A specification MUST have a single responsible editor, the only person who SHALL change the status of the specification through the lifecycle stages. A specification MAY also have additional contributors who contribute changes to it. -It is RECOMMENDED to use a process similar to [C4 process](https://github.com/unprotocols/rfc/blob/master/1/README.md) +It is RECOMMENDED to use a process similar to [C4 process](https://github.com/unprotocols/rfc/blob/master/1/README) to maximize the scale and diversity of contributions. Unlike the original C4 process however, it is RECOMMENDED to use CC0 as a more permissive license alternative. @@ -215,7 +214,7 @@ This will enable programmatic access to specification metadata. ### Specification Template -Standards Track specifications SHOULD be based on the [Vac RFC template](./images/template.md). +Standards Track specifications SHOULD be based on the [Vac RFC template](./images/template). ## Conventions diff --git a/vac/mvds.md b/vac/2/mvds.md similarity index 99% rename from vac/mvds.md rename to vac/2/mvds.md index 590889305..ca4fefa0c 100644 --- a/vac/mvds.md +++ b/vac/2/mvds.md @@ -6,7 +6,6 @@ editor: Sanaz Taheri \ contributors: - Dean Eigenmann \ - Oskar Thorén \ -sidebar_position: 2 --- - Status: stable - Editor: Sanaz Taheri \ @@ -155,5 +154,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## Footnotes -[^1]: akwizgran et al. [BSP](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md). Briar. +[^1]: akwizgran et al. [BSP](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP). Briar. [^2]: \ diff --git a/vac/libp2p-dns-discovery.md b/vac/25/libp2p-dns-discovery.md similarity index 95% rename from vac/libp2p-dns-discovery.md rename to vac/25/libp2p-dns-discovery.md index a3fb4a42b..7c56f6a9b 100644 --- a/vac/libp2p-dns-discovery.md +++ b/vac/25/libp2p-dns-discovery.md @@ -4,14 +4,13 @@ name: Libp2p Peer Discovery via DNS status: deleted editor: Hanno Cornelius \ contributors: -sidebar_position: 25 --- - Status: deleted - Editor: Hanno Cornelius \ `25/LIBP2P-DNS-DISCOVERY` specifies a scheme to implement [`libp2p`](https://libp2p.io/) peer discovery via DNS for Waku v2. The generalised purpose is to retrieve an arbitrarily long, authenticated, updateable list of [`libp2p` peers](https://docs.libp2p.io/concepts/peer-id/) to bootstrap connection to a `libp2p` network. -Since [`10/WAKU2`](../../waku/standards/core/10/waku2.md) currently specifies use of [`libp2p` peer identities](https://docs.libp2p.io/concepts/peer-id/), +Since [`10/WAKU2`](../../waku/standards/core/10/waku2) currently specifies use of [`libp2p` peer identities](https://docs.libp2p.io/concepts/peer-id/), 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](https://eips.ethereum.org/EIPS/eip-1459), @@ -128,7 +127,7 @@ Copyright and related rights waived via # References -1. [`10/WAKU2`](../../waku/standards/core/10/waku2.md) +1. [`10/WAKU2`](../../waku/standards/core/10/waku2) 1. [EIP-1459: Client Protocol](https://eips.ethereum.org/EIPS/eip-1459#client-protocol) 1. [EIP-1459: Node Discovery via DNS ](https://eips.ethereum.org/EIPS/eip-1459) 1. [`libp2p`](https://libp2p.io/) diff --git a/vac/remote-log.md b/vac/3/remote-log.md similarity index 96% rename from vac/remote-log.md rename to vac/3/remote-log.md index 78fb1ea94..7ba12c2ba 100644 --- a/vac/remote-log.md +++ b/vac/3/remote-log.md @@ -5,7 +5,6 @@ status: draft editor: Oskar Thorén \ contributors: - Dean Eigenmann \ -sidebar_position: 3 --- - Status: draft - Editor: Oskar Thorén \ @@ -232,7 +231,7 @@ in time. ### Interaction with MVDS -[vac.mvds.Message](../2/mvds.md/#payloads) payloads are the only payloads that MUST be uploaded. Other messages types MAY be uploaded, depending on the implementation. +[vac.mvds.Message](../2/mvds#payloads) payloads are the only payloads that MUST be uploaded. Other messages types MAY be uploaded, depending on the implementation. ## Acknowledgments diff --git a/vac/rln-v1.md b/vac/32/rln-v1.md similarity index 99% rename from vac/rln-v1.md rename to vac/32/rln-v1.md index b3302311a..1744cf61e 100644 --- a/vac/rln-v1.md +++ b/vac/32/rln-v1.md @@ -9,7 +9,6 @@ contributors: - Oskar Thorén \ - Onur Kilic \ - Blagoj Dimovski \ -sidebar_position: 32 --- - Status: raw - Editor: Rasul Ibragimov \ @@ -28,7 +27,7 @@ RLN guarantees a messaging rate is enforced cryptographically while preserving t A wide range of applications can benefit from RLN and provide desirable security features. For example, an e-voting system can integrate RLN to contain the voting rate while protecting the voters-vote unlinkability. Another use case is to protect an anonymous messaging system against DDoS and spam attacks by containing messaging rate of users. -This latter use case is explained in [17/WAKU2-RLN-RELAY RFC](../../waku/standards/core/17/rln-relay.md). +This latter use case is explained in [17/WAKU2-RLN-RELAY RFC](../../waku/standards/core/17/rln-relay). ## Flow diff --git a/vac/mvds-meta.md b/vac/4/mvds-meta.md similarity index 86% rename from vac/mvds-meta.md rename to vac/4/mvds-meta.md index 0f95c63b0..6b8c9453d 100644 --- a/vac/mvds-meta.md +++ b/vac/4/mvds-meta.md @@ -7,7 +7,6 @@ contributors: - Dean Eigenmann \ - Andrea Maria Piana \ - Oskar Thorén \ -sidebar_position: 4 --- - Status: draft - Editor: Sanaz Taheri \ @@ -16,7 +15,7 @@ sidebar_position: 4 - Andrea Maria Piana \ - Oskar Thorén \ -In this specification, we describe a method to construct message history that will aid the consistency guarantees of [2/MVDS](../2/mvds.md). Additionally, we explain how data sync can be used for more lightweight messages that do not require full synchronization. +In this specification, we describe a method to construct message history that will aid the consistency guarantees of [2/MVDS](../2/mvds). Additionally, we explain how data sync can be used for more lightweight messages that do not require full synchronization. ## Motivation @@ -35,7 +34,7 @@ message Metadata { } ``` -Nodes MAY transmit a `Metadata` message by extending the MVDS [message](../2/mvds.md/#payloads) with a `metadata` field. +Nodes MAY transmit a `Metadata` message by extending the MVDS [message](../2/mvds#payloads) with a `metadata` field. ```diff message Message { @@ -50,14 +49,14 @@ message Message { | Name | Description | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -| `parents` | list of parent [`message identifier`s](../2/mvds.md/#payloads) for the specific message. | +| `parents` | list of parent [`message identifier`s](../2/mvds#payloads) for the specific message. | | `ephemeral` | indicates whether a message is ephemeral or not. | ## Usage ### `parents` -This field contains a list of parent [`message identifier`s](../2/mvds.md/#payloads) for the specific message. It MUST NOT contain any messages as parent whose `ack` flag was set to `false`. This establishes a directed acyclic graph (DAG)[^2] of persistent messages. +This field contains a list of parent [`message identifier`s](../2/mvds#payloads) for the specific message. It MUST NOT contain any messages as parent whose `ack` flag was set to `false`. This establishes a directed acyclic graph (DAG)[^2] of persistent messages. Nodes MAY buffer messages until dependencies are satisfied for causal consistency[^3], they MAY also pass the messages straight away for eventual consistency[^4]. @@ -80,7 +79,7 @@ Nodes SHOULD send ephemeral messages in batch mode. As their delivery is not nee Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). ## Footnotes -[^1]: [2/MVDS](../2/mvds.md) +[^1]: [2/MVDS](../2/mvds) [^2]: \ [^3]: Jepsen. [Causal Consistency](https://jepsen.io/consistency/models/causal). Jepsen, LLC. [^4]: \ diff --git a/vac/gossipsub-tor-push.md b/vac/46/gossipsub-tor-push.md similarity index 95% rename from vac/gossipsub-tor-push.md rename to vac/46/gossipsub-tor-push.md index 988ffaec3..dfd92d9b8 100644 --- a/vac/gossipsub-tor-push.md +++ b/vac/46/gossipsub-tor-push.md @@ -5,7 +5,6 @@ status: raw category: Standards Track editor: Daniel Kaiser \ contributors: -sidebar_position: 46 --- - Status: raw - Category: Standards Track @@ -13,7 +12,7 @@ sidebar_position: 46 ## Abstract -This document extends the [libp2p gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) +This document extends the [libp2p gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README) 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. @@ -26,7 +25,7 @@ This allows nodes that are oblivious to Tor Push to process messages received vi ## Background -Without extensions, [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) +Without extensions, [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README) does not protect sender identities. A possible design of an anonymity extension to gossipsub is pushing messages through an anonymization network before they enter the gossipsub network. @@ -84,11 +83,11 @@ The Tp-context MUST NOT share any data, e.g. peer lists, with the default contex Tp-peers are peers a Tp-node plans to send Tp-messages to. Tp-peers MUST support `/meshsub/1.1.0`. -For retrieving Tp-peers, Tp-nodes SHOULD use an ambient peer discovery method that retrieves a random peer sample (from the set of all peers), e.g. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md). +For retrieving Tp-peers, Tp-nodes SHOULD use an ambient peer discovery method that retrieves a random peer sample (from the set of all peers), e.g. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5). Tp-nodes MUST establish a connection as described in sub-section [Tor Push Connection Establishment](#connection-establishment) to at least one Tp-peer. To significantly increase resilience, Tp-nodes SHOULD establish Tp-connections to `D` peers, -where `D` is the [desired gossipsub out-degree](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#parameters), +where `D` is the [desired gossipsub out-degree](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0##parameters), with a default value of `8`. Each Tp-message MUST be sent via the Tp-context over at least one Tp-connection. @@ -143,7 +142,7 @@ Still, messages might be delayed during this window which might be critical to c #### Targeting the Gossipsub Network -Without sophisticated rate limiting (for example using [17/WAKU2-RLN-RELAY](../../waku/standards/core/17/rln-relay.md)), +Without sophisticated rate limiting (for example using [17/WAKU2-RLN-RELAY](../../waku/standards/core/17/rln-relay)), attackers can spam the gossipsub network. It is not enough to just block peers that send too many messages, because these messages might actually come from a Tor exit node that many honest Tp-nodes use. @@ -176,12 +175,12 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -* [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) +* [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README) * [libp2p pubsub](https://github.com/libp2p/specs/tree/master/pubsub) * [libp2p pubsub message](https://github.com/libp2p/specs/tree/master/pubsub#the-message) * [libp2p switch](https://docs.libp2p.io/concepts/multiplex/switch) * [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928) * [Tor](https://www.torproject.org/) -* [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) +* [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5) * [Bitcoin over Tor isn't a Good Idea](https://ieeexplore.ieee.org/abstract/document/7163022) -* [17/WAKU2-RLN-RELAY](../../waku/standards/core/17/rln-relay.md) +* [17/WAKU2-RLN-RELAY](../../waku/standards/core/17/rln-relay) diff --git a/vac/rln-interep-spec.md b/vac/48/rln-interep-spec.md similarity index 96% rename from vac/rln-interep-spec.md rename to vac/48/rln-interep-spec.md index 95adfdc14..a9735f7cc 100644 --- a/vac/rln-interep-spec.md +++ b/vac/48/rln-interep-spec.md @@ -5,7 +5,6 @@ status: raw category: editor: Aaryamann Challani \ contributors: -sidebar_position: 48 --- - Status: raw - Category: @@ -13,7 +12,7 @@ sidebar_position: 48 ## Abstract -This spec integrates [Interep](https://interep.link) into the [RLN](../32/rln-v1.md) spec. +This spec integrates [Interep](https://interep.link) into the [RLN](../32/rln-v1) 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. @@ -81,11 +80,11 @@ Following is the modified signature of the register function in the RLN contract ## Verification of messages -Messages are verified the same way as in the [RLN spec](../32/rln-v1.md/#verification). +Messages are verified the same way as in the [RLN spec](../32/rln-v1#verification). ## Slashing -The slashing mechanism is the same as in the [RLN spec](../32/rln-v1.md/#slashing). +The slashing mechanism is the same as in the [RLN spec](../32/rln-v1#slashing). It is important to note that the slashing may not have the intended effect on the user, since the only consequence is that they cannot send messages. This is due to the fact that the user can send a identity commitment in the registration to the RLN contract, which is different than the one used in the Interep group. @@ -96,13 +95,13 @@ A proof of concept is available at [vacp2p/rln-interp-contract](https://github.c ## Security Considerations 1. As mentioned in [Slashing](#slashing), the slashing mechanism may not have the intended effect on the user. -2. This spec inherits the security considerations of the [RLN spec](../32/rln-v1.md/#security-considerations). +2. This spec inherits the security considerations of the [RLN spec](../32/rln-v1#security-considerations). 3. This spec inherits the security considerations of [Interep](https://docs.interep.link/). 4. A user may make multiple registrations using the same Interep proofs but different identity commitments. The way to mitigate this is to check if the nullifier hash has been detected previously in proof verification. ## References -1. [RLN spec](../32/rln-v1.md) +1. [RLN spec](../32/rln-v1) 2. [Interep](https://interep.link) 3. [Semaphore](https://semaphore.appliedzkp.org/) 4. [Decentralized cloudflare using Interep](https://ethresear.ch/t/decentralised-cloudflare-using-rln-and-rich-user-identities/10774) diff --git a/vac/rln-v2.md b/vac/58/rln-v2.md similarity index 85% rename from vac/rln-v2.md rename to vac/58/rln-v2.md index 70283f867..a8e4590bc 100644 --- a/vac/rln-v2.md +++ b/vac/58/rln-v2.md @@ -5,7 +5,6 @@ status: raw editor: Rasul Ibragimov \ contributors: - Lev Soukhanov \<0xdeadfae@gmail.com\> -sidebar_position: 58 --- - Status: raw - Editor: Rasul Ibragimov \ @@ -14,12 +13,12 @@ sidebar_position: 58 ## Abstract -The protocol specified in this document is an improvement of [32/RLN-V1](../32/rln-v1.md), being more general construct, that allows to set various limits for an epoch (it's 1 message per epoch in [32/RLN-V1](../32/rln-v1.md)) while remaining almost as simple as it predecessor. +The protocol specified in this document is an improvement of [32/RLN-V1](../32/rln-v1), being more general construct, that allows to set various limits for an epoch (it's 1 message per epoch in [32/RLN-V1](../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](../32/rln-v1.md) and expand its applications. +The main goal of this RFC is to generalize [32/RLN-V1](../32/rln-v1) and expand its applications. There are two different subprotocols based on this protocol: * RLN-Same - RLN with the same rate-limit for all users; * RLN-Diff - RLN that allows to set different rate-limits for different users. @@ -28,7 +27,7 @@ It is important to note that by using a large epoch limit value, users will be a ## Flow -As in [32/RLN-V1](../32/rln-v1.md), the general flow can be described by three steps: +As in [32/RLN-V1](../32/rln-v1), the general flow can be described by three steps: 1. Registration 2. Signaling @@ -38,13 +37,13 @@ The two sub-protocols have different flows, and hence are defined separately. ### Important note -All terms and parameters used remain the same as in [32/RLN-V1](../32/rln-v1.md), more details [here](../32/rln-v1.md/#technical-overview) +All terms and parameters used remain the same as in [32/RLN-V1](../32/rln-v1), more details [here](../32/rln-v1#technical-overview) ## RLN-Same flow ### Registration -The registration process in the RLN-Same subprotocol does not differ from [32/RLN-V1](../32/rln-v1.md). +The registration process in the RLN-Same subprotocol does not differ from [32/RLN-V1](../32/rln-v1). ### Signalling @@ -92,13 +91,13 @@ internal_nullifier = poseidonHash([a_1]) ### Registration -**id_commitment** in [32/RLN-V1](../32/rln-v1.md) is equal to `poseidonHash(identity_secret)`. +**id_commitment** in [32/RLN-V1](../32/rln-v1) is equal to `poseidonHash(identity_secret)`. The goal of RLN-Diff is to set different rate-limits for different users. It follows that **id_commitment** must somehow depend on the `user_message_limit` parameter, where 0 \<= `user_message_limit` \<= `message_limit`. There are few ways to do that: 1. Sending `identity_secret_hash` = `poseidonHash(identity_secret, userMessageLimit)` and zk proof that `user_message_limit` is valid (is in the right range). This approach requires zkSNARK verification, which is an expensive operation on the blockchain. -2. Sending the same `identity_secret_hash` as in [32/RLN-V1](../32/rln-v1.md) (`poseidonHash(identity_secret)`) and a user_message_limit publicly to a server or smart-contract where `rate_commitment` = `poseidonHash(identity_secret_hash, userMessageLimit)` is calculated. +2. Sending the same `identity_secret_hash` as in [32/RLN-V1](../32/rln-v1) (`poseidonHash(identity_secret)`) and a user_message_limit publicly to a server or smart-contract where `rate_commitment` = `poseidonHash(identity_secret_hash, userMessageLimit)` is calculated. The leaves in the membership Merkle tree would be the rate_commitments of the users. This approach requires additional hashing in the Circuit, but it eliminates the need for zk proof verification for the registration. @@ -130,12 +129,12 @@ The Output is calculated in the same way as the RLN-Same sub-protocol. ### Verification and slashing -Verification and slashing in both subprotocols remain the same as in [32/RLN-V1](../32/rln-v1.md). +Verification and slashing in both subprotocols remain the same as in [32/RLN-V1](../32/rln-v1). The only difference that may arise is the `message_limit` check in RLN-Same, since it is now a public input of the Circuit. ### ZK Circuits specification -The design of the [32/RLN-V1](../32/rln-v1.md) circuits is different from the circuits of this protocol. +The design of the [32/RLN-V1](../32/rln-v1) circuits is different from the circuits of this protocol. RLN-v2 requires additional algebraic constraints. The membership proof and Shamir's Secret Sharing constraints remain unchanged. @@ -193,7 +192,7 @@ In the RLN-Diff scheme, instead of the public parameter `message_limit`, a param ## Appendix A: Security considerations -Although there are changes in the circuits, this spec inherits all the security considerations of [32/RLN-V1](../32/rln-v1.md). +Although there are changes in the circuits, this spec inherits all the security considerations of [32/RLN-V1](../32/rln-v1). ## Copyright @@ -203,4 +202,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public - [1](https://zkresear.ch/t/rate-limit-nullifier-v2-circuits/102) - [2](https://github.com/Rate-Limiting-Nullifier/rln-circuits-v2) -- [3](../32/rln-v1.md/#technical-overview) +- [3](../32/rln-v1#technical-overview) diff --git a/vac/eth-secpm.md b/vac/70/eth-secpm.md similarity index 99% rename from vac/eth-secpm.md rename to vac/70/eth-secpm.md index 1234b5a60..a1dcc48a3 100644 --- a/vac/eth-secpm.md +++ b/vac/70/eth-secpm.md @@ -5,7 +5,6 @@ status: raw category: Standards Track editor: Ramses Fernandez \ contributors: -sidebar_position: 70 --- - Status: raw - Category: Standards Track @@ -19,7 +18,7 @@ Therefore a decentralized approach to secure communication becomes increasingly offering a robust solution to address these challenges. This specification outlines a private messaging service using the Ethereum blockchain as authentication service. -Rooted in the existing [model](../../waku/standards/application/20/toy-eth-pm.md), +Rooted in the existing [model](../../waku/standards/application/20/toy-eth-pm), this proposal addresses the deficiencies related to forward privacy and authentication inherent in the current framework. The specification is divided into 3 sections: diff --git a/vac/raw/README.md b/vac/raw/README.md index 0453294e7..a8cbe7561 100644 --- a/vac/raw/README.md +++ b/vac/raw/README.md @@ -2,4 +2,4 @@ # Vac Raw Specifications All Vac specifications that have not reached **draft** status will live in this repository. -To learn more about **raw** specifications, take a look at [1/COSS](../1/coss.md). +To learn more about **raw** specifications, take a look at [1/COSS](../1/coss). diff --git a/vac/rln-stealth-commitments.md b/vac/raw/rln-stealth-commitments.md similarity index 86% rename from vac/rln-stealth-commitments.md rename to vac/raw/rln-stealth-commitments.md index feaad83c6..ed10eb293 100644 --- a/vac/rln-stealth-commitments.md +++ b/vac/raw/rln-stealth-commitments.md @@ -5,7 +5,6 @@ category: Standards Track editor: Aaryamann Challani \ contributors: - Jimmy Debe \ -sidebar_position: 1 --- - Category: Standards Track - Editor: Aaryamann Challani \ @@ -14,11 +13,11 @@ sidebar_position: 1 ## Abstract -This specification describes the usage of stealth commitments to add prospective users to a network-governed [32/RLN-V1](./32/rln-v1.md) membership set. +This specification describes the usage of stealth commitments to add prospective users to a network-governed [32/RLN-V1](./32/rln-v1) membership set. ## Motivation -When [32/RLN-V1](./32/rln-v1.md) is enforced in [10/Waku2](../waku/standards/core/10/waku2.md), +When [32/RLN-V1](./32/rln-v1) is enforced in [10/Waku2](../waku/standards/core/10/waku2), all users are required to register to a membership set. The membership set will store user identities allowing the secure interaction within an application. Forcing a user to do an on-chain transaction to join a membership set is an onboarding friction, @@ -28,24 +27,24 @@ stealth commitments can be used by a counterparty to register identities on the while maintaining the user's anonymity. This document specifies a privacy-preserving mechanism, -allowing a counterparty to utilize [32/RLN-V1](./32/rln-v1.md) to register an `identityCommitment` on-chain. +allowing a counterparty to utilize [32/RLN-V1](./32/rln-v1) to register an `identityCommitment` on-chain. Counterparties will be able to register members to a RLN membership set without exposing the user's private keys. ## Background -The [32/RLN-V1](./32/rln-v1.md) protocol, +The [32/RLN-V1](./32/rln-v1) protocol, consists of a smart contract that stores a `idenitityCommitment` in a membership set. In order for a user to join the membership set, the user is required to make a transaction on the blockchain. A set of public keys is used to compute a stealth commitment for a user, as described in [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564). This specification is an implementation of the [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) scheme, -tailored to the curve that is used in the [32/RLN-V1](./32/rln-v1.md) protocol. +tailored to the curve that is used in the [32/RLN-V1](./32/rln-v1) protocol. This can be used in a couple of ways in applications: -1. Applications can add users to the [32/RLN-V1](./32/rln-v1.md) membership set in a batch. -2. Users of the application can register other users to the [32/RLN-V1](./32/rln-v1.md) membership set. +1. Applications can add users to the [32/RLN-V1](./32/rln-v1) membership set in a batch. +2. Users of the application can register other users to the [32/RLN-V1](./32/rln-v1) membership set. -This is useful when the prospective user does not have access to funds on the network that [32/RLN-V1](./32/rln-v1.md) is deployed on. +This is useful when the prospective user does not have access to funds on the network that [32/RLN-V1](./32/rln-v1) is deployed on. ## Wire Format Specification @@ -105,6 +104,6 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -- [10/Waku2](../waku/standards/core/10/waku2.md) -- [32/RLN-V1](./32/rln-v1.md) +- [10/Waku2](../waku/standards/core/10/waku2) +- [32/RLN-V1](./32/rln-v1) - [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) diff --git a/vac/template.md b/vac/template.md index 89abd6c03..04418b3ff 100644 --- a/vac/template.md +++ b/vac/template.md @@ -5,7 +5,6 @@ status: (raw|draft|stable) category: (Standards Track|Informational|Best Current Practice) editor: Daniel Kaiser \ contributors: -sidebar_position: 1 --- - Status: (raw|draft|stable) - Category: (Standards Track|Informational|Best Current Practice) diff --git a/waku/README.md b/waku/README.md index 2117b35a4..18caa945f 100644 --- a/waku/README.md +++ b/waku/README.md @@ -1,5 +1,5 @@ -## Waku RFCs +# Waku RFCs Waku builds a family of privacy-preserving, censorship-resistant communication protocols for web3 applications. diff --git a/waku/deprecated/rpc.md b/waku/deprecated/16/rpc.md similarity index 86% rename from waku/deprecated/rpc.md rename to waku/deprecated/16/rpc.md index b7a3d011a..990f1a5a8 100644 --- a/waku/deprecated/rpc.md +++ b/waku/deprecated/16/rpc.md @@ -3,14 +3,13 @@ title: 16/WAKU2-RPC name: Waku v2 RPC API status: deprecated editor: Hanno Cornelius \ -sidebar_position: 16 --- - Status: deprecated - Editor: Hanno Cornelius \ ## Introduction -This specification describes the JSON-RPC API that Waku v2 nodes MAY adhere to. Refer to the [Waku v2 specification](../10/waku2.md) for more information on Waku v2. +This specification describes the JSON-RPC API that Waku v2 nodes MAY adhere to. Refer to the [Waku v2 specification](../10/waku2) for more information on Waku v2. ## Wire Protocol @@ -44,7 +43,7 @@ The following structured types are defined for use throughout the document: ### WakuMessage -Refer to [`Waku Message` specification](../14/message.md) for more information. +Refer to [`Waku Message` specification](../14/message) for more information. `WakuMessage` is an `Object` containing the following fields: @@ -54,7 +53,7 @@ Refer to [`Waku Message` specification](../14/message.md) for more information. | `contentTopic` | `String` | optional | Message content topic for optional content-based filtering | | `version` | `Number` | optional | Message version. Used to indicate type of payload encryption. Default version is 0 (no payload encryption). | | `timestamp` | `Number` | optional | The time at which the message is generated by its sender. This field holds the Unix epoch time in nanoseconds as a 64-bits integer value. | -| `ephemeral` | `Boolean` | optional | This flag indicates the transient nature of the message. Indicates if the message is eligible to be stored by the `store` protocol, [13/WAKU2-STORE](../13/store.md). | +| `ephemeral` | `Boolean` | optional | This flag indicates the transient nature of the message. Indicates if the message is eligible to be stored by the `store` protocol, [13/WAKU2-STORE](../13/store). | ## Method naming @@ -116,17 +115,17 @@ none ## Relay API -Refer to the [Waku Relay specification](../11/relay.md) for more information on the relaying of messages. +Refer to the [Waku Relay specification](../11/relay) for more information on the relaying of messages. ### `post_waku_v2_relay_v1_message` -The `post_waku_v2_relay_v1_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) +The `post_waku_v2_relay_v1_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) #### Parameters | Field | Type | Inclusion | Description | | ----: | :---: | :---: |----------- | -| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being published on | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) being published on | | `message` | [`WakuMessage`](#wakumessage) | mandatory | The `message` being relayed | #### Response @@ -135,13 +134,13 @@ The `post_waku_v2_relay_v1_message` method publishes a message to be relayed on ### `post_waku_v2_relay_v1_subscriptions` -The `post_waku_v2_relay_v1_subscriptions` method subscribes a node to an array of [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). +The `post_waku_v2_relay_v1_subscriptions` method subscribes a node to an array of [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor). #### Parameters | Field | Type | Inclusion | Description | | ----: | :---: | :---: |----------- | -| `topics` | `Array`[`String`] | mandatory | The [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being subscribed to | +| `topics` | `Array`[`String`] | mandatory | The [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) being subscribed to | #### Response @@ -149,13 +148,13 @@ The `post_waku_v2_relay_v1_subscriptions` method subscribes a node to an array o ### `delete_waku_v2_relay_v1_subscriptions` -The `delete_waku_v2_relay_v1_subscriptions` method unsubscribes a node from an array of [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). +The `delete_waku_v2_relay_v1_subscriptions` method unsubscribes a node from an array of [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor). #### Parameters | Field | Type | Inclusion | Description | | ----: | :---: | :---: |----------- | -| `topics` | `Array`[`String`] | mandatory | The [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being unsubscribed from | +| `topics` | `Array`[`String`] | mandatory | The [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) being unsubscribed from | #### Response @@ -163,13 +162,13 @@ The `delete_waku_v2_relay_v1_subscriptions` method unsubscribes a node from an a ### `get_waku_v2_relay_v1_messages` -The `get_waku_v2_relay_v1_messages` method returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. +The `get_waku_v2_relay_v1_messages` method returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. #### Parameters | Field | Type | Inclusion | Description | | ----: | :---: | :---: |----------- | -| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) to poll for the latest messages | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) to poll for the latest messages | #### Response @@ -177,7 +176,7 @@ The `get_waku_v2_relay_v1_messages` method returns a list of messages that were ## Relay Private API -The Private API provides functionality to encrypt/decrypt `WakuMessage` payloads using either symmetric or asymmetric cryptography. This allows backwards compatibility with [Waku v1 nodes](../../legacy/6/waku1.md). +The Private API provides functionality to encrypt/decrypt `WakuMessage` payloads using either symmetric or asymmetric cryptography. This allows backwards compatibility with [Waku v1 nodes](../../legacy/6/waku1). It is the API client's responsibility to keep track of the keys used for encrypted communication. Since keys must be cached by the client and provided to the node to encrypt/decrypt payloads, a Private API SHOULD NOT be exposed on non-local or untrusted nodes. ### Types @@ -217,7 +216,7 @@ none ### `post_waku_v2_private_v1_symmetric_message` -The `post_waku_v2_private_v1_symmetric_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). +The `post_waku_v2_private_v1_symmetric_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor). Before being relayed, the message payload is encrypted using the supplied symmetric key. The client MUST provide a symmetric key. @@ -225,7 +224,7 @@ Before being relayed, the message payload is encrypted using the supplied symmet | Field | Type | Inclusion | Description | | ----: | :---: | :---: |----------- | -| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being published on | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) being published on | | `message` | [`WakuMessage`](#wakumessage) | mandatory | The (unencrypted) `message` being relayed | | `symkey` | `String` | mandatory | The hex encoded symmetric key to use for payload encryption. This field MUST be included if symmetric key cryptography is selected | @@ -235,7 +234,7 @@ Before being relayed, the message payload is encrypted using the supplied symmet ### `post_waku_v2_private_v1_asymmetric_message` -The `post_waku_v2_private_v1_asymmetric_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). +The `post_waku_v2_private_v1_asymmetric_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor). Before being relayed, the message payload is encrypted using the supplied public key. The client MUST provide a public key. @@ -243,7 +242,7 @@ Before being relayed, the message payload is encrypted using the supplied public | Field | Type | Inclusion | Description | | ----: | :---: | :---: |----------- | -| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being published on | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) being published on | | `message` | [`WakuMessage`](#wakumessage) | mandatory | The (unencrypted) `message` being relayed | | `publicKey` | `String` | mandatory | The hex encoded public key to use for payload encryption. This field MUST be included if asymmetric key cryptography is selected | @@ -253,7 +252,7 @@ Before being relayed, the message payload is encrypted using the supplied public ### `get_waku_v2_private_v1_symmetric_messages` -The `get_waku_v2_private_v1_symmetric_messages` method decrypts and returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. +The `get_waku_v2_private_v1_symmetric_messages` method decrypts and returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. Before returning the messages, the server decrypts the message payloads using the supplied symmetric key. The client MUST provide a symmetric key. @@ -261,7 +260,7 @@ Before returning the messages, the server decrypts the message payloads using th | Field | Type | Inclusion | Description | | ----: | :---: | :---: |----------- | -| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) to poll for the latest messages | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) to poll for the latest messages | | `symkey` | `String` | mandatory | The hex encoded symmetric key to use for payload decryption. This field MUST be included if symmetric key cryptography is selected | #### Response @@ -270,7 +269,7 @@ Before returning the messages, the server decrypts the message payloads using th ### `get_waku_v2_private_v1_asymmetric_messages` -The `get_waku_v2_private_v1_asymmetric_messages` method decrypts and returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. +The `get_waku_v2_private_v1_asymmetric_messages` method decrypts and returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. Before returning the messages, the server decrypts the message payloads using the supplied private key. The client MUST provide a private key. @@ -278,7 +277,7 @@ Before returning the messages, the server decrypts the message payloads using th | Field | Type | Inclusion | Description | | ----: | :---: | :---: |----------- | -| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) to poll for the latest messages | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) to poll for the latest messages | | `privateKey` | `String` | mandatory | The hex encoded private key to use for payload decryption. This field MUST be included if asymmetric key cryptography is selected | #### Response @@ -288,7 +287,7 @@ Before returning the messages, the server decrypts the message payloads using th ## Store API -Refer to the [Waku Store specification](../13/store.md) for more information on message history retrieval. +Refer to the [Waku Store specification](../13/store) for more information on message history retrieval. ### Types @@ -341,8 +340,8 @@ The `get_waku_v2_store_v1_messages` method retrieves historical messages on spec | ----: | :---: | :---: |----------- | | `pubsubTopic` | `String` | optional | The pubsub topic on which a [`WakuMessage`](#wakumessage) is published | | `contentFilters` | `Array`[[`ContentFilter`](#contentfilter)] | optional | Array of content filters to query for historical messages | -| `startTime` | `Number`| optional | The inclusive lower bound on the [`timestamp`](../14/message.md/#message-attributes) of queried [`WakuMessage`s](#wakumessage). This field holds the Unix epoch time in nanoseconds as a 64-bits integer value. | -| `endTime` | `Number` | optional | The inclusive upper bound on the [`timestamp`](../14/message.md/#message-attributes) of queried [`WakuMessage`s](#wakumessage). This field holds the Unix epoch time in nanoseconds as a 64-bits integer value. | +| `startTime` | `Number`| optional | The inclusive lower bound on the [`timestamp`](../14/message#message-attributes) of queried [`WakuMessage`s](#wakumessage). This field holds the Unix epoch time in nanoseconds as a 64-bits integer value. | +| `endTime` | `Number` | optional | The inclusive upper bound on the [`timestamp`](../14/message#message-attributes) of queried [`WakuMessage`s](#wakumessage). This field holds the Unix epoch time in nanoseconds as a 64-bits integer value. | | `pagingOptions` | [`PagingOptions`](#pagingoptions) | optional | Pagination information | #### Response @@ -351,7 +350,7 @@ The `get_waku_v2_store_v1_messages` method retrieves historical messages on spec ## Filter API -Refer to the [Waku Filter specification](../12/filter.md) for more information on content filtering. +Refer to the [Waku Filter specification](../12/filter) for more information on content filtering. ### Types @@ -367,7 +366,7 @@ The following structured types are defined for use on the Filter API: ### `post_waku_v2_filter_v1_subscription` -The `post_waku_v2_filter_v1_subscription` method creates a subscription in a [light node](../12/filter.md/#rationale) for messages that matches a content filter and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). +The `post_waku_v2_filter_v1_subscription` method creates a subscription in a [light node](../12/filter#rationale) for messages that matches a content filter and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor). #### Parameters @@ -382,7 +381,7 @@ The `post_waku_v2_filter_v1_subscription` method creates a subscription in a [li ### `delete_waku_v2_filter_v1_subscription` -The `delete_waku_v2_filter_v1_subscription` method removes subscriptions in a [light node](../12/filter.md/#rationale) matching a content filter and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). +The `delete_waku_v2_filter_v1_subscription` method removes subscriptions in a [light node](../12/filter#rationale) matching a content filter and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor). #### Parameters @@ -636,5 +635,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public 1. [JSON-RPC specification](https://www.jsonrpc.org/specification) 1. [LibP2P Addressing](https://docs.libp2p.io/concepts/addressing/) 1. [LibP2P PubSub specification - topic descriptor](https://github.com/libp2p/specs/tree/master/pubsub#the-topic-descriptor) -1. [Waku v2 specification](../10/waku2.md) +1. [Waku v2 specification](../10/waku2) 1. [IETF RFC 4648 - The Base16, Base32, and Base64 Data Encodings](https://datatracker.ietf.org/doc/html/rfc4648) diff --git a/waku/deprecated/swap.md b/waku/deprecated/18/swap.md similarity index 98% rename from waku/deprecated/swap.md rename to waku/deprecated/18/swap.md index a536a66be..fd5d7e4d1 100644 --- a/waku/deprecated/swap.md +++ b/waku/deprecated/18/swap.md @@ -4,7 +4,6 @@ name: Waku SWAP Accounting status: deprecated editor: Oskar Thorén \ contributor: Ebube Ud \ -sidebar_position: 18 --- - Status: deprecated - Editor: Oskar Thorén \ @@ -143,7 +142,7 @@ In the soft phase only accounting is performed, without consequence for the peers. No disconnect or sending of cheques is performed at this tage. SWAP protocol is performed in conjunction with another request-reply protocol to account for its usage. -It SHOULD be done for [13/WAKU2-STORE](../../core/13/store.md) +It SHOULD be done for [13/WAKU2-STORE](../../core/13/store) and it MAY be done for other request/reply protocols. A client SHOULD log accounting state per peer @@ -175,7 +174,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public 1. [Prisoner's Dilemma](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma) 2. [Axelrod - Evolution of Cooperation (book)](https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation) 3. [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth) -4. [13/WAKU2-STORE](../../core/13/store.md) +4. [13/WAKU2-STORE](../../core/13/store) @@ -186,28 +185,28 @@ Copyright and related rights waived via ## References -1. [`10/WAKU2`](../10/waku2.md) +1. [`10/WAKU2`](../10/waku2) -1. [`14/WAKU2-MESSAGE`](../14/message.md) +1. [`14/WAKU2-MESSAGE`](../14/message) -1. [`17/WAKU-RLN`](../17/rln-relay.md) +1. [`17/WAKU-RLN`](../17/rln-relay) -1. [GossipSub v1.0](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md) +1. [GossipSub v1.0](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0) -1. [GossipSub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) +1. [GossipSub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1) 1. [K-anonimity](https://www.privitar.com/blog/k-anonymity-an-introduction/) 1. [`libp2p` concepts: Publish/Subscribe](https://docs.libp2p.io/concepts/publish-subscribe/) -1. [`libp2p` protocol negotiation](https://github.com/libp2p/specs/blob/master/connections/README.md#protocol-negotiation) +1. [`libp2p` protocol negotiation](https://github.com/libp2p/specs/blob/master/connections/README##protocol-negotiation) 1. [Partitioned topics](https://specs.status.im/spec/10#partitioned-topic) 1. [Protocol Buffers](https://developers.google.com/protocol-buffers/) -1. [PubSub interface for libp2p (r2, 2019-02-01)](https://github.com/libp2p/specs/blob/master/pubsub/README.md) +1. [PubSub interface for libp2p (r2, 2019-02-01)](https://github.com/libp2p/specs/blob/master/pubsub/README) -1. [Waku v1 spec](../6/waku1.md) +1. [Waku v1 spec](../6/waku1) 1. [Whisper spec (EIP627)](https://eips.ethereum.org/EIPS/eip-627) diff --git a/waku/standards/core/12/filter.md b/waku/standards/core/12/filter.md index 8d01d1080..10ef80418 100644 --- a/waku/standards/core/12/filter.md +++ b/waku/standards/core/12/filter.md @@ -2,31 +2,35 @@ title: 12/WAKU2-FILTER name: Waku v2 Filter status: draft +version: 01 editor: Hanno Cornelius \ contributors: - Dean Eigenmann \ - - Oskar Thorén \ + - Oskar Thorén \ - Sanaz Taheri \ - Ebube Ud \ -sidebar_position: 12 --- - Status: draft - Editor: Hanno Cornelius \ - Contributors:: - Dean Eigenmann \ - - Oskar Thorén \ + - Oskar Thorén \ - Sanaz Taheri \ - Ebube Ud \ - Contributors:: -version: 00 + +previous versions: [00](./previous-versions00) --- + `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` +**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](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering). @@ -71,80 +75,164 @@ The following are not considered as part of the adversarial model: ### Protobuf ```protobuf -message FilterRequest { - bool subscribe = 1; - string topic = 2; - repeated ContentFilter contentFilters = 3; +syntax = "proto3"; - message ContentFilter { - string contentTopic = 1; +// 12/WAKU2-FILTER rfc: https://rfc.vac.dev/spec/12/ +package waku.filter.v2; + +// Protocol identifier: /vac/waku/filter-subscribe/2.0.0-beta1 +message FilterSubscribeRequest { + enum FilterSubscribeType { + SUBSCRIBER_PING = 0; + SUBSCRIBE = 1; + UNSUBSCRIBE = 2; + UNSUBSCRIBE_ALL = 3; } + + string request_id = 1; + FilterSubscribeType filter_subscribe_type = 2; + + // Filter criteria + optional string pubsub_topic = 10; + repeated string content_topics = 11; } +message FilterSubscribeResponse { + string request_id = 1; + uint32 status_code = 10; + optional string status_desc = 11; +} + +// Protocol identifier: /vac/waku/filter-push/2.0.0-beta1 message MessagePush { - repeated WakuMessage messages = 1; -} - -message FilterRPC { - string requestId = 1; - FilterRequest request = 2; - MessagePush push = 3; + WakuMessage waku_message = 1; + optional string pubsub_topic = 2; } ``` -#### FilterRPC +### Filter-Subscribe -A node MUST send all Filter messages (`FilterRequest`, `MessagePush`) wrapped inside a -`FilterRPC` this allows the node handler to determine how to handle a message as the Waku -Filter protocol is not a request response based protocol but instead a push based system. +A filter service node MUST support the _filter-subscribe_ protocol +to allow filter clients to subscribe, modify, refresh and unsubscribe a desired set of filter criteria. +The combination of different filter criteria for a specific filter client node is termed a "subscription". +A filter client is interested in receiving messages matching the filter criteria in its registered subscriptions. -The `requestId` MUST be a uniquely generated string. When a `MessagePush` is sent -the `requestId` MUST match the `requestId` of the subscribing `FilterRequest` whose filters -matched the message causing it to be pushed. +Since a filter service node is consuming resources to provide this service, +it MAY account for usage and adapt its service provision to certain clients. +An incentive mechanism is currently planned but underspecified. -#### FilterRequest +#### Filter Subscribe Request -A `FilterRequest` contains an optional topic, zero or more content filters and -a boolean signifying whether to subscribe or unsubscribe to the given filters. -True signifies 'subscribe' and false signifies 'unsubscribe'. +A client node MUST send all filter requests in a `FilterSubscribeRequest` message. +This request MUST contain a `request_id`. +The `request_id` MUST be a uniquely generated string. +Each request MUST include a `filter_subscribe_type`, indicating the type of request. -A node that sends the RPC with a filter request and `subscribe` set to 'true' -requests that the filter node SHOULD notify the light requesting node of messages -matching this filter. +#### Filter Subscribe Response -A node that sends the RPC with a filter request and `subscribe` set to 'false' -requests that the filter node SHOULD stop notifying the light requesting node -of messages matching this filter if it is currently doing so. +In return to any `FilterSubscribeRequest`, +a filter service node SHOULD respond with a `FilterSubscribeResponse` with a `requestId` matching that of the request. +This response MUST contain a `status_code` indicating if the request was successful or not. +Successful status codes are in the `2xx` range. +Client nodes SHOULD consider all other status codes as error codes and assume that the requested operation had failed. +In addition, the filter service node MAY choose to provide a more detailed status description in the `status_desc` field. -The filter matches when content filter and, optionally, a topic is matched. -Content filter is matched when a `WakuMessage` `contentTopic` field is the same. +#### Filter matching -A filter node SHOULD honor this request, though it MAY choose not to do so. If -it chooses not to do so it MAY tell the light why. The mechanism for doing this -is currently not specified. For notifying the light node a filter node sends a -MessagePush message. +In the description of each request type below, +the term "filter criteria" refers to the combination of `pubsub_topic` and a set of `content_topics`. +The request MAY include filter criteria, conditional to the selected `filter_subscribe_type`. +If the request contains filter criteria, +it MUST contain a `pubsub_topic` +and the `content_topics` set MUST NOT be empty. +A `WakuMessage` matches filter criteria when its `content_topic` is in the `content_topics` set +and it was published on a matching `pubsub_topic`. -Since such a filter node is doing extra work for a light node, it MAY also -account for usage and be selective in how much service it provides. This -mechanism is currently planned but underspecified. +#### Filter Subscribe Types -#### MessagePush +The following filter subscribe types are defined: -A filter node that has received a filter request SHOULD push all messages that -match this filter to a light node. These [`WakuMessage`'s](../14/message.md) are likely to come from the -`relay` protocol and be kept at the Node, but there MAY be other sources or -protocols where this comes from. This is up to the consumer of the protocol. +##### SUBSCRIBER_PING -A filter node MUST NOT send a push message for messages that have not been -requested via a FilterRequest. +A filter client that sends a `FilterSubscribeRequest` with `filter_subscribe_type` set to `SUBSCRIBER_PING` +requests that the service node SHOULD indicate if it has any active subscriptions for this client. +The filter client SHOULD exclude any filter criteria from the request. +The filter service node SHOULD respond with a success code if it has any active subscriptions for this client +or an error code if not. +The filter service node SHOULD ignore any filter criteria in the request. -If a specific light node isn't connected to a filter node for some specific -period of time (e.g. a TTL), then the filter node MAY choose to not push these -messages to the node. This period is up to the consumer of the protocol and node -implementation, though a reasonable default is one minute. +##### SUBSCRIBE + +A filter client that sends a `FilterSubscribeRequest` with `filter_subscribe_type` set to `SUBSCRIBE` +requests that the service node SHOULD push messages matching this filter to the client. +The filter client MUST include the desired filter criteria in the request. +A client MAY use this request type to _modify_ an existing subscription +by providing _additional_ filter criteria in a new request. +A client MAY use this request type to _refresh_ an existing subscription +by providing _the same_ filter criteria in a new request. +The filter service node SHOULD respond with a success code if it successfully honored this request +or an error code if not. +The filter service node SHOULD respond with an error code and discard the request +if the subscribe request does not contain valid filter criteria, +i.e. both a `pubsub_topic` _and_ a non-empty `content_topics` set. + +##### UNSUBSCRIBE + +A filter client that sends a `FilterSubscribeRequest` with `filter_subscribe_type` set to `UNSUBSCRIBE` +requests that the service node SHOULD _stop_ pushing messages matching this filter to the client. +The filter client MUST include the filter criteria it desires to unsubscribe from in the request. +A client MAY use this request type to _modify_ an existing subscription +by providing _a subset of_ the original filter criteria to unsubscribe from in a new request. +The filter service node SHOULD respond with a success code if it successfully honored this request +or an error code if not. +The filter service node SHOULD respond with an error code and discard the request +if the unsubscribe request does not contain valid filter criteria, +i.e. both a `pubsub_topic` _and_ a non-empty `content_topics` set. + +##### UNSUBSCRIBE_ALL + +A filter client that sends a `FilterSubscribeRequest` with `filter_subscribe_type` set to `UNSUBSCRIBE_ALL` +requests that the service node SHOULD _stop_ pushing messages matching _any_ filter to the client. +The filter client SHOULD exclude any filter criteria from the request. +The filter service node SHOULD remove any existing subscriptions for this client. +It SHOULD respond with a success code if it successfully honored this request +or an error code if not. + +### Filter-Push + +A filter client node MUST support the _filter-push_ protocol +to allow filter service nodes to push messages matching registered subscriptions to this client. + +A filter service node SHOULD push all messages +matching the filter criteria in a registered subscription +to the subscribed filter client. +These [`WakuMessage`s](../14/message) are likely to come from [`11/WAKU2-RELAY`](../11/relay), +but there MAY be other sources or protocols where this comes from. +This is up to the consumer of the protocol. + +If a message push fails, +the filter service node MAY consider the client node to be unreachable. +If a specific filter client node is not reachable from the service node for a period of time, +the filter service node MAY choose to stop pushing messages to the client and remove its subscription. +This period is up to the service node implementation. +We consider `1 minute` to be a reasonable default. + +#### Message Push + +Each message MUST be pushed in a `MessagePush` message. +Each `MessagePush` MUST contain one (and only one) `waku_message`. +If this message was received on a specific `pubsub_topic`, +it SHOULD be included in the `MessagePush`. +A filter client SHOULD NOT respond to a `MessagePush`. +Since the filter protocol does not include caching or fault-tolerance, +this is a best effort push service with no bundling +or guaranteed retransmission of messages. +A filter client SHOULD verify that each `MessagePush` it receives +originated from a service node where the client has an active subscription +and that it matches filter criteria belonging to that subscription. --- -# Future Work +## Future Work @@ -178,6 +266,13 @@ Copyright and related rights waived via ## References +- [message-based +filtering](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering) +- [`WakuMessage`s](../14/message) +- [`11/WAKU2-RELAY`](../11/relay) +- [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains) +- previous versions: [00](./previous-versions00) + 1. [Message Filtering (Wikipedia)](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering) 2. [Libp2p PubSub spec - topic validation](https://github.com/libp2p/specs/tree/master/pubsub#topic-validation) diff --git a/waku/standards/core/12/previous-versions00/filter.md b/waku/standards/core/12/previous-versions00/filter.md new file mode 100644 index 000000000..642f0a73f --- /dev/null +++ b/waku/standards/core/12/previous-versions00/filter.md @@ -0,0 +1,182 @@ +--- +title: 12/WAKU2-FILTER +name: Waku v2 Filter +status: draft +editor: Hanno Cornelius \ +contributors: + - Dean Eigenmann \ + - Oskar Thorén \ + - Sanaz Taheri \ + - Ebube Ud \ +--- +- Status: draft +- Editor: Hanno Cornelius \ +- Contributors:: + - Dean Eigenmann \ + - Oskar Thorén \ + - Sanaz Taheri \ + - Ebube Ud \ +- Contributors:: + +version: 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 identifier***: `/vac/waku/filter/2.0.0-beta1` + +Content filtering is a way to do [message-based +filtering](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering). +Currently the only content filter being applied is on `contentTopic`. This +corresponds to topics in Waku v1. + +## Rationale + +Unlike the `store` protocol for historical messages, this protocol allows for +native lower latency scenarios such as instant messaging. It is thus +complementary to it. + +Strictly speaking, it is not just doing basic request response, but performs +sender push based on receiver intent. While this can be seen as a form of light +pub/sub, it is only used between two nodes in a direct fashion. Unlike the +Gossip domain, this is meant for light nodes which put a premium on bandwidth. +No gossiping takes place. + +It is worth noting that a light node could get by with only using the `store` +protocol to query for a recent time window, provided it is acceptable to do +frequent polling. + + +## Design Requirements + +The effectiveness and reliability of the content filtering service enabled by `WakuFilter` protocol rely on the *high availability* of the full nodes as the service providers. To this end, full nodes must feature *high uptime* (to persistently listen and capture the network messages) as well as *high Bandwidth* (to provide timely message delivery to the light nodes). + +## Security Consideration + +Note that while using `WakuFilter` allows light nodes to save bandwidth, it comes with a privacy cost in the sense that they need to disclose their liking topics to the full nodes to retrieve the relevant messages. Currently, anonymous subscription is not supported by the `WakuFilter`, however, potential solutions in this regard are sketched below in [Future Work](#future-work) section. + +### Terminology +The term Personally identifiable information (PII) refers to any piece of data that can be used to uniquely identify a user. For example, the signature verification key, and the hash of one's static IP address are unique for each user and hence count as PII. + +## Adversarial Model +Any node running the `WakuFilter` protocol i.e., both the subscriber node and the queried node are considered as an adversary. Furthermore, we consider the adversary as a passive entity that attempts to collect information from other nodes to conduct an attack but it does so without violating protocol definitions and instructions. For example, under the passive adversarial model, no malicious node intentionally hides the messages matching to one's subscribed content filter as it is against the description of the `WakuFilter` protocol. + +The following are not considered as part of the adversarial model: + - An adversary with a global view of all the nodes and their connections. + - An adversary that can eavesdrop on communication links between arbitrary pairs of nodes (unless the adversary is one end of the communication). In specific, the communication channels are assumed to be secure. + +### Protobuf + +```protobuf +message FilterRequest { + bool subscribe = 1; + string topic = 2; + repeated ContentFilter contentFilters = 3; + + message ContentFilter { + string contentTopic = 1; + } +} + +message MessagePush { + repeated WakuMessage messages = 1; +} + +message FilterRPC { + string requestId = 1; + FilterRequest request = 2; + MessagePush push = 3; +} +``` + +#### FilterRPC + +A node MUST send all Filter messages (`FilterRequest`, `MessagePush`) wrapped inside a +`FilterRPC` this allows the node handler to determine how to handle a message as the Waku +Filter protocol is not a request response based protocol but instead a push based system. + +The `requestId` MUST be a uniquely generated string. When a `MessagePush` is sent +the `requestId` MUST match the `requestId` of the subscribing `FilterRequest` whose filters +matched the message causing it to be pushed. + +#### FilterRequest + +A `FilterRequest` contains an optional topic, zero or more content filters and +a boolean signifying whether to subscribe or unsubscribe to the given filters. +True signifies 'subscribe' and false signifies 'unsubscribe'. + +A node that sends the RPC with a filter request and `subscribe` set to 'true' +requests that the filter node SHOULD notify the light requesting node of messages +matching this filter. + +A node that sends the RPC with a filter request and `subscribe` set to 'false' +requests that the filter node SHOULD stop notifying the light requesting node +of messages matching this filter if it is currently doing so. + +The filter matches when content filter and, optionally, a topic is matched. +Content filter is matched when a `WakuMessage` `contentTopic` field is the same. + +A filter node SHOULD honor this request, though it MAY choose not to do so. If +it chooses not to do so it MAY tell the light why. The mechanism for doing this +is currently not specified. For notifying the light node a filter node sends a +MessagePush message. + +Since such a filter node is doing extra work for a light node, it MAY also +account for usage and be selective in how much service it provides. This +mechanism is currently planned but underspecified. + +#### MessagePush + +A filter node that has received a filter request SHOULD push all messages that +match this filter to a light node. These [`WakuMessage`'s](../14/message) are likely to come from the +`relay` protocol and be kept at the Node, but there MAY be other sources or +protocols where this comes from. This is up to the consumer of the protocol. + +A filter node MUST NOT send a push message for messages that have not been +requested via a FilterRequest. + +If a specific light node isn't connected to a filter node for some specific +period of time (e.g. a TTL), then the filter node MAY choose to not push these +messages to the node. This period is up to the consumer of the protocol and node +implementation, though a reasonable default is one minute. + +--- +# Future Work + + + +**Anonymous filter subscription**: This feature guarantees that nodes can anonymously subscribe for a message filter (i.e., without revealing their exact content filter). As such, no adversary in the `WakuFilter` protocol would be able to link nodes to their subscribed content filers. The current version of the `WakuFilter` protocol does not provide anonymity as the subscribing node has a direct connection to the full node and explicitly submits its content filter to be notified about the matching messages. However, one can consider preserving anonymity through one of the following ways: +- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor + +. + Note that the current structure of filter requests i.e., `FilterRPC` does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve anonymity. +- By deploying secure 2-party computations in which the subscribing node obtains the messages matching a content filter whereas the full node learns nothing about the content filter as well as the messages pushed to the subscribing node. Examples of such 2PC protocols are [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains.) and one-way Private Set Intersections (PSI). + +## Changelog + +### Next + +- Added initial threat model and security analysis. + +### 2.0.0-beta2 + +Initial draft version. Released [2020-10-28](https://github.com/vacp2p/specs/commit/5ceeb88cee7b918bb58f38e7c4de5d581ff31e68) +- Fix: Ensure contentFilter is a repeated field, on implementation +- Change: Add ability to unsubscribe from filters. Make `subscribe` an explicit boolean indication. Edit protobuf field order to be consistent with libp2p. + +### 2.0.0-beta1 + +Initial draft version. Released [2020-10-05](https://github.com/vacp2p/specs/commit/31857c7434fa17efc00e3cd648d90448797d107b) + +## Copyright + +Copyright and related rights waived via +[CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References + +1. [Message Filtering (Wikipedia)](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering) + +2. [Libp2p PubSub spec - topic validation](https://github.com/libp2p/specs/tree/master/pubsub#topic-validation) diff --git a/waku/standards/core/store.md b/waku/standards/core/13/store.md similarity index 97% rename from waku/standards/core/store.md rename to waku/standards/core/13/store.md index 9377fd99a..c7ad6498f 100644 --- a/waku/standards/core/store.md +++ b/waku/standards/core/13/store.md @@ -9,7 +9,6 @@ contributors: - Aaryamann Challani \ - Sanaz Taheri \ - Hanno Cornelius \ -sidebar_position: 13 --- - Status: draft - Editor: Simon-Pierre Vivier \ @@ -46,8 +45,8 @@ intact view of the message history is delivered to the querying nodes. Nevertheless, in case storage provider nodes cannot afford high availability, the querying nodes may retrieve the historical messages from multiple sources to achieve a full and intact view of the past. -The concept of `ephemeral` messages introduced in [`14/WAKU2-MESSAGE`](../14/message.md) affects `13/WAKU2-STORE` as well. -Nodes running `13/WAKU2-STORE` SHOULD support `ephemeral` messages as specified in [14/WAKU2-MESSAGE](../14/message.md). +The concept of `ephemeral` messages introduced in [`14/WAKU2-MESSAGE`](../14/message) affects `13/WAKU2-STORE` as well. +Nodes running `13/WAKU2-STORE` SHOULD support `ephemeral` messages as specified in [14/WAKU2-MESSAGE](../14/message). Nodes running `13/WAKU2-STORE` SHOULD NOT store messages with the `ephemeral` flag set to `true`. ## Adversarial Model @@ -128,7 +127,7 @@ message HistoryRPC { To perform pagination, each `WakuMessage` stored at a node running the `13/WAKU2-STORE` protocol is associated with a unique `Index` that encapsulates the following parts. - `digest`: a sequence of bytes representing the SHA256 hash of a `WakuMessage`. - The hash is computed over the concatenation of `contentTopic` and `payload` fields of a `WakuMessage` (see [14/WAKU2-MESSAGE](../14/message.md)). + The hash is computed over the concatenation of `contentTopic` and `payload` fields of a `WakuMessage` (see [14/WAKU2-MESSAGE](../14/message)). - `receiverTime`: the UNIX time in nanoseconds at which the `WakuMessage` is received by the receiving node. - `senderTime`: the UNIX time in nanoseconds at which the `WakuMessage` is generated by its sender. - `pubsubTopic`: the pubsub topic on which the `WakuMessage` is received. @@ -144,7 +143,7 @@ each `WakuMessage` stored at a node running the `13/WAKU2-STORE` protocol is ass #### ContentFilter `ContentFilter` carries the information required for filtering historical messages. - `contentTopic` represents the content topic of the queried historical `WakuMessage`. - This field maps to the `contentTopic` field of the [14/WAKU2-MESSAGE](../14/message.md). + This field maps to the `contentTopic` field of the [14/WAKU2-MESSAGE](../14/message). #### HistoryQuery @@ -152,7 +151,7 @@ RPC call to query historical messages. - The `pubsubTopic` field MUST indicate the pubsub topic of the historical messages to be retrieved. This field denotes the pubsub topic on which `WakuMessage`s are published. - This field maps to `topicIDs` field of `Message` in [`11/WAKU2-RELAY`](../11/relay.md). + This field maps to `topicIDs` field of `Message` in [`11/WAKU2-RELAY`](../11/relay). Leaving this field empty means no filter on the pubsub topic of message history is requested. This field SHOULD be left empty in order to retrieve the historical `WakuMessage` regardless of the pubsub topics on which they are published. - The `contentFilters` field MUST indicate the list of content filters based on which the historical messages are to be retrieved. @@ -189,13 +188,13 @@ nodes' clock asynchrony. RPC call to respond to a HistoryQuery call. - The `messages` field MUST contain the messages found, -these are [14/WAKU2-MESSAGE](../14/message.md) types. +these are [14/WAKU2-MESSAGE](../14/message) types. - `PagingInfo` holds the paging information based on which the querying node can resume its further history queries. The `pageSize` indicates the number of returned Waku messages (i.e., the number of messages included in the `messages` field of `HistoryResponse`). The `direction` is the same direction as in the corresponding `HistoryQuery`. In the forward pagination, the `cursor` holds the `Index` of the last message in the `HistoryResponse` `messages` (and the first message in the backward paging). Regardless of the paging direction, the retrieved `messages` are always sorted in ascending order based on their timestamp as explained in the [sorting messages](#sorting-messages) section, that is, from the oldest to the most recent. - The requester SHALL embed the returned `cursor` inside its next `HistoryQuery` to retrieve the next page of the [14/WAKU2-MESSAGE](../14/message.md). + The requester SHALL embed the returned `cursor` inside its next `HistoryQuery` to retrieve the next page of the [14/WAKU2-MESSAGE](../14/message). The `cursor` obtained from one node SHOULD NOT be used in a request to another node because the result may be different. - The `error` field contains information about any error that has occurred while processing the corresponding `HistoryQuery`. `NONE` stands for no error. @@ -209,9 +208,9 @@ The main security consideration to take into account while using this protocol i ## Future Work - **Anonymous query**: This feature guarantees that nodes can anonymously query historical messages from other nodes i.e., -without disclosing the exact topics of [14/WAKU2-MESSAGE](../14/message.md) they are interested in. +without disclosing the exact topics of [14/WAKU2-MESSAGE](../14/message) they are interested in. As such, no adversary in the `13/WAKU2-STORE` protocol would be able to learn which peer is interested in which content filters i.e., -content topics of [14/WAKU2-MESSAGE](../14/message.md). +content topics of [14/WAKU2-MESSAGE](../14/message). The current version of the `13/WAKU2-STORE` protocol does not provide anonymity for historical queries, as the querying node needs to directly connect to another node in the `13/WAKU2-STORE` protocol and explicitly disclose the content filters of its interest to retrieve the corresponding messages. @@ -270,7 +269,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). ## References -1. [14/WAKU2-MESSAGE](../14/message.md) +1. [14/WAKU2-MESSAGE](../14/message) 2. [protocol buffers v3](https://developers.google.com/protocol-buffers/) -3. [11/WAKU2-RELAY](../11/relay.md) +3. [11/WAKU2-RELAY](../11/relay) 4. [Open timestamps](https://opentimestamps.org/) diff --git a/waku/standards/core/message.md b/waku/standards/core/14/message.md similarity index 95% rename from waku/standards/core/message.md rename to waku/standards/core/14/message.md index 31086ec87..ff99fa5f0 100644 --- a/waku/standards/core/message.md +++ b/waku/standards/core/14/message.md @@ -10,7 +10,6 @@ contributors: - Lorenzo Delgado \ - Abhimanyu Rawat \ - Oskar Thorén \ -sidebar_position: 14 --- - Status: draft - Category: Standards Track @@ -37,7 +36,7 @@ When sending messages over Waku, there are multiple requirements: - One may have a separate encryption layer as part of the application. - One may want to provide efficient routing for resource-restricted devices. -- One may want to provide compatibility with [Waku v1 envelopes](../../legacy/6/waku1.md). +- One may want to provide compatibility with [Waku v1 envelopes](../../legacy/6/waku1). - One may want encrypted payloads by default. - One may want to provide unlinkability to get metadata protection. @@ -59,7 +58,7 @@ The data payload is also treated as a Waku message attribute for convenience. * The `payload` attribute MUST contain the message data payload to be sent. * The `content_topic` attribute MUST specify a string identifier that can be used for content-based filtering, -as described in [23/WAKU2-TOPICS](../../../informational/23/topics.md). +as described in [23/WAKU2-TOPICS](../../../informational/23/topics). * The `meta` attribute, if present, contains an arbitrary application-specific variable-length byte array with a maximum length limit of 64 bytes. This attribute can be utilized to convey supplementary details to various Waku protocols, thereby enabling customized processing based on its contents. @@ -105,13 +104,13 @@ The message `version` attribute indicates the schema used to encrypt the payload The payload SHOULD be interpreted as unencrypted; additionally, it CAN indicate that the message payload has been encrypted at the application layer. - **Version 1:** -The payload SHOULD be encrypted using Waku v1 payload encryption specified in [26/WAKU-PAYLOAD](../../application/26/payload.md). +The payload SHOULD be encrypted using Waku v1 payload encryption specified in [26/WAKU-PAYLOAD](../../application/26/payload). This provides asymmetric and symmetric encryption. The key agreement is performed out of band. And provides an encrypted signature and padding for some form of unlinkability. - **Version 2:** -The payload SHOULD be encoded according to [35/WAKU2-NOISE]([/spec/35](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)). +The payload SHOULD be encoded according to [35/WAKU2-NOISE]([/spec/35](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise)). Waku Noise protocol provides symmetric encryption and asymmetric key exchange. Any `version` value not included in this list is reserved for future specification. @@ -204,7 +203,7 @@ Therefore, because message timestamps aren’t independently verified, this attr It should not solely be relied upon for operations such as message ordering. For example, a malicious actor can arbitrarily set the `timestamp` of a Waku message to a high value so that it always shows up as the most recent message in a chat application. Applications using Waku messages’ `timestamp` attribute are recommended to use additional methods for more robust message ordering. -An example of how to deal with message ordering against adversarial message timestamps can be found in the Status protocol, see [62/STATUS-PAYLOADS](../../../../status/62/payloads.md/#clock-vs-timestamp-and-message-ordering). +An example of how to deal with message ordering against adversarial message timestamps can be found in the Status protocol, see [62/STATUS-PAYLOADS](../../../../status/62/payloads#clock-vs-timestamp-and-message-ordering). ### Reliability of the `ephemeral` attribute @@ -219,8 +218,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -- [6/WAKU1](../../legacy/6/waku1.md) +- [6/WAKU1](../../legacy/6/waku1) - [Google Protocol buffers v3](https://developers.google.com/protocol-buffers/) -- [26/WAKU-PAYLOAD](../../application/26/payload.md) -- [35/WAKU2-NOISE]([/spec/35](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)) -- [62/STATUS-PAYLOADS](../../../../status/62/payloads.md/#clock-vs-timestamp-and-message-ordering) +- [26/WAKU-PAYLOAD](../../application/26/payload) +- [35/WAKU2-NOISE]([/spec/35](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise)) +- [62/STATUS-PAYLOADS](../../../../status/62/payloads#clock-vs-timestamp-and-message-ordering) diff --git a/waku/standards/core/bridge.md b/waku/standards/core/15/bridge.md similarity index 99% rename from waku/standards/core/bridge.md rename to waku/standards/core/15/bridge.md index a9aac7937..286f5a555 100644 --- a/waku/standards/core/bridge.md +++ b/waku/standards/core/15/bridge.md @@ -3,7 +3,6 @@ title: 15/WAKU-BRIDGE name: Waku Bridge status: draft editor: Hanno Cornelius \ -sidebar_position: 15 --- - Status: draft - Editor: Hanno Cornelius \ diff --git a/waku/standards/core/rln-relay.md b/waku/standards/core/17/rln-relay.md similarity index 93% rename from waku/standards/core/rln-relay.md rename to waku/standards/core/17/rln-relay.md index 9e9fe8f63..48834bc2c 100644 --- a/waku/standards/core/rln-relay.md +++ b/waku/standards/core/17/rln-relay.md @@ -8,7 +8,6 @@ contributors: - Aaryamann Challani \ - Sanaz Taheri \ - Hanno Cornelius \ -sidebar_position: 17 --- - Status: draft - Editor: Alvaro Revuelta \ @@ -18,7 +17,7 @@ sidebar_position: 17 - Sanaz Taheri \ - Hanno Cornelius \ -The `17/WAKU2-RLN-RELAY` protocol is an extension of `11/WAKU2-RELAY` which additionally provides spam protection using [Rate Limiting Nullifiers (RLN)](../../../../vac/32/rln-v1.md). +The `17/WAKU2-RLN-RELAY` protocol is an extension of `11/WAKU2-RELAY` which additionally provides spam protection using [Rate Limiting Nullifiers (RLN)](../../../../vac/32/rln-v1). 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. @@ -35,7 +34,7 @@ In open and anonymous p2p messaging networks, one big problem is spam resistance Existing solutions, such as Whisper’s proof of work are computationally expensive hence not suitable for resource-limited nodes. Other reputation-based approaches might not be desirable, due to issues around arbitrary exclusion and privacy. -We augment the [`11/WAKU2-RELAY`](../11/relay.md) protocol with a novel construct of [RLN](../../../../vac/32/rln-v1.md) to enable an efficient economic spam prevention mechanism that can be run in resource-constrained environments. +We augment the [`11/WAKU2-RELAY`](../11/relay) protocol with a novel construct of [RLN](../../../../vac/32/rln-v1) to enable an efficient economic spam prevention mechanism that can be run in resource-constrained environments. ## Flow @@ -51,13 +50,13 @@ The higher-level layers adopting `17/WAKU2-RLN-RELAY` MAY choose to enforce the ### Setup and Registration -Peers subscribed to a specific `pubsubTopic` form a [RLN group](../../../../vac/32/rln-v1.md). +Peers subscribed to a specific `pubsubTopic` form a [RLN group](../../../../vac/32/rln-v1). Peers MUST be registered to the RLN group to be able to publish messages. Registration is moderated through a smart contract deployed on the Ethereum blockchain. -Each peer has an [RLN key pair](../../../../vac/32/rln-v1.md) denoted by `sk` and `pk`. +Each peer has an [RLN key pair](../../../../vac/32/rln-v1) denoted by `sk` and `pk`. The secret key `sk` is secret data and MUST be persisted securely by the peer. The state of the membership contract contains the list of registered members' public identity keys i.e., `pk`s. For the registration, a peer creates a transaction that invokes the registration function of the contract via which registers its `pk` in the group. @@ -71,12 +70,12 @@ The peer who has the secret key `sk` associated with a registered `pk` would be Note that `sk` is initially only known to its owning peer however, it may get exposed to other peers in case the owner attempts spamming the system i.e., sending more than one message per `epoch`. An overview of registration is illustrated in Figure 1. -![Figure 1: Registration.](./17/images/rln-relay.png) +![Figure 1: Registration.](./images/rln-relay.png) ### Publishing -To publish at a given `epoch`, the publishing peer proceeds based on the regular [`11/WAKU2-RELAY`](../11/relay.md) protocol. +To publish at a given `epoch`, the publishing peer proceeds based on the regular [`11/WAKU2-RELAY`](../11/relay) protocol. However, to protect against spamming, each `WakuMessage` (which is wrapped inside the `data` field of a PubSub message) MUST carry a [`RateLimitProof`](##RateLimitProof) with the following fields. Section [Payload](#payloads) covers the details about the type and encoding of these fields. @@ -88,7 +87,7 @@ The `nullifier` is an internal nullifier acting as a fingerprint that allows spe The `nullifier` is a deterministic value derived from `sk` and `epoch` therefore any two messages issued by the same peer (i.e., using the same `sk`) for the same `epoch` are guaranteed to have identical `nullifier`s. The `share_x` and `share_y` can be seen as partial disclosure of peer's `sk` for the intended `epoch`. -They are derived deterministically from peer's `sk` and current `epoch` using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md). +They are derived deterministically from peer's `sk` and current `epoch` using [Shamir secret sharing scheme](../../../../vac/32/rln-v1). If a peer discloses more than one such pair (`share_x`, `share_y`) for the same `epoch`, it would allow full disclosure of its `sk` and hence get access to its staked fund in the membership contract. @@ -96,7 +95,7 @@ The `proof` field is a zero-knowledge proof signifying that: 1. The message owner is the current member of the group i.e., her/his identity commitment key `pk` is part of the membership group Merkle tree with the root `merkle_root`. 2. `share_x` and `share_y` are correctly computed. 3. The `nullifier` is constructed correctly. -For more details about the proof generation check [RLN](../../../../vac/32/rln-v1.md) +For more details about the proof generation check [RLN](../../../../vac/32/rln-v1) The proof generation relies on the knowledge of two pieces of private information i.e., `sk` and `authPath`. The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. @@ -122,7 +121,7 @@ The reason is that using an old root can allow inference about the index of the ### Routing -Upon the receipt of a PubSub message via [`11/WAKU2-RELAY`](../11/relay.md) protocol, the routing peer parses the `data` field as a `WakuMessage` and gets access to the `RateLimitProof` field. +Upon the receipt of a PubSub message via [`11/WAKU2-RELAY`](../11/relay) protocol, the routing peer parses the `data` field as a `WakuMessage` and gets access to the `RateLimitProof` field. The peer then validates the `RateLimitProof` as explained next. #### Epoch Validation @@ -146,7 +145,7 @@ See [Recommended System Parameters](#recommended-system-parameters) on choosing #### Proof Verification The routing peers MUST check whether the zero-knowledge proof `proof` is valid. -It does so by running the zk verification algorithm as explained in [RLN](../../../../vac/32/rln-v1.md). +It does so by running the zk verification algorithm as explained in [RLN](../../../../vac/32/rln-v1). If `proof` is invalid then the message is discarded. #### Spam detection @@ -162,17 +161,17 @@ An overview of the routing procedure and slashing is provided in Figure 2. - + -![Figure 2: Publishing, Routing and Slashing workflow.](./17/images/rln-message-verification.png) +![Figure 2: Publishing, Routing and Slashing workflow.](./images/rln-message-verification.png) ------- ## Payloads Payloads are protobuf messages implemented using [protocol buffers v3](https://developers.google.com/protocol-buffers/). -Nodes MAY extend the [14/WAKU2-MESSAGE](../14/message.md) with a `rate_limit_proof` field to indicate that their message is not spam. +Nodes MAY extend the [14/WAKU2-MESSAGE](../14/message) with a `rate_limit_proof` field to indicate that their message is not spam. ```diff @@ -208,10 +207,10 @@ Below is the description of the fields of `RateLimitProof` and their types. | ----: | ----------- | ----------- | | `proof` | array of 256 bytes | the zkSNARK proof as explained in the [Publishing process](##Publishing) | | `merkle_root` | array of 32 bytes in little-endian order | the root of membership group Merkle tree at the time of publishing the message | -| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md) | +| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](../../../../vac/32/rln-v1) | -| `nullifier` | array of 32 bytes | internal nullifier derived from `epoch` and peer's `sk` as explained in [RLN construct](../../../../vac/32/rln-v1.md)| +| `nullifier` | array of 32 bytes | internal nullifier derived from `epoch` and peer's `sk` as explained in [RLN construct](../../../../vac/32/rln-v1)| ## Recommended System Parameters diff --git a/waku/standards/core/lightpush.md b/waku/standards/core/19/lightpush.md similarity index 86% rename from waku/standards/core/lightpush.md rename to waku/standards/core/19/lightpush.md index 772eb9fb8..a85e7b5ac 100644 --- a/waku/standards/core/lightpush.md +++ b/waku/standards/core/19/lightpush.md @@ -6,7 +6,6 @@ editor: Hanno Cornelius \ contributors: - Daniel Kaiser \ - Oskar Thorén \ -sidebar_position: 19 --- - Status: draft - Editor: Hanno Cornelius \ @@ -50,14 +49,14 @@ message PushRPC { ### Message Relaying Nodes that respond to `PushRequests` MUST either -relay the encapsulated message via [11/WAKU2-RELAY](../11/relay.md) protocol on the specified `pubsub_topic`, -or forward the `PushRequest` via 19/LIGHTPUSH on a [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) stem. +relay the encapsulated message via [11/WAKU2-RELAY](../11/relay) protocol on the specified `pubsub_topic`, +or forward the `PushRequest` via 19/LIGHTPUSH on a [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion) stem. If they are unable to do so for some reason, they SHOULD return an error code in `PushResponse`. ## Security Considerations Since this can introduce an amplification factor, it is RECOMMENDED for the node relaying to the rest of the network to take extra precautions. -This can be done by rate limiting via [17/WAKU2-RLN-RELAY](../17/rln-relay.md). +This can be done by rate limiting via [17/WAKU2-RLN-RELAY](../17/rln-relay). Note that the above is currently not fully implemented. @@ -67,6 +66,6 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -* [11/WAKU2-RELAY](../11/relay.md) -* [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) -* [17/WAKU2-RLN-RELAY](../17/rln-relay.md) +* [11/WAKU2-RELAY](../11/relay) +* [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion) +* [17/WAKU2-RLN-RELAY](../17/rln-relay) diff --git a/waku/standards/core/discv5.md b/waku/standards/core/33/discv5.md similarity index 87% rename from waku/standards/core/discv5.md rename to waku/standards/core/33/discv5.md index 8517956ec..13eb102df 100644 --- a/waku/standards/core/discv5.md +++ b/waku/standards/core/33/discv5.md @@ -4,21 +4,20 @@ name: Waku v2 Discv5 Ambient Peer Discovery status: draft editor: Daniel Kaiser \ contributors: -sidebar_position: 33 --- - Status: draft - Editor: Daniel Kaiser \ ## Abstract -`33/WAKU2-DISCV5` specifies a modified version of [Ethereum's Node Discovery Protocol v5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) as a means for ambient node discovery. -[10/WAKU2](../10/waku2.md) uses the `33/WAKU2-DISCV5` ambient node discovery network for establishing a decentralized network of interconnected Waku2 nodes. +`33/WAKU2-DISCV5` specifies a modified version of [Ethereum's Node Discovery Protocol v5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5) as a means for ambient node discovery. +[10/WAKU2](../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. ## Disclaimer -This version of `33/WAKU2-DISCV5` has a focus on timely deployment of an efficient discovery method for [10/WAKU2](../10/waku2.md). +This version of `33/WAKU2-DISCV5` has a focus on timely deployment of an efficient discovery method for [10/WAKU2](../10/waku2). Establishing a separate discovery network is in line with this focus. However, we are aware of potential resilience problems (see section on security considerations) and are [discussing](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121/8) and researching hybrid approaches. @@ -26,16 +25,16 @@ and researching hybrid approaches. ## Background and Rationale -[11/WAKU2-RELAY](../11/relay.md) assumes the existence of a network of Waku2 nodes. +[11/WAKU2-RELAY](../11/relay) assumes the existence of a network of Waku2 nodes. For establishing and growing this network, new nodes trying to join the Waku2 network need a means of discovering nodes within the network. -[10/WAKU2](../10/waku2.md) supports the following discovery methods in order of increasing decentralization +[10/WAKU2](../10/waku2) supports the following discovery methods in order of increasing decentralization * hard coded bootstrap nodes * [`DNS discovery`](https://rfc.vac.dev/spec/10/#discovery-domain) (based on [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459)) * `peer-exchange` (work in progress) * `33/WAKU2-DISCV5` (specified in this document) -The purpose of ambient node discovery within [10/WAKU2](../10/waku2.md) is discovering Waku2 nodes in a decentralized way. +The purpose of ambient node discovery within [10/WAKU2](../10/waku2) is discovering Waku2 nodes in a decentralized way. The unique selling point of `33/WAKU2-DISCV5` is its holistic view of the network, which allows avoiding hotspots and allows merging the network after a split. While the other methods provide either a fixed or local set of nodes, `33/WAKU2-DISCV5` can provide a random sample of Waku2 nodes. Future iterations of this document will add the possibility of efficiently discovering Waku2 nodes that have certain capabilities, e.g. holding messages of a certain time frame during which the querying node was offline. @@ -44,7 +43,7 @@ Future iterations of this document will add the possibility of efficiently disco #### w.r.t. Waku2 Relay Network -`33/WAKU2-DISCV5` spans an overlay network separate from the [GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) network [11/WAKU2-RELAY](../11/relay.md) builds on. +`33/WAKU2-DISCV5` spans an overlay network separate from the [GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README) network [11/WAKU2-RELAY](../11/relay) builds on. Because it is a P2P network on its own, it also depends on bootstrap nodes. Having a separate discovery network reduces load on the bootstrap nodes, because the actual work is done by randomly discovered nodes. This also increases decentralization. @@ -54,7 +53,7 @@ This also increases decentralization. `33/WAKU2-DISCV5` spans a discovery network isolated from the Ethereum Discovery v5 network. -Another simple solution would be taking part in the Ethereum Discovery network, and filtering Waku nodes based on whether they support [WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md). +Another simple solution would be taking part in the Ethereum Discovery network, and filtering Waku nodes based on whether they support [WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr). This solution is more resilient towards eclipse attacks. However, this discovery method is very inefficient for small percentages of Waku nodes (see [estimation](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121/8)). It boils down to random walk discovery and does not offer a O(log(n)) hop bound. @@ -62,7 +61,7 @@ The rarer the requested property (in this case Waku), the longer a random walk w Using a dedicated Waku2 discovery network, nodes can query this discovery network for a random set of nodes and all (well-behaving) returned nodes can serve as bootstrap nodes for other Waku2 protocols. -A more sophisticated solution would be using [Discv5 topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement). +A more sophisticated solution would be using [Discv5 topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory##topic-advertisement). However, in its current state it also has efficiency problems for small percentages of Waku nodes and is still in the design phase ([see here](https://github.com/ethereum/devp2p/issues/199)). Currently, the Ethereum discv5 network is very efficient in finding other discv5 nodes, @@ -70,21 +69,21 @@ but it is not so efficient for finding discv5 nodes that have a specific propert As part of our [discv5 roadmap](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121), we consider two ideas for future versions of `33/WAKU2-DISCV5` -* [Discv5 topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement) with adjustments (ideally upstream) +* [Discv5 topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory##topic-advertisement) with adjustments (ideally upstream) * a hybrid solution that uses both a separate discv5 network and a Waku-ENR-filtered Ethereum discv5 network ## Semantics -`33/WAKU2-DISCV5` fully inherits the [discv5 semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md). +`33/WAKU2-DISCV5` fully inherits the [discv5 semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory). Before announcing their address via Waku2 discv5, nodes SHOULD check if this address is publicly reachable. -Nodes MAY use the [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md) to perform that check. +Nodes MAY use the [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README) to perform that check. Nodes SHOULD only announce publicly reachable addresses via Waku2 discv5, to avoid cluttering peer lists with nodes that are not reachable. ## Wire Format Specification -`33/WAKU2-DISCV5` inherits the [discv5 wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) except for the following differences +`33/WAKU2-DISCV5` inherits the [discv5 wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire) except for the following differences ## WAKU2-Specific `protocol-id` @@ -157,17 +156,17 @@ Properly protecting against eclipse attacks is challenging and raises research q ## References -1. [10/WAKU2](../10/waku2.md) -1. [11/WAKU2-RELAY](../11/relay.md) -1. [`WAKU2-ENR`](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md) -1. [Node Discovery Protocol v5 (`discv5`)](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) -1. [`discv5` semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md). -1. [`discv5` wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) -1. [`discv5` topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement) +1. [10/WAKU2](../10/waku2) +1. [11/WAKU2-RELAY](../11/relay) +1. [`WAKU2-ENR`](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr) +1. [Node Discovery Protocol v5 (`discv5`)](https://github.com/ethereum/devp2p/blob/master/discv5/discv5) +1. [`discv5` semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory). +1. [`discv5` wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire) +1. [`discv5` topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory##topic-advertisement) 1. [Waku DNS discovery](https://rfc.vac.dev/spec/10/#discovery-domain) -1. [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md) +1. [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README) 1. [`EIP-1459`](https://eips.ethereum.org/EIPS/eip-1459) -1. [`GossipSub`](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) +1. [`GossipSub`](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README) 1. [Waku discv5 roadmap discussion](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121) 1. [discovery efficiency estimation](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121/8) 1. [implementation: Nim](https://github.com/kaiserd/nim-eth/blob/add-selectable-protocol-id-static/eth/p2p/discoveryv5/encoding.nim) diff --git a/waku/standards/core/bindings-api.md b/waku/standards/core/36/bindings-api.md similarity index 98% rename from waku/standards/core/bindings-api.md rename to waku/standards/core/36/bindings-api.md index ddd66c0ea..76b84347b 100644 --- a/waku/standards/core/bindings-api.md +++ b/waku/standards/core/36/bindings-api.md @@ -5,7 +5,6 @@ status: draft editor: Richard Ramos \ contributors: - Franck Royer \ -sidebar_position: 36 --- - Status: draft - Editor: Richard Ramos \ @@ -700,7 +699,7 @@ This list has this format: ### `extern int waku_content_topic(char* applicationName, unsigned int applicationVersion, char* contentTopicName, char* encoding, WakuCallBack onOkCb)` -Create a content topic string according to [RFC 23](../../../informational/23/topics.md). +Create a content topic string according to [RFC 23](../../../informational/23/topics). **Parameters** @@ -713,14 +712,14 @@ Create a content topic string according to [RFC 23](../../../informational/23/to **Returns** `int` with a status code. Possible values: - - 0 - The operation was completed successfuly. `onOkCb` will receive the content topic formatted according to [RFC 23](../../../informational/23/topics.md): `/{application-name}/{version-of-the-application}/{content-topic-name}/{encoding}` + - 0 - The operation was completed successfuly. `onOkCb` will receive the content topic formatted according to [RFC 23](../../../informational/23/topics): `/{application-name}/{version-of-the-application}/{content-topic-name}/{encoding}` - 1 - The operation failed for any reason. - 2 - The function is missing the `onOkCb` callback ### `extern int waku_pubsub_topic(char* name, char* encoding, WakuCallBack onOkCb)` -Create a pubsub topic string according to [RFC 23](../../../informational/23/topics.md). +Create a pubsub topic string according to [RFC 23](../../../informational/23/topics). **Parameters** @@ -731,13 +730,13 @@ Create a pubsub topic string according to [RFC 23](../../../informational/23/top **Returns** `int` with a status code. Possible values: - - 0 - The operation was completed successfuly. `onOkCb` will get populated with a pubsub topic formatted according to [RFC 23](../../../informational/23/topics.md): `/waku/2/{topic-name}/{encoding}` + - 0 - The operation was completed successfuly. `onOkCb` will get populated with a pubsub topic formatted according to [RFC 23](../../../informational/23/topics): `/waku/2/{topic-name}/{encoding}` - 1 - The operation failed for any reason. - 2 - The function is missing the `onOkCb` callback ### `extern int waku_default_pubsub_topic(WakuCallBack onOkCb)` -Returns the default pubsub topic used for exchanging waku messages defined in [RFC 10](../10/waku2.md). +Returns the default pubsub topic used for exchanging waku messages defined in [RFC 10](../10/waku2). **Parameters** 1. `WakuCallBack onOkCb`: callback to be executed if the function is succesful @@ -755,7 +754,7 @@ Publish a message using Waku Relay. **Parameters** -1. `char* messageJson`: JSON string containing the [Waku Message](../14/message.md) as [`JsonMessage`](#jsonmessage-type). +1. `char* messageJson`: JSON string containing the [Waku Message](../14/message) as [`JsonMessage`](#jsonmessage-type). 2. `char* pubsubTopic`: pubsub topic on which to publish the message. If `NULL`, it uses the default pubsub topic. 3. `int timeoutMs`: Timeout value in milliseconds to execute the call. @@ -1016,7 +1015,7 @@ Sends a requests to a service node (or all service nodes) to stop pushing messag ### `extern int waku_legacy_filter_subscribe(char* filterJSON, char* peerID, int timeoutMs, WakuCallBack onErrCb)` -Creates a subscription in a lightnode for messages that matches a content filter and optionally a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). +Creates a subscription in a lightnode for messages that matches a content filter and optionally a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor). **Parameters** @@ -1066,7 +1065,7 @@ For Example: ### `extern int waku_legacy_filter_unsubscribe(char* filterJSON, int timeoutMs, WakuCallBack onErrCb)` -Removes subscriptions in a light node matching a content filter and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). +Removes subscriptions in a light node matching a content filter and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor). **Parameters** @@ -1092,7 +1091,7 @@ Publish a message using Waku Lightpush. **Parameters** -1. `char* messageJson`: JSON string containing the [Waku Message](../14/message.md) as [`JsonMessage`](#jsonmessage-type). +1. `char* messageJson`: JSON string containing the [Waku Message](../14/message) as [`JsonMessage`](#jsonmessage-type). 2. `char* pubsubTopic`: pubsub topic on which to publish the message. If `NULL`, it uses the default pubsub topic. 3. `char* peerID`: Peer ID supporting the lightpush protocol. @@ -1180,7 +1179,7 @@ Encrypt a message using symmetric encryption and optionally sign the message **Parameters** -1. `char* messageJson`: JSON string containing the [Waku Message](../14/message.md) as [`JsonMessage`](#jsonmessage-type). +1. `char* messageJson`: JSON string containing the [Waku Message](../14/message) as [`JsonMessage`](#jsonmessage-type). 2. `char* symmetricKey`: hex encoded secret key to be used for encryption. 3. `char* optionalSigningKey`: hex encoded private key to be used to sign the message. 4. `WakuCallBack onOkCb`: callback to be executed if the function is succesful @@ -1201,7 +1200,7 @@ Encrypt a message using asymmetric encryption and optionally sign the message **Parameters** -1. `char* messageJson`: JSON string containing the [Waku Message](../14/message.md) as [`JsonMessage`](#jsonmessage-type). +1. `char* messageJson`: JSON string containing the [Waku Message](../14/message) as [`JsonMessage`](#jsonmessage-type). 2. `char* publicKey`: hex encoded public key to be used for encryption. 3. `char* optionalSigningKey`: hex encoded private key to be used to sign the message. 4. `WakuCallBack onOkCb`: callback to be executed if the function is succesful @@ -1224,7 +1223,7 @@ Decrypt a message using a symmetric key **Parameters** -1. `char* messageJson`: JSON string containing the [Waku Message](../14/message.md) as [`JsonMessage`](#jsonmessage-type). +1. `char* messageJson`: JSON string containing the [Waku Message](../14/message) as [`JsonMessage`](#jsonmessage-type). 2. `char* symmetricKey`: 32 byte symmetric key hex encoded. 3. `WakuCallBack onOkCb`: callback to be executed if the function is succesful 4. `WakuCallBack onErrCb`: callback to be executed if the function fails @@ -1252,7 +1251,7 @@ Decrypt a message using a secp256k1 private key **Parameters** -1. `char* messageJson`: JSON string containing the [Waku Message](../14/message.md) as [`JsonMessage`](#jsonmessage-type). +1. `char* messageJson`: JSON string containing the [Waku Message](../14/message) as [`JsonMessage`](#jsonmessage-type). 2. `char* privateKey`: secp256k1 private key hex encoded. 3. `WakuCallBack onOkCb`: callback to be executed if the function is succesful 4. `WakuCallBack onErrCb`: callback to be executed if the function fails diff --git a/waku/standards/core/metadata.md b/waku/standards/core/66/metadata.md similarity index 93% rename from waku/standards/core/metadata.md rename to waku/standards/core/66/metadata.md index 5fcfcf62b..2959c014a 100644 --- a/waku/standards/core/metadata.md +++ b/waku/standards/core/66/metadata.md @@ -4,13 +4,12 @@ name: Waku Metadata Protocol status: draft editor: Alvaro Revuelta \ contributors: -sidebar_position: 66 --- - Status: draft - Editor: Alvaro Revuelta \ ## Abstract -This specification describes the metadata that can be associated with a [10/WAKU2](../10/waku2.md) node. +This specification describes the metadata that can be associated with a [10/WAKU2](../10/waku2) node. ## Metadata Protocol @@ -50,4 +49,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -- [10/WAKU2](../10/waku2.md) +- [10/WAKU2](../10/waku2) diff --git a/waku/standards/core/filter.md b/waku/standards/core/filter.md deleted file mode 100644 index ebfdf4e71..000000000 --- a/waku/standards/core/filter.md +++ /dev/null @@ -1,279 +0,0 @@ ---- -title: 12/WAKU2-FILTER -name: Waku v2 Filter -status: draft -version: 01 -editor: Hanno Cornelius \ -contributors: - - Dean Eigenmann \ - - Oskar Thorén \ - - Sanaz Taheri \ - - Ebube Ud \ -sidebar_position: 12 ---- -- Status: draft -- Editor: Hanno Cornelius \ -- Contributors:: - - Dean Eigenmann \ - - Oskar Thorén \ - - Sanaz Taheri \ - - Ebube Ud \ -- Contributors:: - - -previous versions: [00](./previous-versions00) - ---- - -`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](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering). -Currently the only content filter being applied is on `contentTopic`. This -corresponds to topics in Waku v1. - -## Rationale - -Unlike the `store` protocol for historical messages, this protocol allows for -native lower latency scenarios such as instant messaging. It is thus -complementary to it. - -Strictly speaking, it is not just doing basic request response, but performs -sender push based on receiver intent. While this can be seen as a form of light -pub/sub, it is only used between two nodes in a direct fashion. Unlike the -Gossip domain, this is meant for light nodes which put a premium on bandwidth. -No gossiping takes place. - -It is worth noting that a light node could get by with only using the `store` -protocol to query for a recent time window, provided it is acceptable to do -frequent polling. - - -## Design Requirements - -The effectiveness and reliability of the content filtering service enabled by `WakuFilter` protocol rely on the *high availability* of the full nodes as the service providers. To this end, full nodes must feature *high uptime* (to persistently listen and capture the network messages) as well as *high Bandwidth* (to provide timely message delivery to the light nodes). - -## Security Consideration - -Note that while using `WakuFilter` allows light nodes to save bandwidth, it comes with a privacy cost in the sense that they need to disclose their liking topics to the full nodes to retrieve the relevant messages. Currently, anonymous subscription is not supported by the `WakuFilter`, however, potential solutions in this regard are sketched below in [Future Work](#future-work) section. - -### Terminology -The term Personally identifiable information (PII) refers to any piece of data that can be used to uniquely identify a user. For example, the signature verification key, and the hash of one's static IP address are unique for each user and hence count as PII. - -## Adversarial Model -Any node running the `WakuFilter` protocol i.e., both the subscriber node and the queried node are considered as an adversary. Furthermore, we consider the adversary as a passive entity that attempts to collect information from other nodes to conduct an attack but it does so without violating protocol definitions and instructions. For example, under the passive adversarial model, no malicious node intentionally hides the messages matching to one's subscribed content filter as it is against the description of the `WakuFilter` protocol. - -The following are not considered as part of the adversarial model: - - An adversary with a global view of all the nodes and their connections. - - An adversary that can eavesdrop on communication links between arbitrary pairs of nodes (unless the adversary is one end of the communication). In specific, the communication channels are assumed to be secure. - -### Protobuf - -```protobuf -syntax = "proto3"; - -// 12/WAKU2-FILTER rfc: https://rfc.vac.dev/spec/12/ -package waku.filter.v2; - -// Protocol identifier: /vac/waku/filter-subscribe/2.0.0-beta1 -message FilterSubscribeRequest { - enum FilterSubscribeType { - SUBSCRIBER_PING = 0; - SUBSCRIBE = 1; - UNSUBSCRIBE = 2; - UNSUBSCRIBE_ALL = 3; - } - - string request_id = 1; - FilterSubscribeType filter_subscribe_type = 2; - - // Filter criteria - optional string pubsub_topic = 10; - repeated string content_topics = 11; -} - -message FilterSubscribeResponse { - string request_id = 1; - uint32 status_code = 10; - optional string status_desc = 11; -} - -// Protocol identifier: /vac/waku/filter-push/2.0.0-beta1 -message MessagePush { - WakuMessage waku_message = 1; - optional string pubsub_topic = 2; -} -``` - -### Filter-Subscribe - -A filter service node MUST support the _filter-subscribe_ protocol -to allow filter clients to subscribe, modify, refresh and unsubscribe a desired set of filter criteria. -The combination of different filter criteria for a specific filter client node is termed a "subscription". -A filter client is interested in receiving messages matching the filter criteria in its registered subscriptions. - -Since a filter service node is consuming resources to provide this service, -it MAY account for usage and adapt its service provision to certain clients. -An incentive mechanism is currently planned but underspecified. - -#### Filter Subscribe Request - -A client node MUST send all filter requests in a `FilterSubscribeRequest` message. -This request MUST contain a `request_id`. -The `request_id` MUST be a uniquely generated string. -Each request MUST include a `filter_subscribe_type`, indicating the type of request. - -#### Filter Subscribe Response - -In return to any `FilterSubscribeRequest`, -a filter service node SHOULD respond with a `FilterSubscribeResponse` with a `requestId` matching that of the request. -This response MUST contain a `status_code` indicating if the request was successful or not. -Successful status codes are in the `2xx` range. -Client nodes SHOULD consider all other status codes as error codes and assume that the requested operation had failed. -In addition, the filter service node MAY choose to provide a more detailed status description in the `status_desc` field. - -#### Filter matching - -In the description of each request type below, -the term "filter criteria" refers to the combination of `pubsub_topic` and a set of `content_topics`. -The request MAY include filter criteria, conditional to the selected `filter_subscribe_type`. -If the request contains filter criteria, -it MUST contain a `pubsub_topic` -and the `content_topics` set MUST NOT be empty. -A `WakuMessage` matches filter criteria when its `content_topic` is in the `content_topics` set -and it was published on a matching `pubsub_topic`. - -#### Filter Subscribe Types - -The following filter subscribe types are defined: - -##### SUBSCRIBER_PING - -A filter client that sends a `FilterSubscribeRequest` with `filter_subscribe_type` set to `SUBSCRIBER_PING` -requests that the service node SHOULD indicate if it has any active subscriptions for this client. -The filter client SHOULD exclude any filter criteria from the request. -The filter service node SHOULD respond with a success code if it has any active subscriptions for this client -or an error code if not. -The filter service node SHOULD ignore any filter criteria in the request. - -##### SUBSCRIBE - -A filter client that sends a `FilterSubscribeRequest` with `filter_subscribe_type` set to `SUBSCRIBE` -requests that the service node SHOULD push messages matching this filter to the client. -The filter client MUST include the desired filter criteria in the request. -A client MAY use this request type to _modify_ an existing subscription -by providing _additional_ filter criteria in a new request. -A client MAY use this request type to _refresh_ an existing subscription -by providing _the same_ filter criteria in a new request. -The filter service node SHOULD respond with a success code if it successfully honored this request -or an error code if not. -The filter service node SHOULD respond with an error code and discard the request -if the subscribe request does not contain valid filter criteria, -i.e. both a `pubsub_topic` _and_ a non-empty `content_topics` set. - -##### UNSUBSCRIBE - -A filter client that sends a `FilterSubscribeRequest` with `filter_subscribe_type` set to `UNSUBSCRIBE` -requests that the service node SHOULD _stop_ pushing messages matching this filter to the client. -The filter client MUST include the filter criteria it desires to unsubscribe from in the request. -A client MAY use this request type to _modify_ an existing subscription -by providing _a subset of_ the original filter criteria to unsubscribe from in a new request. -The filter service node SHOULD respond with a success code if it successfully honored this request -or an error code if not. -The filter service node SHOULD respond with an error code and discard the request -if the unsubscribe request does not contain valid filter criteria, -i.e. both a `pubsub_topic` _and_ a non-empty `content_topics` set. - -##### UNSUBSCRIBE_ALL - -A filter client that sends a `FilterSubscribeRequest` with `filter_subscribe_type` set to `UNSUBSCRIBE_ALL` -requests that the service node SHOULD _stop_ pushing messages matching _any_ filter to the client. -The filter client SHOULD exclude any filter criteria from the request. -The filter service node SHOULD remove any existing subscriptions for this client. -It SHOULD respond with a success code if it successfully honored this request -or an error code if not. - -### Filter-Push - -A filter client node MUST support the _filter-push_ protocol -to allow filter service nodes to push messages matching registered subscriptions to this client. - -A filter service node SHOULD push all messages -matching the filter criteria in a registered subscription -to the subscribed filter client. -These [`WakuMessage`s](../14/message.md) are likely to come from [`11/WAKU2-RELAY`](../11/relay.md), -but there MAY be other sources or protocols where this comes from. -This is up to the consumer of the protocol. - -If a message push fails, -the filter service node MAY consider the client node to be unreachable. -If a specific filter client node is not reachable from the service node for a period of time, -the filter service node MAY choose to stop pushing messages to the client and remove its subscription. -This period is up to the service node implementation. -We consider `1 minute` to be a reasonable default. - -#### Message Push - -Each message MUST be pushed in a `MessagePush` message. -Each `MessagePush` MUST contain one (and only one) `waku_message`. -If this message was received on a specific `pubsub_topic`, -it SHOULD be included in the `MessagePush`. -A filter client SHOULD NOT respond to a `MessagePush`. -Since the filter protocol does not include caching or fault-tolerance, -this is a best effort push service with no bundling -or guaranteed retransmission of messages. -A filter client SHOULD verify that each `MessagePush` it receives -originated from a service node where the client has an active subscription -and that it matches filter criteria belonging to that subscription. - ---- -## Future Work - - - -**Anonymous filter subscription**: This feature guarantees that nodes can anonymously subscribe for a message filter (i.e., without revealing their exact content filter). As such, no adversary in the `WakuFilter` protocol would be able to link nodes to their subscribed content filers. The current version of the `WakuFilter` protocol does not provide anonymity as the subscribing node has a direct connection to the full node and explicitly submits its content filter to be notified about the matching messages. However, one can consider preserving anonymity through one of the following ways: -- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor - -. - Note that the current structure of filter requests i.e., `FilterRPC` does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve anonymity. -- By deploying secure 2-party computations in which the subscribing node obtains the messages matching a content filter whereas the full node learns nothing about the content filter as well as the messages pushed to the subscribing node. Examples of such 2PC protocols are [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains.) and one-way Private Set Intersections (PSI). - -## Changelog - -### Next - -- Added initial threat model and security analysis. - -### 2.0.0-beta2 - -Initial draft version. Released [2020-10-28](https://github.com/vacp2p/specs/commit/5ceeb88cee7b918bb58f38e7c4de5d581ff31e68) -- Fix: Ensure contentFilter is a repeated field, on implementation -- Change: Add ability to unsubscribe from filters. Make `subscribe` an explicit boolean indication. Edit protobuf field order to be consistent with libp2p. - -### 2.0.0-beta1 - -Initial draft version. Released [2020-10-05](https://github.com/vacp2p/specs/commit/31857c7434fa17efc00e3cd648d90448797d107b) - -## Copyright - -Copyright and related rights waived via -[CC0](https://creativecommons.org/publicdomain/zero/1.0/). - -## References - -- [message-based -filtering](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering) -- [`WakuMessage`s](../14/message.md) -- [`11/WAKU2-RELAY`](../11/relay.md) -- [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains) -- previous versions: [00](./previous-versions00) - -1. [Message Filtering (Wikipedia)](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering) - -2. [Libp2p PubSub spec - topic validation](https://github.com/libp2p/specs/tree/master/pubsub#topic-validation) diff --git a/waku/standards/legacy/waku1.md b/waku/standards/legacy/6/waku1.md similarity index 98% rename from waku/standards/legacy/waku1.md rename to waku/standards/legacy/6/waku1.md index d9b888bc4..e8e137c2c 100644 --- a/waku/standards/legacy/waku1.md +++ b/waku/standards/legacy/6/waku1.md @@ -8,7 +8,6 @@ contributors: - Andrea Maria Piana \ - Dean Eigenmann \ - Kim De Mey \ -sidebar_position: 6 --- - Status: stable - Editor: Oskar Thorén \ @@ -43,7 +42,7 @@ This protocol needs to advertise the `waku/1` [capability](https://ethereum.gitb ### Gossip based routing -In Whisper, envelopes are gossiped between peers. Whisper is a form of rumor-mongering protocol that works by flooding to its connected peers based on some factors. Envelopes are eligible for retransmission until their TTL expires. A node SHOULD relay envelopes to all connected nodes if an envelope matches their PoW and bloom filter settings. If a node works in light mode, it MAY choose not to forward envelopes. A node MUST NOT send expired envelopes, unless the envelopes are sent as a [8/WAKU-MAIL](../8/mail.md) response. A node SHOULD NOT send an envelope to a peer that it has already sent before. +In Whisper, envelopes are gossiped between peers. Whisper is a form of rumor-mongering protocol that works by flooding to its connected peers based on some factors. Envelopes are eligible for retransmission until their TTL expires. A node SHOULD relay envelopes to all connected nodes if an envelope matches their PoW and bloom filter settings. If a node works in light mode, it MAY choose not to forward envelopes. A node MUST NOT send expired envelopes, unless the envelopes are sent as a [8/WAKU-MAIL](../8/mail) response. A node SHOULD NOT send an envelope to a peer that it has already sent before. ### Maximum Packet Size @@ -350,7 +349,7 @@ The drawback of sending message confirmations is that it increases the noise in #### P2P Request -This packet is used for sending Dapp-level peer-to-peer requests, e.g. Waku Mail Client requesting historic (expired) envelopes from the [Waku Mail Server](../8/mail.md). +This packet is used for sending Dapp-level peer-to-peer requests, e.g. Waku Mail Client requesting historic (expired) envelopes from the [Waku Mail Server](../8/mail). #### P2P Message @@ -360,7 +359,7 @@ This packet is used for sending the peer-to-peer envelopes, which are not suppos This packet is used to indicate that all envelopes, requested earlier with a P2P Request packet (`0x7E`), have been sent via one or more P2P Message packets (`0x7F`). -The content of the packet is explained in the [Waku Mail Server](../8/mail.md) specification. +The content of the packet is explained in the [Waku Mail Server](../8/mail) specification. ### Payload Encryption @@ -380,7 +379,7 @@ Packet codes `0x7E` and `0x7F` may be used to implement Waku Mail Server and Cli Waku supports multiple capabilities. These include light node, rate limiting and bridging of traffic. Here we list these capabilities, how they are identified, what properties they have and what invariants they must maintain. -Additionally there is the capability of a mailserver which is documented in its on [specification](../8/mail.md). +Additionally there is the capability of a mailserver which is documented in its on [specification](../8/mail). ### Light node @@ -459,7 +458,7 @@ It is desirable to have a strategy for maintaining forward compatibility between ## Appendix A: Security considerations -There are several security considerations to take into account when running Waku. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used. The security considerations for extra capabilities such as [mailservers](../8/mail.md#security-considerations) can be found in their respective specifications. +There are several security considerations to take into account when running Waku. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used. The security considerations for extra capabilities such as [mailservers](../8/mail##security-considerations) can be found in their respective specifications. ### Scalability and UX @@ -519,8 +518,8 @@ By default Devp2p runs on port `30303`, which is not commonly used for any other | Client | Spec supported | Details | |--------|----------------|---------| -| **Status-go** | 0.5 | [details](https://github.com/status-im/status-go/blob/develop/WAKU.md) | -| **Nim-waku** | 1.0 | [details](https://github.com/status-im/nim-waku/blob/master/README.md) | +| **Status-go** | 0.5 | [details](https://github.com/status-im/status-go/blob/develop/WAKU) | +| **Nim-waku** | 1.0 | [details](https://github.com/status-im/nim-waku/blob/master/README) | ### Recommendations for clients @@ -600,7 +599,7 @@ Released [February 13, 2020](https://github.com/vacp2p/specs/commit/73138d6ba954 ### Version 0.2 -Released [December 10, 2019](https://github.com/vacp2p/specs/blob/waku-0.2.0/waku.md). +Released [December 10, 2019](https://github.com/vacp2p/specs/blob/waku-0.2.0/waku). - General style improvements. - Fix ABNF grammar. @@ -618,7 +617,7 @@ Released [December 10, 2019](https://github.com/vacp2p/specs/blob/waku-0.2.0/wak ### Version 0.1 -Initial version. Released [November 21, 2019](https://github.com/vacp2p/specs/blob/b59b9247f2ac1bf45c75bd3227a2e5dd87b6d7b0/waku.md). +Initial version. Released [November 21, 2019](https://github.com/vacp2p/specs/blob/b59b9247f2ac1bf45c75bd3227a2e5dd87b6d7b0/waku). ### Differences between shh/6 and waku/1 @@ -639,4 +638,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## Footnotes -[^1]: Felix Lange et al. [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md). Ethereum. +[^1]: Felix Lange et al. [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx). Ethereum. diff --git a/waku/standards/legacy/data.md b/waku/standards/legacy/7/data.md similarity index 95% rename from waku/standards/legacy/data.md rename to waku/standards/legacy/7/data.md index 6eafeb22c..7b71b48fb 100644 --- a/waku/standards/legacy/data.md +++ b/waku/standards/legacy/7/data.md @@ -6,7 +6,6 @@ editor: Oskar Thorén \ contributors: - Dean Eigenmann \ - Kim De Mey \ -sidebar_position: 7 --- - Status: stable - Editor: Oskar Thorén \ @@ -14,7 +13,7 @@ sidebar_position: 7 - Dean Eigenmann \ - Kim De Mey \ -This specification describes the encryption, decryption and signing of the content in the [data field used in Waku](../6/waku1.md/#abnf-specification). +This specification describes the encryption, decryption and signing of the content in the [data field used in Waku](../6/waku1#abnf-specification). ## Specification diff --git a/waku/standards/legacy/mail.md b/waku/standards/legacy/8/mail.md similarity index 98% rename from waku/standards/legacy/mail.md rename to waku/standards/legacy/8/mail.md index 90822cbc1..cde591d9d 100644 --- a/waku/standards/legacy/mail.md +++ b/waku/standards/legacy/8/mail.md @@ -7,7 +7,6 @@ contributors: - Adam Babik \ - Dean Eigenmann \ - Oskar Thorén \ -sidebar_position: 8 --- - Status: stable - Editor: Andrea Maria Piana \ @@ -106,7 +105,7 @@ A mailserver client fetches archival envelopes from a mailserver through a direc In this direct connection, the client discloses its IP/ID as well as the topics/ bloom filter it is interested in to the mailserver. The collection of such information allows the mailserver to link clients' IP/IDs to their topic interests and build a profile for each client over time. As such, the mailserver client has to trust the mailserver with this level of information. -A similar concern exists for the light nodes and their direct peers which is discussed in the security considerations of [6/WAKU1](../6/waku1.md). +A similar concern exists for the light nodes and their direct peers which is discussed in the security considerations of [6/WAKU1](../6/waku1). **Mailserver trusted connection:** @@ -118,7 +117,7 @@ A mailserver has a direct TCP connection, which means they are trusted to send t | :--------------------------------------------------------------------------------------------: | ------- | | [1.0.0](https://github.com/vacp2p/specs/commit/bc7e75ebb2e45d2cbf6ab27352c113e666df37c8) | marked stable as it is in use. | | 0.2.0 | Add topic interest to reduce bandwidth usage | -| [0.1.0](https://github.com/vacp2p/specs/blob/06d4c736c920526472a507e5d842212843a112ed/wms.md) | Initial Release | +| [0.1.0](https://github.com/vacp2p/specs/blob/06d4c736c920526472a507e5d842212843a112ed/wms) | Initial Release | ### Difference between wms 0.1 and wms 0.2 diff --git a/waku/standards/legacy/rpc.md b/waku/standards/legacy/9/rpc.md similarity index 99% rename from waku/standards/legacy/rpc.md rename to waku/standards/legacy/9/rpc.md index 93e2d712b..353cbaf9c 100644 --- a/waku/standards/legacy/rpc.md +++ b/waku/standards/legacy/9/rpc.md @@ -6,7 +6,6 @@ editor: Andrea Maria Piana \ contributors: - Dean Eigenmann \ - Oskar Thorén \ -sidebar_position: 9 --- - Status: stable - Editor: Andrea Maria Piana \ @@ -51,7 +50,7 @@ In this section you will find objects used throughout the JSON RPC API. #### Message -The message object represents a Waku message. Below you will find the description of the attributes contained in the message object. A message is the decrypted payload and padding of an [envelope](../7/data.md) along with all of its metadata and other extra information such as the hash. +The message object represents a Waku message. Below you will find the description of the attributes contained in the message object. A message is the decrypted payload and padding of an [envelope](../7/data) along with all of its metadata and other extra information such as the hash. | Field | Type | Description | | ----: | :--: | ----------- |