Update and rename decentralized-messaging-ethereum.md to decentralized-messaging-ethereum.md

Fix the current markdown-linting errors.

.github/workflows/.gitignore

@@ -0,0 +1 @@
+.DS_Store

.github/workflows/.markdownlint.json

@@ -1,6 +1,4 @@
 {
-        "MD013": {
-                "tables": false,
-                "code_blocks" : false
-        }
+        "MD013": false,
+        "MD024": false
 }

nomos/deprecated/claro.md

@@ -1,17 +1,17 @@
 ---
-slug: 38
-title: 38/CONSENSUS-CLARO
+title: CONSENSUS-CLARO
 name: Claro Consensus Protocol
-status: raw
+status: deprecated
 category: Standards Track
-tags: logos/consensus
+tags:
+  - logos/consensus
 editor: Corey Petty <corey@status.im>
 created: 01-JUL-2022
 revised: <2022-08-26 Fri 13:11Z>
 uri: <https://rdf.logos.co/protocol/Claro/1/0/0#<2022-08-26%20Fri$2013:11Z>
 contributors:
-    - Álvaro Castro-Castilla 
-    - Mark Evenson
+  - Álvaro Castro-Castilla
+  - Mark Evenson
 ---
 
 ## Abstract

status/56/communities.md

@@ -9,6 +9,7 @@ description: Status Communities allow multiple users to communicate in a discuss
 editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 - Andrea Piana <andreap@status.im>
+- Prem Chaitanya Prathi <prem@waku.org>
 ---
 
 ## Abstract
@@ -306,10 +307,45 @@ message CommunityDescription {
 
 Note: The usage of the clock is described in the [Clock](#clock) section.
 
+### Functional scope and shard assignment
+
+We define two special [functional scopes](../raw/status-app-protocols.md#functional-scope) for messages related to Status Communities:
+
+1. Global community control
+2. Global community content
+
+All messages that relate to controlling communities MUST be assigned the _global community control_ scope.
+All messages that carry user-generated content for communities MUST be assigned the _global community content_ scope.
+
+> **Note:** a previous iteration of Status Communities defined separate community-wide scopes for each community.
+However, this model was deprecated and all communities now operate on a global, shared scope.
+This implies that different communities will share shards on the routing layer.
+
+The following [Waku transport layer](../raw/status-app-protocols.md#waku-transport-layer) allocations are reserved for communities:
+As per [STATUS-SIMPLE-SCALING](https://rfc.vac.dev/status/raw/simple-scaling/#relay-shards), communities use the default cluster ID `16`
+set aside for all Status app protocols.
+Within this cluster, the following [shards](../raw/status-app-protocols.md#pubsub-topics-and-sharding) are reserved for the community functional scopes:
+
+1. All messages with a _global community control_ scope MUST be published to shard `128`
+2. All messages with a _global community content_ scope MUST be published to shard `256`
+
+### Content topic level encryption
+
+-a universal chat identifier is used for all community chats.
+<!-- Don't enforce any constraints on the unique id generation -->
+
+All messages are encrypted before they are handed over to waku ir-respective of the encryption explained above.
+All community chats are encrypted using a symmetric key generated from universal chat id using pbkdf2.
+
+```js
+symKey = pbkdf2(password:universalChatID, salt:nil, iteration-count:65356,key-length:32, hash-func: random-sha256)
+```
+
 ### 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).
+The content-topic usage follows the guidelines specified at [23/topics](../../waku/informational/23/topics.md#content-topic-usage-guidelines)
 
 #### Advertising a Community
 
@@ -334,32 +370,9 @@ for i = 0; i < topicLen; i++ {
 contentTopic = "/waku/1/0x" + topic + "/rfc26"
 ```
 
-#### Community channels/chats
-
-The unique identifier for a community channel/chat is the chat id.
-<!-- Don't enforce any constraints on the unique id generation -->
-The content topic, that Community channels/chats uses,
-MUST be the hex-encoded keccak-256 hash of the public key of the community
-concatenated with the chat id.
-
-```js
-hash = hex(keccak256(encodeToHex(compressedPublicKey + chatId)))
-
-topicLen = 4
-if len(hash) < topicLen {
-    topicLen = len(hash)
-}
-var topic [4]byte
-for i = 0; i < topicLen; i++ {
-    topic[i] = hash[i]
-}
-
-contentTopic = "/waku/1/0x" + topic + "/rfc26"
-```
-
 #### Community event messages
 
-Requests to leave, join, kick and ban, as well as key exchange messages,
+Message such as community description
 MUST be sent to the content topic derived from the public key of the community.
 The content topic
 MUST be the hex-encoded keccak-256 hash of the public key of the community.
@@ -379,6 +392,53 @@ for i = 0; i < topicLen; i++ {
 contentTopic = "/waku/1/0x" + topic + "/rfc26"
 ```
 
+#### Community Requests
+
+Requests to leave, join, kick and ban, as well as key exchange messages, MUST be sent to the content topic derived from the public key of the community on the common shard.
+
+The content topic
+MUST be the keccak-256 hash of hex-encoded universal chat id (public key appended with fixed string) of the community omitting the first 2 bytes.
+
+```js
+universalChatId = publicKey+"-memberUpdate"
+hash = hex(keccak256(encodeToHex(universalChatId))[2:])
+
+topicLen = 4
+if len(hash) < topicLen {
+    topicLen = len(hash)
+}
+var topic [4]byte
+for i = 0; i < topicLen; i++ {
+    topic[i] = hash[i]
+}
+
+contentTopic = "/waku/1/0x" + topic + "/rfc26"
+```
+
+#### Community Shard Info
+
+If a community is assigned a dedicated shard then the shard info for that community is published on a content topic derived from a specialized key. This is useful for users joining the new community so that they can subscribe to this specific content topic.
+
+```js
+chatID = publicKey+"-shard-info"
+hash = hex(keccak256(encodeToHex(chatID))[2:])
+
+topicLen = 4
+if len(hash) < topicLen {
+    topicLen = len(hash)
+}
+var topic [4]byte
+for i = 0; i < topicLen; i++ {
+    topic[i] = hash[i]
+}
+
+contentTopic = "/waku/1/0x" + topic + "/rfc26"
+```
+
+#### Community channels/chats
+
+All channels/chats shall use a single content-topic which is derived from a universal chat id irrespective of their individual unique chat ids.
+
 ### Community Management
 
 The flows for Community management are as described below.
@@ -391,8 +451,7 @@ according to the wire format "CommunityDescription".
 3. The Community owner publishes the Community metadata on a content topic
 derived from the public key of the Community.
 the Community metadata SHOULD be encrypted with the public key of the Community.
-<!-- TODO: Verify this-->
-The Community metadata MAY be sent during fixed intervals,
+The Community metadata is sent during fixed intervals,
 to ensure that the Community metadata is available to members.
 The Community metadata SHOULD be sent every time the Community metadata is updated.
 4. The Community owner MAY advertise the Community out of band,

status/raw/simple-scaling.md

@@ -63,14 +63,14 @@ efficient way will be part of a future document.
 Sharding the [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
 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)
+[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
 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/master/informational/relay-static-shard-alloc.md).
 
-[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)
+[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
 specifies three sharding methods.
 This document uses *static sharding*,
 which leaves the distribution of content topics to application protocols,
@@ -88,7 +88,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/master/standards/core/relay-sharding.md)).
 
 `/waku/2/rs/<cluster_id>/<shard_number>`
 
@@ -154,7 +154,7 @@ 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 [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md).
 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,
@@ -168,7 +168,7 @@ Status communities can be mapped to shards in two ways: static, and owner-based.
 
 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/master/informational/relay-static-shard-alloc.md).
 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).
@@ -310,7 +310,7 @@ 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)
+* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md)
 for discovering peers
 
 ## Waku Archive
@@ -333,7 +333,7 @@ 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/master/standards/core/relay-sharding.md).
 This allows the Status app to abstract from the discovery process and
 simply address shards by their index.
 
@@ -344,7 +344,7 @@ this document suggests using [libp2p rendezvous](https://github.com/libp2p/specs
 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).
 
-> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md),
+> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/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.
@@ -369,9 +369,9 @@ functionality offered by the libp2p circuit relay protocols, and
 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).
+MAY use rendezvous discovery instead of or along-side [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/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)
+[WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md)
 offer the same functionality,
 but return node sets sampled in different ways.
 Using both can help increasing connectivity.
@@ -401,7 +401,7 @@ The string conversion SHOULD remove leading zeros.
 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),
+see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md),
 the register query would look like
 
 ```rs
@@ -601,7 +601,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)
+See [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/master/informational/adversarial-models.md)
 for information on Waku Anonymity.
 
 ## Copyright
@@ -614,12 +614,12 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [55/STATUS-1TO1-CHAT](../55/1to1-chat.md)
 * [23/WAKU2-TOPICS](../../waku/informational/23/topics.md)
 * [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)
+* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
+* [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/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)
+* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/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)
@@ -629,9 +629,9 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [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)
 * [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/master/informational/adversarial-models.md)
 
 ## 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/master/standards/core/enr.md)

status/raw/status-app-protocols.md

@@ -58,8 +58,8 @@ Status currently defines functionality to support three main application feature
 Each application-level function, regardless which feature set it supports, has the following properties:
 
 1. Functional scope
-1. Content topic
-1. Ephemerality
+2. Content topic
+3. Ephemerality
 
 ### Functional Scope
 
@@ -74,10 +74,11 @@ However, since all users of the Status app MUST be able to participate in 1:1 ch
 the functional scope of messages enabling 1:1 chats MUST be a global scope.
 Similarly, since private group chats can be set up between any subset of Status app users,
 the functional scope for messages related to private group chats MUST be global.
-As a counter-example, messages that originate within a community (and are _addressed_ to members of that community)
-are only of interest to participants that are also members of that community.
-Such messages MUST have a community-wide functional scope.
-A third group of messages are addressed only to the participant that generated those messages itself.
+Along the same principle, messages that originate within communities are of global interest
+for all users who have an interest in the Status Communities feature.
+Such messages MUST have a global functional scope,
+that can be accessed by any app users interested in communities.
+A different group of messages are addressed only to the participant that generated those messages itself.
 These _self-addressed_ messages MUST have a local functional scope.
 
 If we further make a distinction between "control" and "content" messages,
@@ -85,25 +86,30 @@ we can distinguish five distinct functional scopes.
 
 All Status messages MUST have one of these functional scopes:
 
-#### Global scope
+#### Global general scope
 
-1. _Global control_: messages enabling the basic functioning of the app to control features that all app users should be able to participate in. Examples include Contact Requests, Community Invites, global Status Updates, Group Chat Invites, etc.
+1. _Global control_: messages enabling the basic functioning of the app to control general features that all app users should be able to participate in. Examples include Contact Requests, global Status Updates, Group Chat Invites, etc.
 2. _Global content_: messages carrying user-generated content for global functions. Examples include 1:1 chat messages, images shared over private group chats, etc.
 
-#### Community scope
+#### Global community scope
 
-3. _Community control_: messages enabling the basic functioning of the app to control features _only relevant to members of a specific community_. Examples include Community Membership Updates, community Status Updates, etc.
-4. _Community content_: messages carrying user-generated content _only for members of a specific community_.
+1. _Global community control_: messages enabling the basic functioning of the app to control features related to communities. Examples include Community Invites, Community Membership Updates, community Status Updates, etc.
+2. _Global community content_: messages carrying user-generated content for members of any community.
+
+> **Note:** a previous iteration of the Status Communities feature defined separate community-wide scopes for each community.
+However, this model was deprecated and all communities now operate on a global, shared scope.
+This implies that different communities will share shards on the routing layer.
 
 #### Local scope
 
-5. _Local_: messages related to functions that are only relevant to a single user. Also known as _self-addressed messages_. Examples include messages used to exchange information between app installations, such as User Backup and Sync messages.
+1. _Local_: messages related to functions that are only relevant to a single user. Also known as _self-addressed messages_. Examples include messages used to exchange information between app installations, such as User Backup and Sync messages.
 
 Note that the functional scope is a logical property of Status messages.
 It SHOULD however inform the underlying [transport layer sharding](#pubsub-topics-and-sharding) and [transport layer subscriptions](#subscribing).
 In general a Status client SHOULD subscribe to participate in:
-- all global functions,
-- (only) the community functions for communities of which it is a member, and
+
+- all global functions
+- global community functions if it is interested in this feature, and
 - its own local functions.
 
 ### Content topics
@@ -140,7 +146,7 @@ App-level messages that are considered ephemeral, MUST set the `ephemeral` field
 The end-to-end reliability layer contains the functions related to one of the two end-to-end reliability schemes defined for Status app messages:
 
 1. Minimum Viable protocol for Data Synchronisation, or MVDS (see [STATUS-MVDS-USAGE](./status-mvds.md))
-1. Scalable distributed log reliability (spec and a punchier name TBD, see the [original forum post announcement](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16))
+2. Scalable distributed log reliability (spec and a punchier name TBD, see the [original forum post announcement](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16))
 
 Ephemeral messages SHOULD omit this layer.
 Non-ephemeral 1:1 chat messages SHOULD make use of MVDS to achieve reliable data synchronisation between the two parties involved in the communication.
@@ -204,9 +210,9 @@ It is RECOMMENDED that separate pubsub topics be used for global control message
 
 #### Community messages
 
-The application SHOULD define at least one separate pubsub topic for each separate community's control and content messages.
-The application MAY define a set of more than one pubsub topic per community to allow traffic sharding for scalability.
-It is RECOMMENDED that separate pubsub topics be used for community control messages and community content messages.
+The application SHOULD define at least one distinct pubsub topic for global community control messages and global community content messages.
+The application MAY define a set of more than one pubsub topic for global community messages to allow traffic sharding for scalability.
+It is RECOMMENDED that separate pubsub topics be used for global community control messages and global community content messages.
 
 #### Large messages
 
@@ -243,8 +249,8 @@ useful for the user functions specific to that instance of the application.
 The specific Waku discovery protocol used for discovery depends on the use case and resource-availability of the client.
 
 1. [EIP-1459: DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459) is useful for initial connection to bootstrap peers.
-1. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) allows decentralized discovery of Waku peers.
-1. [34/WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md) allows requesting peers from a service node
+2. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) allows decentralized discovery of Waku peers.
+3. [34/WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md) allows requesting peers from a service node
 and is appropriate for resource-restricted discovery.
 
 All clients SHOULD use DNS-based discovery on startup
@@ -263,14 +269,14 @@ and to enable the user functions specific to that instance of the application.
 The specific Waku protocol used for subscription depends on the resource-availability of the client:
 
 1. Filter client protocol, as specified in [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md), allows subscribing for traffic with content topic granularity and is appropriate for resource-restricted subscriptions.
-1. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows subscribing to traffic only with pubsub topic granularity and therefore is more resource-intensive. Relay subscription also allows the application instance to contribute to the overall routing infrastructure, which adds to its overall higher resource usage but benefits the ecosystem.
+2. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows subscribing to traffic only with pubsub topic granularity and therefore is more resource-intensive. Relay subscription also allows the application instance to contribute to the overall routing infrastructure, which adds to its overall higher resource usage but benefits the ecosystem.
 
 Full clients SHOULD use relay protocol as preferred method to subscribe to pubsub topics matching the scopes:
 
 1. Global control
-1. Global content
-1. Community control, for each community of which the app user is a member
-1. Community content, for each community of which the app user is a member
+2. Global content
+3. Global community control, if the client has activated the Status Communities feature
+4. Global community content, if the client has activated the Status Communities feature
 
 Light clients SHOULD use filter protocol to subscribe only to the content topics relevant to the user.
 
@@ -290,14 +296,14 @@ The application MUST publish user and app generated messages via the Waku transp
 The specific Waku protocol used for publishing depends on the resource-availability of the client:
 
 1. Lightpush protocol, as specified in [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) allows publishing to a pubsub topic via an intermediate "full node" and is more appropriate for resource-restricted publishing.
-1. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows publishing directly into the relay routing network and is therefore more resource-intensive.
+2. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows publishing directly into the relay routing network and is therefore more resource-intensive.
 
 Full clients SHOULD use relay protocol to publish to pubsub topics matching the scopes:
 
 1. Global control
-1. Global content
-1. Community control, for each community of which the app user is a member
-1. Community content, for each community of which the app user is a member
+2. Global content
+3. Global community control, if the client has activated the Status Communities feature
+4. Global community content, if the client has activated the Status Communities feature
 
 Light clients SHOULD use lightpush protocol to publish control and content messages.
 
@@ -397,13 +403,13 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References
 
 1. [55/STATUS-1TO1-CHAT](../55/1to1-chat.md)
-1. [56/STATUS-COMMUNITIES](../56/communities.md)
-1. [10/WAKU2](../../waku/standards/core/10/waku2.md)
-1. [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
-1. [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md)
-1. [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md)
-1. [23/WAKU2-TOPICS](../../waku/informational/23/topics.md)
-1. [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md)
-1. [Scalable distributed log reliability](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16)
-1. [STATUS-MVDS-USAGE](./status-mvds.md)
-1. [WAKU2-STORE](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md)
+2. [56/STATUS-COMMUNITIES](../56/communities.md)
+3. [10/WAKU2](../../waku/standards/core/10/waku2.md)
+4. [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
+5. [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md)
+6. [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md)
+7. [23/WAKU2-TOPICS](../../waku/informational/23/topics.md)
+8. [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md)
+9. [Scalable distributed log reliability](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16)
+10. [STATUS-MVDS-USAGE](./status-mvds.md)
+11. [WAKU2-STORE](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md)

status/raw/url-data.md

@@ -26,7 +26,7 @@ this specification proposes a standard method for encoding data within URLs.
 - Community: Refer to [STATUS-COMMUNITIES](../56/communities.md)
 - Channel: Refer to terminology in [STATUS-COMMUNITIES](../56/communities.md)
 - User: Refer to terminology in [STATUS-COMMUNITIES](../56/communities.md)
-- Shard Refer to terminology in [51/WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
+- Shard Refer to terminology in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
 
 ## Wire Format
 

vac/raw/mix.md

@@ -735,7 +735,7 @@ ii. **Verify Timestamp**
 - If the timestamp is outside the acceptable window, the exit node
   discards the message.
 
-iii. **Verifiy Response**
+iii. **Verify Response**
 
 - Compute the SHA-256 hash of the `message` and check if the hash
   meets the difficulty requirement, _i.e._, has at least 18 leading zeros.

vac/raw/sds.md

@@ -0,0 +1,276 @@
+---
+title: SDS
+name: Scalable Data Sync protocol for distributed logs
+status: raw
+editor: Hanno Cornelius <hanno@status.im>
+contributors:
+  - Akhil Peddireddy <akhil@status.im>
+---
+
+## Abstract
+
+This specification introduces the Scalable Data Sync (SDS) protocol
+to achieve end-to-end reliability
+when consolidating distributed logs in a decentralized manner.
+The protocol is designed for a peer-to-peer (p2p) topology
+where an append-only log is maintained by each member of a group of nodes
+who may individually append new entries to their local log at any time and
+is interested in merging new entries from other nodes in real-time or close to real-time
+while maintaining a consistent order.
+The outcome of the log consolidation procedure is
+that all nodes in the group eventually reflect in their own logs
+the same entries in the same order.
+The protocol aims to scale to very large groups.
+
+## Motivation
+
+A common application that fits this model is a p2p group chat (or group communication),
+where the participants act as log nodes
+and the group conversation is modelled as the consolidated logs
+maintained on each node.
+The problem of end-to-end reliability can then be stated as
+ensuring that all participants eventually see the same sequence of messages
+in the same causal order,
+despite the challenges of network latency, message loss,
+and scalability present in any communications transport layer.
+The rest of this document will assume the terminology of a group communication:
+log nodes being the _participants_ in the group chat
+and the logged entries being the _messages_ exchanged between participants.
+
+## Design Assumptions
+
+We make the following simplifying assumptions for a proposed reliability protocol:
+
+* **Broadcast routing:**
+Messages are broadcast disseminated by the underlying transport.
+The selected transport takes care of routing messages
+to all participants of the communication.
+* **Store nodes:**
+There are high-availability caches (a.k.a. Store nodes)
+from which missed messages can be retrieved.
+These caches maintain the full history of all messages that have been broadcast.
+This is an optional element in the protocol design,
+but improves scalability by reducing direct interactions between participants.
+* **Message ID:**
+Each message has a globally unique, immutable ID (or hash).
+Messages can be requested from the high-availability caches or
+other participants using the corresponding message ID.
+
+## Wire protocol
+
+The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
+“SHOULD NOT”, “RECOMMENDED”, “MAY”, and
+ “OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+### Message
+
+Messages MUST adhere to the following meta structure:
+
+```protobuf
+syntax = "proto3";
+
+message HistoryEntry {
+  string message_id = 1; // Unique identifier of the SDS message, as defined in `Message`
+  optional bytes retrieval_hint = 2; // Optional information to help remote parties retrieve this SDS message; For example, A Waku deterministic message hash or routing payload hash
+}
+
+message Message {
+  // 1 Reserved for sender/participant id
+  string message_id = 2;          // Unique identifier of the message
+  string channel_id = 3;          // Identifier of the channel to which the message belongs
+  optional int32 lamport_timestamp = 10;    // Logical timestamp for causal ordering in channel
+  repeated HistoryEntry causal_history = 11;  // List of preceding message IDs that this message causally depends on. Generally 2 or 3 message IDs are included.
+  optional bytes bloom_filter = 12;         // Bloom filter representing received message IDs in channel
+  optional bytes content = 20;             // Actual content of the message
+}
+```
+
+Each message MUST include its globally unique identifier in the `message_id` field,
+likely based on a message hash.
+The `channel_id` field MUST be set to the identifier of the channel of group communication
+that is being synchronized.
+For simple group communications without individual channels,
+the `channel_id` SHOULD be set to `0`.
+The `lamport_timestamp`, `causal_history` and
+`bloom_filter` fields MUST be set according to the [protocol steps](#protocol-steps)
+set out below.
+These fields MAY be left unset in the case of [ephemeral messages](#ephemeral-messages).
+The message `content` MAY be left empty for [periodic sync messages](#periodic-sync-message),
+otherwise it MUST contain the application-level content
+
+### Participant state
+
+Each participant MUST maintain:
+
+* A Lamport timestamp for each channel of communication,
+initialized to current epoch time in nanosecond resolution.
+* A bloom filter for received message IDs per channel.
+The bloom filter SHOULD be rolled over and
+recomputed once it reaches a predefined capacity of message IDs.
+Furthermore,
+it SHOULD be designed to minimize false positives through an optimal selection of
+size and hash functions.
+* A buffer for unacknowledged outgoing messages
+* A buffer for incoming messages with unmet causal dependencies
+* A local log (or history) for each channel,
+containing all message IDs in the communication channel,
+ordered by Lamport timestamp.
+
+Messages in the unacknowledged outgoing buffer can be in one of three states:
+
+1. **Unacknowledged** - there has been no acknowledgement of message receipt
+by any participant in the channel
+2. **Possibly acknowledged** - there has been ambiguous indication that the message
+has been _possibly_ received by at least one participant in the channel
+3. **Acknowledged** - there has been sufficient indication that the message
+has been received by at least some of the participants in the channel.
+This state will also remove the message from the outgoing buffer.
+
+### Protocol Steps
+
+For each channel of communication,
+participants MUST follow these protocol steps to populate and interpret
+the `lamport_timestamp`, `causal_history` and `bloom_filter` fields.
+
+#### Send Message
+
+Before broadcasting a message:
+
+* the participant MUST increase its local Lamport timestamp by `1` and
+include this in the `lamport_timestamp` field.
+* the participant MUST determine the preceding few message IDs in the local history
+and include these in an ordered list in the `causal_history` field.
+The number of message IDs to include in the `causal_history` depends on the application.
+We recommend a causal history of two message IDs.
+* the participant MAY include a `retrieval_hint` in the `HistoryEntry`
+for each message ID in the `causal_history` field.
+This is an application-specific field to facilitate retrieval of messages,
+e.g. from high-availability caches.
+* the participant MUST include the current `bloom_filter`
+state in the broadcast message.
+
+After broadcasting a message,
+the message MUST be added to the participant’s buffer
+of unacknowledged outgoing messages.
+
+#### Receive Message
+
+Upon receiving a message,
+
+* the participant MUST [review the ACK status](#review-ack-status) of messages
+in its unacknowledged outgoing buffer
+using the received message's causal history and bloom filter.
+* if the message has a populated `content` field,
+the participant MUST include the received message ID in its local bloom filter.
+* the participant MUST verify that all causal dependencies are met
+for the received message.
+Dependencies are met if the message IDs in the `causal_history` of the received message
+appear in the local history of the receiving participant.
+
+If all dependencies are met and the message has a populated `content` field,
+the participant MUST [deliver the message](#deliver-message).
+If dependencies are unmet,
+the participant MUST add the message to the incoming buffer of messages
+with unmet causal dependencies.
+
+#### Deliver Message
+
+Triggered by the [Receive Message](#receive-message) procedure.
+
+If the received message’s Lamport timestamp is greater than the participant's
+local Lamport timestamp,
+the participant MUST update its local Lamport timestamp to match the received message.
+The participant MUST insert the message ID into its local log,
+based on Lamport timestamp.
+If one or more message IDs with the same Lamport timestamp already exists,
+the participant MUST follow the [Resolve Conflicts](#resolve-conflicts) procedure.
+
+#### Resolve Conflicts
+
+Triggered by the [Deliver Message](#deliver-message) procedure.
+
+The participant MUST order messages with the same Lamport timestamp
+in ascending order of message ID.
+If the message ID is implemented as a hash of the message,
+this means the message with the lowest hash would precede
+other messages with the same Lamport timestamp in the local log.
+
+#### Review ACK Status
+
+Triggered by the [Receive Message](#receive-message) procedure.
+
+For each message in the unacknowledged outgoing buffer,
+based on the received `bloom_filter` and `causal_history`:
+
+* the participant MUST mark all messages in the received `causal_history` as **acknowledged**.
+* the participant MUST mark all messages included in the `bloom_filter`
+as **possibly acknowledged**.
+If a message appears as **possibly acknowledged** in multiple received bloom filters,
+the participant MAY mark it as acknowledged based on probabilistic grounds,
+taking into account the bloom filter size and hash number.
+
+#### Periodic Incoming Buffer Sweep
+
+The participant MUST periodically check causal dependencies for each message
+in the incoming buffer.
+For each message in the incoming buffer:
+
+* the participant MAY attempt to retrieve missing dependencies from the Store node
+(high-availability cache) or other peers.
+It MAY use the application-specific `retrieval_hint` in the `HistoryEntry` to facilitate retrieval.
+* if all dependencies of a message are met,
+the participant MUST proceed to [deliver the message](#deliver-message).
+
+If a message's causal dependencies have failed to be met
+after a predetermined amount of time,
+the participant MAY mark them as **irretrievably lost**.
+
+#### Periodic Outgoing Buffer Sweep
+
+The participant MUST rebroadcast **unacknowledged** outgoing messages
+after a set period.
+The participant SHOULD use distinct resend periods for **unacknowledged** and
+**possibly acknowledged** messages,
+prioritizing **unacknowledged** messages.
+
+#### Periodic Sync Message
+
+For each channel of communication,
+participants SHOULD periodically send sync messages to maintain state.
+These sync messages:
+
+* MUST be sent with empty content
+* MUST include an incremented Lamport timestamp
+* MUST include causal history and bloom filter according to regular message rules
+* MUST NOT be added to the unacknowledged outgoing buffer
+* MUST NOT be included in causal histories of subsequent messages
+* MUST NOT be included in bloom filters
+* MUST NOT be added to the local log
+
+Since sync messages are not persisted,
+they MAY have non-unique message IDs without impacting the protocol.
+To avoid network activity bursts in large groups,
+a participant MAY choose to only send periodic sync messages
+if no other messages have been broadcast in the channel after a random backoff period.
+
+Participants MUST process the causal history and bloom filter of these sync messages
+following the same steps as regular messages,
+but MUST NOT persist the sync messages themselves.
+
+#### Ephemeral Messages
+
+Participants MAY choose to send short-lived messages for which no synchronization
+or reliability is required.
+These messages are termed _ephemeral_.
+
+Ephemeral messages SHOULD be sent with `lamport_timestamp`, `causal_history`, and
+`bloom_filter` unset.
+Ephemeral messages SHOULD NOT be added to the unacknowledged outgoing buffer
+after broadcast.
+Upon reception,
+ephemeral messages SHOULD be delivered immediately without buffering for causal dependencies
+or including in the local log.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

vac/stagnant/decentralized-messaging-ethereum.md

@@ -1,7 +1,7 @@
 ---
 title: VAC-DECENTRALIZED-MESSAGING-ETHEREUM
 name: Decentralized Key and Session Setup for Secure Messaging over Ethereum
-status: raw
+status: stagnant
 category: informational
 editor: Ramses Fernandez-Valencia <ramses@status.im>
 contributors:

vac/template.md

@@ -1,9 +1,9 @@
 ---
 slug: XX
-title: XX/(WAKU2|LOGOS|CODEX|*)-TEMPLATE
-name: (Waku v2 | Logos | Codex) RFC Template
-status: (raw|draft|stable)
-category: (Standards Track|Informational|Best Current Practice)
+title: TEMPLATE
+name: RFC Template
+status: raw/draft/stable/deprecated
+category: Standards Track/Informational/Best Current Practice
 tags: an optional list of tags, not standard
 editor: Daniel Kaiser <danielkaiser@status.im>
 contributors:

waku/informational/23/topics.md

@@ -19,9 +19,9 @@ In [10/WAKU2 spec](../../standards/core/10/waku2.md) there are two types of topi
 ## Pubsub Topics
 
 Pubsub topics are used for routing of messages (see [11/WAKU2-RELAY](../../standards/core/11/relay.md)),
-and can be named implicitly by Waku sharding (see [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)).
+and can be named implicitly by Waku sharding (see [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)).
 This document comprises recommendations for explicitly naming pubsub topics
-(e.g. when choosing *named sharding* as specified in [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)).
+(e.g. when choosing *named sharding* as specified in [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)).
 
 ### Pubsub Topic Format
 
@@ -80,7 +80,7 @@ but for different domains completely.
 
 ### Named Topic Sharding Example
 
-The following is an example of named sharding, as specified in [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md).
+The following is an example of named sharding, as specified in [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md).
 
 ```text
 waku/2/waku-9_shard-0/
@@ -120,8 +120,8 @@ As an example, here's the content topic used for an upcoming testnet:
 
 ### Content Topic Naming Recommendations
 
-Application names should be unique to avoid conflicting issues with other protocols.
-Applications should specify their version (if applicable) in the version field.
+Application names SHOULD be unique to avoid conflicting issues with other protocols.
+Applications SHOULD specify their version (if applicable) in the version field.
 The `{content-topic-name}` portion of the content topic is up to the application,
 and depends on the problem domain.
 It can be hierarchical, for instance to separate content, or
@@ -129,6 +129,17 @@ to indicate different bandwidth and privacy guarantees.
 The encoding field indicates the serialization/encoding scheme
 for the [WakuMessage payload](../../standards/core/14/message.md/#payloads) field.
 
+### Content Topic usage guidelines
+
+Applications SHOULD be mindful while designing/using content topics so that a bloat of content-topics does not happen.
+A content-topic bloat causes performance degradation in Store and Filter protocols while trying to retrieve messages.
+
+Store queries have been noticed to be considerably slow (e.g doubling of response-time when content-topic count is increased from 10 to 100) when a lot of content-topics are involved in a single query.
+Similarly number of filter subscriptions increase, which increases complexity on client side to maintain and manage these subscriptions.
+
+Applications SHOULD analyze the query/filter criteria for fetching messages from the network and select/design content topics to match such filter criteria.
+e.g: even though applications may want to segregate messages into different sets based on some application logic, if those sets of messages are always fetched/queried together from the network, then all those messages SHOULD use a single content-topic.
+
 ## Differences with Waku v1
 
 In [5/WAKU1](../../deprecated/5/waku0.md) there is no actual routing.
@@ -175,7 +186,7 @@ Copyright and related rights waived via
 
 - [10/WAKU2 spec](../../standards/core/10/waku2.md)
 - [11/WAKU2-RELAY](../../standards/core/11/relay.md)
-- [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)
+- [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
 - [Ethereum 2 P2P spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#topics-and-messages)
 - [14/WAKU2-MESSAGE](../../standards/core/14/message.md)
 - [12/WAKU2-FILTER](../../standards/core/12/filter.md)

waku/standards/core/10/waku2.md

@@ -224,7 +224,7 @@ It is possible to bypass the discovery domain by specifying static nodes.
 
 #### Use of ENR
 
-[31/WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md)
+[WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
 describes the usage of [EIP-778 ENR (Ethereum Node Records)](https://eips.ethereum.org/EIPS/eip-778)
 for Waku v2 discovery purposes.
 It introduces two new ENR fields, `multiaddrs` and
@@ -574,7 +574,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 17. [Node Discovery v5](https://github.com/ethereum/devp2p/blob/8fd5f7e1c1ec496a9d8dc1640a8548b8a8b5986b/discv5/discv5.md)
 
-18. [31/WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md)
+18. [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
 
 19. [EIP-778 ENR (Ethereum Node Records)](https://eips.ethereum.org/EIPS/eip-778)
 

waku/standards/core/13/previous-versions/00/store.md

@@ -0,0 +1,359 @@
+---
+slug: 13
+title: 13/WAKU2-STORE
+name: Waku v2 Store
+status: draft
+tags: waku-core
+version: 00
+editor: Simon-Pierre Vivier <simvivier@status.im>
+contributors:
+  - Dean Eigenmann <dean@status.im>
+  - Oskar Thorén <oskarth@titanproxy.com>
+  - Aaryamann Challani <p1ge0nh8er@proton.me>
+  - Sanaz Taheri <sanaz@status.im>
+  - Hanno Cornelius <hanno@status.im>
+---
+
+## Abstract
+
+This specification explains the `13/WAKU2-STORE` protocol
+which enables querying of messages received through the relay protocol and
+stored by other nodes.
+It also supports pagination for more efficient querying of historical messages.
+
+**Protocol identifier***: `/vac/waku/store/2.0.0-beta4`
+
+## Terminology
+
+The term PII, Personally Identifiable Information,
+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.
+
+## Design Requirements
+
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
+“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
+“OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+Nodes willing to provide the storage service using `13/WAKU2-STORE` protocol,
+SHOULD provide a complete and full view of message history.
+As such, they are required to be *highly available* and
+specifically have a *high uptime* to consistently receive and store network messages.
+The high uptime requirement makes sure that no message is missed out
+hence a complete and 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).
+Nodes running `13/WAKU2-STORE` SHOULD NOT store messages
+with the `ephemeral` flag set to `true`.
+
+## Adversarial Model
+
+Any peer running the `13/WAKU2-STORE` protocol, i.e.
+both the querying node and the queried node, are considered as an adversary.
+Furthermore,
+we currently consider the adversary as a passive entity
+that attempts to collect information from other peers to conduct an attack but
+it does so without violating protocol definitions and instructions.
+As we evolve the protocol,
+further adversarial models will be considered.
+For example, under the passive adversarial model,
+no malicious node hides or
+lies about the history of messages
+as it is against the description of the `13/WAKU2-STORE` protocol.
+
+The following are not considered as part of the adversarial model:
+
+- An adversary with a global view of all the peers and their connections.
+- An adversary that can eavesdrop on communication links
+between arbitrary pairs of peers (unless the adversary is one end of the communication).
+In specific, the communication channels are assumed to be secure.
+
+## Wire Specification
+
+Peers communicate with each other using a request / response API.
+The messages sent are Protobuf RPC messages which are implemented using
+[protocol buffers v3](https://developers.google.com/protocol-buffers/).
+The following are the specifications of the Protobuf messages.
+
+### Payloads
+
+```protobuf
+syntax = "proto3";
+
+message Index {
+  bytes digest = 1;
+  sint64 receiverTime = 2;
+  sint64 senderTime = 3;
+  string pubsubTopic = 4;
+}
+
+message PagingInfo {
+  uint64 pageSize = 1;
+  Index cursor = 2;
+  enum Direction {
+    BACKWARD = 0;
+    FORWARD = 1;
+  }
+  Direction direction = 3;
+}
+
+message ContentFilter {
+  string contentTopic = 1;
+}
+
+message HistoryQuery {
+  // the first field is reserved for future use
+  string pubsubtopic = 2;
+  repeated ContentFilter contentFilters = 3;
+  PagingInfo pagingInfo = 4;
+}
+
+message HistoryResponse {
+  // the first field is reserved for future use
+  repeated WakuMessage messages = 2;
+  PagingInfo pagingInfo = 3;
+  enum Error {
+    NONE = 0;
+    INVALID_CURSOR = 1;
+  }
+  Error error = 4;
+}
+
+message HistoryRPC {
+  string request_id = 1;
+  HistoryQuery query = 2;
+  HistoryResponse response = 3;
+}
+```
+
+#### Index
+
+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)).
+- `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.
+
+#### PagingInfo
+
+`PagingInfo` holds the information required for pagination.
+It consists of the following components.
+
+- `pageSize`: A positive integer indicating the number of queried `WakuMessage`s
+in a `HistoryQuery`
+(or retrieved  `WakuMessage`s in a `HistoryResponse`).
+- `cursor`: holds the `Index` of a `WakuMessage`.
+- `direction`: indicates the direction of paging
+which can be either `FORWARD` or `BACKWARD`.
+
+#### 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).
+  
+#### HistoryQuery
+
+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).
+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.
+Leaving this field empty means no filter on the content topic
+of message history is required.
+This field SHOULD be left empty in order
+to retrieve historical `WakuMessage` regardless of their content topics.
+- `PagingInfo` holds the information required for pagination.  
+Its `pageSize` field indicates the number of  `WakuMessage`s
+to be included in the corresponding `HistoryResponse`.
+It is RECOMMENDED that the queried node defines a maximum page size internally.
+If the querying node leaves the `pageSize` unspecified,
+or if the `pageSize` exceeds the maximum page size,
+the queried node SHOULD auto-paginate the `HistoryResponse`
+to no more than the configured maximum page size.
+This allows mitigation of long response time for `HistoryQuery`.
+In the forward pagination request,
+the `messages` field of the `HistoryResponse` SHALL contain, at maximum,
+the `pageSize` amount of `WakuMessage` whose `Index`
+values are larger than the given `cursor`
+(and vise versa for the backward pagination).
+Note that the `cursor` of a `HistoryQuery` MAY be empty
+(e.g., for the initial query), as such, and
+depending on whether the  `direction` is `BACKWARD` or
+`FORWARD`  the last or the first `pageSize` `WakuMessage` SHALL be returned,
+respectively.
+
+#### Sorting Messages
+
+The queried node MUST sort the `WakuMessage` based on their `Index`,
+where the `senderTime` constitutes the most significant part and
+the `digest` comes next, and
+then perform pagination on the sorted result.
+As such, the retrieved page contains an ordered list of `WakuMessage`
+from the oldest messages to the most recent one.
+Alternatively, the `receiverTime` (instead of `senderTime`)
+MAY be used to sort messages during the paging process.
+However, it is RECOMMENDED the use of the `senderTime`
+for sorting as it is invariant and
+consistent across all the nodes.
+This has the benefit of `cursor` reusability i.e.,
+a `cursor` obtained from one node can be consistently used
+to query from another node.
+However, this `cursor` reusability does not hold when the `receiverTime` is utilized
+as the receiver time is affected by the network delay and
+nodes' clock asynchrony.
+
+#### HistoryResponse
+
+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.
+- `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 `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.
+This is also the default value.
+`INVALID_CURSOR` means that the `cursor` field of `HistoryQuery`
+does not match with the `Index` of any of the `WakuMessage`
+persisted by the queried node.
+
+## Security Consideration
+
+The main security consideration to take into account
+while using this protocol is that a querying node
+have to reveal their content filters of interest to the queried node,
+hence potentially compromising their privacy.
+
+## 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.  
+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).
+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.
+However, one can consider preserving anonymity through one of the following ways:
+  - By hiding the source of the request i.e., anonymous communication.
+  That is the querying node shall hide all its PII in its history 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 historical requests
+  does not embody any piece of PII, otherwise,
+  such data fields must be treated carefully to achieve query anonymity.
+  <!-- TODO: if nodes have to disclose their PeerIDs
+  (e.g., for authentication purposes) when connecting to other nodes
+  in the store protocol,
+  then Tor does not preserve anonymity since it only helps in hiding the IP.
+  So, the PeerId usage in switches must be investigated further.
+  Depending on how PeerId is used, one may be able to link between a querying node
+  and its queried topics despite hiding the IP address-->
+  - By deploying secure 2-party computations in which the querying node
+  obtains the historical messages of a certain topic,
+  the queried node learns nothing about the query.
+  Examples of such 2PC protocols are secure one-way Private Set Intersections (PSI).
+  <!-- TODO: add a reference for PSIs? -->
+  <!-- TODO: more techniques to be included -->
+<!-- TODO: Censorship resistant:
+this is about a node that hides the historical messages from other nodes.
+This attack is not included in the specs
+since it does not fit the passive adversarial model
+(the attacker needs to deviate from the store protocol).-->
+
+- **Robust and verifiable timestamps**:
+Messages timestamp is a way to show that the message existed
+prior to some point in time.
+However, the lack of timestamp verifiability can create room for a range of attacks,
+including injecting messages with invalid timestamps pointing to the far future.
+To better understand the attack,
+consider a store node whose current clock shows `2021-01-01 00:00:30`
+(and assume all the other nodes have a synchronized clocks +-20seconds).
+The store node already has a list of messages,
+ `(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20)`,
+that are sorted based on their timestamp.  
+An attacker sends a message with an arbitrary large timestamp e.g.,
+10 hours ahead of the correct clock `(m',2021-01-01 10:00:30)`.
+The store node places `m'` at the end of the list,
+
+```text
+(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20),(m',2021-01-01 10:00:30).
+```
+
+Now another message arrives with a valid timestamp e.g.,
+`(m11, 2021-01-01 00:00:45)`.
+However, since its timestamp precedes the malicious message `m'`,
+it gets placed before `m'` in the list i.e.,
+
+```text
+(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20), (m11, 2021-01-01 00:00:45), (m',2021-01-01 10:00:30).
+```
+
+In fact, for the next 10 hours,
+`m'` will always be considered as the most recent message and
+served as the last message to the querying nodes irrespective
+of how many other messages arrive afterward.
+
+A robust and verifiable timestamp allows the receiver of a message
+to verify that a message has been generated prior to the claimed timestamp.
+One solution is the use of [open timestamps](https://opentimestamps.org/) e.g.,
+block height in Blockchain-based timestamps.
+That is, messages contain the most recent block height
+perceived by their senders at the time of message generation.
+This proves accuracy within a range of minutes (e.g., in Bitcoin blockchain) or
+seconds (e.g., in Ethereum 2.0) from the time of origination.
+
+## Copyright
+
+Copyright and related rights waived via
+[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+1. [14/WAKU2-MESSAGE](../14/message.md)
+2. [protocol buffers v3](https://developers.google.com/protocol-buffers/)
+3. [11/WAKU2-RELAY](../11/relay.md)
+4. [Open timestamps](https://opentimestamps.org/)

waku/standards/core/13/store.md

@@ -1,311 +1,402 @@
 ---
 slug: 13
 title: 13/WAKU2-STORE
-name: Waku v2 Store
-status: draft
+name: Waku Store Query
 tags: waku-core
-editor: Simon-Pierre Vivier <simvivier@status.im>
+version: 01
+editor: Hanno Cornelius <hanno@status.im>
 contributors:
   - Dean Eigenmann <dean@status.im>
   - Oskar Thorén <oskarth@titanproxy.com>
   - Aaryamann Challani <p1ge0nh8er@proton.me>
   - Sanaz Taheri <sanaz@status.im>
-  - Hanno Cornelius <hanno@status.im>
 ---
+Previous version: [00](waku/standards/core/13/previous-versions/00/store.md)
 
 ## Abstract
 
-This specification explains the `13/WAKU2-STORE` protocol
-which enables querying of messages received through the relay protocol and
-stored by other nodes.
-It also supports pagination for more efficient querying of historical messages.
+This specification explains the `WAKU2-STORE` protocol,
+which enables querying of [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md)s.
 
-**Protocol identifier***: `/vac/waku/store/2.0.0-beta4`
+**Protocol identifier***: `/vac/waku/store-query/3.0.0`
 
-## Terminology
+### Terminology
 
 The term PII, Personally Identifiable Information,
 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.
 
-## Design Requirements
+## Wire Specification
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
 “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
 “OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-Nodes willing to provide the storage service using `13/WAKU2-STORE` protocol,
-SHOULD provide a complete and full view of message history.
-As such, they are required to be *highly available* and
-specifically have a *high uptime* to consistently receive and store network messages.
-The high uptime requirement makes sure that no message is missed out
-hence a complete and 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.
+### Design Requirements
 
-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).
-Nodes running `13/WAKU2-STORE` SHOULD NOT store messages
-with the `ephemeral` flag set to `true`.
-
-## Adversarial Model
-
-Any peer running the `13/WAKU2-STORE` protocol, i.e.
-both the querying node and the queried node, are considered as an adversary.
-Furthermore,
-we currently consider the adversary as a passive entity
-that attempts to collect information from other peers to conduct an attack but
-it does so without violating protocol definitions and instructions.
-As we evolve the protocol,
-further adversarial models will be considered.
-For example, under the passive adversarial model,
-no malicious node hides or
-lies about the history of messages
-as it is against the description of the `13/WAKU2-STORE` protocol.
-
-The following are not considered as part of the adversarial model:
-
-- An adversary with a global view of all the peers and their connections.
-- An adversary that can eavesdrop on communication links
-between arbitrary pairs of peers (unless the adversary is one end of the communication).
-In specific, the communication channels are assumed to be secure.
-
-## Wire Specification
-
-Peers communicate with each other using a request / response API.
-The messages sent are Protobuf RPC messages which are implemented using
-[protocol buffers v3](https://developers.google.com/protocol-buffers/).
-The following are the specifications of the Protobuf messages.
+The concept of `ephemeral` messages introduced in [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md) affects `WAKU2-STORE` as well.
+Nodes running `WAKU2-STORE` SHOULD support `ephemeral` messages as specified in [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md).
+Nodes running `WAKU2-STORE` SHOULD NOT store messages with the `ephemeral` flag set to `true`.
 
 ### Payloads
 
 ```protobuf
 syntax = "proto3";
 
-message Index {
-  bytes digest = 1;
-  sint64 receiverTime = 2;
-  sint64 senderTime = 3;
-  string pubsubTopic = 4;
+// Protocol identifier: /vac/waku/store-query/3.0.0
+package waku.store.v3;
+
+import "waku/message/v1/message.proto";
+
+message WakuMessageKeyValue {
+  optional bytes message_hash = 1; // Globally unique key for a Waku Message
+
+  // Full message content and associated pubsub_topic as value
+  optional waku.message.v1.WakuMessage message = 2;
+  optional string pubsub_topic = 3;
 }
 
-message PagingInfo {
-  uint64 pageSize = 1;
-  Index cursor = 2;
-  enum Direction {
-    BACKWARD = 0;
-    FORWARD = 1;
-  }
-  Direction direction = 3;
-}
-
-message ContentFilter {
-  string contentTopic = 1;
-}
-
-message HistoryQuery {
-  // the first field is reserved for future use
-  string pubsubtopic = 2;
-  repeated ContentFilter contentFilters = 3;
-  PagingInfo pagingInfo = 4;
-}
-
-message HistoryResponse {
-  // the first field is reserved for future use
-  repeated WakuMessage messages = 2;
-  PagingInfo pagingInfo = 3;
-  enum Error {
-    NONE = 0;
-    INVALID_CURSOR = 1;
-  }
-  Error error = 4;
-}
-
-message HistoryRPC {
+message StoreQueryRequest {
   string request_id = 1;
-  HistoryQuery query = 2;
-  HistoryResponse response = 3;
+  bool include_data = 2; // Response should include full message content
+  
+  // Filter criteria for content-filtered queries
+  optional string pubsub_topic = 10;
+  repeated string content_topics = 11;
+  optional sint64 time_start = 12;
+  optional sint64 time_end = 13;
+
+  // List of key criteria for lookup queries
+  repeated bytes message_hashes = 20; // Message hashes (keys) to lookup
+  
+  // Pagination info. 50 Reserved
+  optional bytes pagination_cursor = 51; // Message hash (key) from where to start query (exclusive)
+  bool pagination_forward = 52;
+  optional uint64 pagination_limit = 53;
+}
+
+message StoreQueryResponse {
+  string request_id = 1;
+
+  optional uint32 status_code = 10;
+  optional string status_desc = 11;
+
+  repeated WakuMessageKeyValue messages = 20;
+
+  optional bytes pagination_cursor = 51;
 }
 ```
 
-#### Index
+### General Store Query Concepts
 
-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.
+#### Waku Message Key-Value Pairs
 
-- `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)).
-- `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.
+The store query protocol operates as a query protocol for a key-value store of historical messages,
+with each entry having a [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md)
+and associated `pubsub_topic` as the value,
+and [deterministic message hash](/waku/standards/core/14/message.md#deterministic-message-hashing) as the key.
+The store can be queried to return either a set of keys or a set of key-value pairs.
 
-#### PagingInfo
+Within the store query protocol,
+the [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md) keys and
+values MUST be represented in a `WakuMessageKeyValue` message.
+This message MUST contain the deterministic `message_hash` as the key.
+It MAY contain the full [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md) and
+associated pubsub topic as the value in the `message` and
+`pubsub_topic` fields, depending on the use case as set out below.
 
-`PagingInfo` holds the information required for pagination.
-It consists of the following components.
+If the message contains a value entry in addition to the key,
+both the `message` and `pubsub_topic` fields MUST be populated.
+The message MUST NOT have either `message` or `pubsub_topic` populated with the other unset.
+Both fields MUST either be set or unset.
 
-- `pageSize`: A positive integer indicating the number of queried `WakuMessage`s
-in a `HistoryQuery`
-(or retrieved  `WakuMessage`s in a `HistoryResponse`).
-- `cursor`: holds the `Index` of a `WakuMessage`.
-- `direction`: indicates the direction of paging
-which can be either `FORWARD` or `BACKWARD`.
+#### Waku Message Store Eligibility
 
-#### ContentFilter
+In order for a message to be eligible for storage:
 
-`ContentFilter` carries the information required for filtering historical messages.
+- it MUST be a _valid_ [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md).
+- the `timestamp` field MUST be populated with the Unix epoch time,
+at which the message was generated in nanoseconds.
+If at the time of storage the `timestamp` deviates by more than 20 seconds
+either into the past or the future when compared to the store node’s internal clock,
+the store node MAY reject the message.
+- the `ephemeral` field MUST be set to `false`.
 
-- `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).
-  
-#### HistoryQuery
+#### Waku message sorting
 
-RPC call to query historical messages.
+The key-value entries in the store MUST be time-sorted by the [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md) `timestamp` attribute.
+Where two or more key-value entries have identical `timestamp` values,
+the entries MUST be further sorted by the natural order of their message hash keys.
+Within the context of traversing over key-value entries in the store,
+_"forward"_ indicates traversing the entries in ascending order,
+whereas _"backward"_ indicates traversing the entries in descending order.
 
-- 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).
-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.
-Leaving this field empty means no filter on the content topic
-of message history is required.
-This field SHOULD be left empty in order
-to retrieve historical `WakuMessage` regardless of their content topics.
-- `PagingInfo` holds the information required for pagination.  
-Its `pageSize` field indicates the number of  `WakuMessage`s
-to be included in the corresponding `HistoryResponse`.
-It is RECOMMENDED that the queried node defines a maximum page size internally.
-If the querying node leaves the `pageSize` unspecified,
-or if the `pageSize` exceeds the maximum page size,
-the queried node SHOULD auto-paginate the `HistoryResponse`
-to no more than the configured maximum page size.
-This allows mitigation of long response time for `HistoryQuery`.
-In the forward pagination request,
-the `messages` field of the `HistoryResponse` SHALL contain, at maximum,
-the `pageSize` amount of `WakuMessage` whose `Index`
-values are larger than the given `cursor`
-(and vise versa for the backward pagination).
-Note that the `cursor` of a `HistoryQuery` MAY be empty
-(e.g., for the initial query), as such, and
-depending on whether the  `direction` is `BACKWARD` or
-`FORWARD`  the last or the first `pageSize` `WakuMessage` SHALL be returned,
-respectively.
+#### Pagination
 
-#### Sorting Messages
+If a large number of entries in the store service node match the query criteria provided in a `StoreQueryRequest`,
+the client MAY make use of pagination
+in a chain of store query request and response transactions
+to retrieve the full response in smaller batches termed _"pages"_.
+Pagination can be performed either in [a _forward_ or _backward_ direction](#waku-message-sorting).
 
-The queried node MUST sort the `WakuMessage` based on their `Index`,
-where the `senderTime` constitutes the most significant part and
-the `digest` comes next, and
-then perform pagination on the sorted result.
-As such, the retrieved page contains an ordered list of `WakuMessage`
-from the oldest messages to the most recent one.
-Alternatively, the `receiverTime` (instead of `senderTime`)
-MAY be used to sort messages during the paging process.
-However, it is RECOMMENDED the use of the `senderTime`
-for sorting as it is invariant and
-consistent across all the nodes.
-This has the benefit of `cursor` reusability i.e.,
-a `cursor` obtained from one node can be consistently used
-to query from another node.
-However, this `cursor` reusability does not hold when the `receiverTime` is utilized
-as the receiver time is affected by the network delay and
-nodes' clock asynchrony.
+A store query client MAY indicate the maximum number of matching entries it wants in the `StoreQueryResponse`,
+by setting the page size limit in the `pagination_limit` field.
+Note that a store service node MAY enforce its own limit
+if the `pagination_limit` is unset
+or larger than the service node's internal page size limit.
 
-#### HistoryResponse
+A `StoreQueryResponse` with a populated `pagination_cursor` indicates that more stored entries match the query than included in the response.
 
-RPC call to respond to a HistoryQuery call.
+A `StoreQueryResponse` without a populated `pagination_cursor` indicates that
+there are no more matching entries in the store.
 
-- The `messages` field MUST contain the messages found,
-these are [14/WAKU2-MESSAGE](../14/message.md) 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 `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.
-This is also the default value.
-`INVALID_CURSOR` means that the `cursor` field of `HistoryQuery`
-does not match with the `Index` of any of the `WakuMessage`
-persisted by the queried node.
+The client MAY request the next page of entries from the store service node
+by populating a subsequent `StoreQueryRequest` with the `pagination_cursor`
+received in the `StoreQueryResponse`.
+All other fields and query criteria MUST be the same as in the preceding `StoreQueryRequest`.
 
-## Security Consideration
+A `StoreQueryRequest` without a populated `pagination_cursor` indicates that
+the client wants to retrieve the "first page" of the stored entries matching the query.
 
-The main security consideration to take into account
-while using this protocol is that a querying node
-have to reveal their content filters of interest to the queried node,
+### Store Query Request
+
+A client node MUST send all historical message queries within a `StoreQueryRequest` message.
+This request MUST contain a `request_id`.
+The `request_id` MUST be a uniquely generated string.
+
+If the store query client requires the store service node to include [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md) values in the query response,
+it MUST set `include_data` to `true`.
+If the store query client requires the store service node to return only message hash keys in the query response,
+it SHOULD set `include_data` to `false`.
+By default, therefore, the store service node assumes `include_data` to be `false`.
+
+A store query client MAY include query filter criteria in the `StoreQueryRequest`.
+There are two types of filter use cases:
+
+1. Content filtered queries and
+2. Message hash lookup queries
+
+#### Content filtered queries
+
+A store query client MAY request the store service node to filter historical entries by a content filter.
+Such a client MAY create a filter on content topic, on time range or on both.
+
+To filter on content topic,
+the client MUST populate _both_ the `pubsub_topic` _and_ `content_topics` field.
+The client MUST NOT populate either `pubsub_topic` or
+`content_topics` and leave the other unset.
+Both fields MUST either be set or unset.
+A mixed content topic filter with just one of either `pubsub_topic` or
+`content_topics` set, SHOULD be regarded as an invalid request.
+
+To filter on time range, the client MUST set `time_start`, `time_end` or both.
+Each `time_` field should contain a Unix epoch timestamp in nanoseconds.
+An unset `time_start` SHOULD be interpreted as "from the oldest stored entry".
+An unset `time_end` SHOULD be interpreted as "up to the youngest stored entry".
+
+If any of the content filter fields are set,
+namely `pubsub_topic`, `content_topic`, `time_start`, or `time_end`,
+the client MUST NOT set the `message_hashes` field.
+
+#### Message hash lookup queries
+
+A store query client MAY request the store service node to filter historical entries by one or
+more matching message hash keys.
+This type of query acts as a "lookup" against a message hash key or
+set of keys already known to the client.
+
+In order to perform a lookup query,
+the store query client MUST populate the `message_hashes` field with the list of message hash keys it wants to lookup in the store service node.
+
+If the `message_hashes` field is set,
+the client MUST NOT set any of the content filter fields,
+namely `pubsub_topic`, `content_topic`, `time_start`, or `time_end`.
+
+#### Presence queries
+
+A presence query is a special type of lookup query that allows a client to check for the presence of one or
+more messages in the store service node,
+without retrieving the full contents (values) of the messages.
+This can, for example, be used as part of a reliability mechanism,
+whereby store query clients verify that previously published messages have been successfully stored.
+
+In order to perform a presence query,
+the store query client MUST populate the `message_hashes` field in the `StoreQueryRequest` with the list of message hashes
+for which it wants to verify presence in the store service node.
+The `include_data` property MUST be set to `false`.
+The client SHOULD interpret every `message_hash` returned in the `messages` field of the `StoreQueryResponse` as present in the store.
+The client SHOULD assume that all other message hashes included in the original `StoreQueryRequest` but
+not in the `StoreQueryResponse` is not present in the store.
+
+#### Pagination info
+
+The store query client MAY include a message hash as `pagination_cursor`,
+to indicate at which key-value entry a store service node SHOULD start the query.
+The `pagination_cursor` is treated as exclusive
+and the corresponding entry will not be included in subsequent store query responses.
+
+For forward queries,
+only messages following (see [sorting](#waku-message-sorting)) the one indexed at `pagination_cursor`
+will be returned.
+For backward queries,
+only messages preceding (see [sorting](#waku-message-sorting)) the one indexed at `pagination_cursor`
+will be returned.
+
+If the store query client requires the store service node to perform a forward query,
+it MUST set `pagination_forward` to `true`.
+If the store query client requires the store service node to perform a backward query,
+it SHOULD set `pagination_forward` to `false`.
+By default, therefore, the store service node assumes pagination to be backward.
+
+A store query client MAY indicate the maximum number of matching entries it wants in the `StoreQueryResponse`,
+by setting the page size limit in the `pagination_limit` field.
+Note that a store service node MAY enforce its own limit
+if the `pagination_limit` is unset
+or larger than the service node's internal page size limit.
+
+See [pagination](#pagination) for more on how the pagination info is used in store transactions.
+
+### Store Query Response
+
+In response to any `StoreQueryRequest`,
+a store service node SHOULD respond with a `StoreQueryResponse` 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.
+A client node SHOULD consider all other status codes as error codes and
+assume that the requested operation had failed.
+In addition,
+the store service node MAY choose to provide a more detailed status description in the `status_desc` field.
+
+#### Filter matching
+
+For [content filtered queries](#content-filtered-queries),
+an entry in the store service node matches the filter criteria in a `StoreQueryRequest` if each of the following conditions are met:
+
+- its `content_topic` is in the request `content_topics` set
+and it was published on a matching `pubsub_topic` OR the request `content_topics` and
+`pubsub_topic` fields are unset
+- its `timestamp` is _larger or equal_ than the request `start_time` OR the request `start_time` is unset
+- its `timestamp` is _smaller_ than the request `end_time` OR the request `end_time` is unset
+
+Note that for content filtered queries, `start_time` is treated as _inclusive_ and
+`end_time` is treated as _exclusive_.
+
+For [message hash lookup queries](#message-hash-lookup-queries),
+an entry in the store service node matches the filter criteria if its `message_hash` is in the request `message_hashes` set.
+
+The store service node SHOULD respond with an error code and
+discard the request if the store query request contains both content filter criteria
+and message hashes.
+
+#### Populating response messages
+
+The store service node SHOULD populate the `messages` field in the response
+only with entries matching the filter criteria provided in the corresponding request.
+Regardless of whether the response is to a _forward_ or _backward_ query,
+the `messages` field in the response MUST be ordered in a forward direction
+according to the [message sorting rules](#waku-message-sorting).
+
+If the corresponding `StoreQueryRequest` has `include_data` set to true,
+the service node SHOULD populate both the `message_hash` and
+`message` for each entry in the response.
+In all other cases,
+the store service node SHOULD populate only the `message_hash` field for each entry in the response.
+
+#### Paginating the response
+
+The response SHOULD NOT contain more `messages` than the `pagination_limit` provided in the corresponding `StoreQueryRequest`.
+It is RECOMMENDED that the store node defines its own maximum page size internally.
+If the `pagination_limit` in the request is unset,
+or exceeds this internal maximum page size,
+the store service node SHOULD ignore the `pagination_limit` field and
+apply its own internal maximum page size.
+
+In response to a _forward_ `StoreQueryRequest`:
+
+- if the `pagination_cursor` is set,
+  the store service node SHOULD populate the `messages` field
+  with matching entries following the `pagination_cursor` (exclusive).
+- if the `pagination_cursor` is unset,
+  the store service node SHOULD populate the `messages` field
+  with matching entries from the first entry in the store.
+- if there are still more matching entries in the store
+  after the maximum page size is reached while populating the response,
+  the store service node SHOULD populate the `pagination_cursor` in the `StoreQueryResponse`
+  with the message hash key of the _last_ entry _included_ in the response.
+
+In response to a _backward_ `StoreQueryRequest`:
+
+- if the `pagination_cursor` is set,
+  the store service node SHOULD populate the `messages` field
+  with matching entries preceding the `pagination_cursor` (exclusive).
+- if the `pagination_cursor` is unset,
+  the store service node SHOULD populate the `messages` field
+  with matching entries from the last entry in the store.
+- if there are still more matching entries in the store
+  after the maximum page size is reached while populating the response,
+  the store service node SHOULD populate the `pagination_cursor` in the `StoreQueryResponse`
+  with the message hash key of the _first_ entry _included_ in the response.
+
+### Security Consideration
+
+The main security consideration while using this protocol is that a querying node has to reveal its content filters of interest to the queried node,
 hence potentially compromising their privacy.
 
-## Future Work
+#### Adversarial Model
 
-- **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.  
-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).
-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.
+Any peer running the `WAKU2-STORE` protocol, i.e.
+both the querying node and the queried node, are considered as an adversary.
+Furthermore,
+we currently consider the adversary as a passive entity that attempts to collect information from other peers to conduct an attack but
+it does so without violating protocol definitions and instructions.
+As we evolve the protocol,
+further adversarial models will be considered.
+For example, under the passive adversarial model,
+no malicious node hides or
+lies about the history of messages as it is against the description of the `WAKU2-STORE` protocol.
+
+The following are not considered as part of the adversarial model:
+
+- An adversary with a global view of all the peers and their connections.
+- An adversary that can eavesdrop on communication links between arbitrary pairs of peers (unless the adversary is one end of the communication).
+Specifically, the communication channels are assumed to be secure.
+
+### 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](/waku/standards/core/14/message.md) they are interested in.  
+As such, no adversary in the `WAKU2-STORE` protocol would be able to learn which peer is interested in which content filters i.e.,
+content topics of [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md).
+The current version of the `WAKU2-STORE` protocol does not provide anonymity for historical queries,
+as the querying node needs to directly connect to another node in the `WAKU2-STORE` protocol and
+explicitly disclose the content filters of its interest to retrieve the corresponding messages.
 However, one can consider preserving anonymity through one of the following ways:
-  - By hiding the source of the request i.e., anonymous communication.
-  That is the querying node shall hide all its PII in its history 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 historical requests
-  does not embody any piece of PII, otherwise,
-  such data fields must be treated carefully to achieve query anonymity.
-  <!-- TODO: if nodes have to disclose their PeerIDs
-  (e.g., for authentication purposes) when connecting to other nodes
-  in the store protocol,
-  then Tor does not preserve anonymity since it only helps in hiding the IP.
-  So, the PeerId usage in switches must be investigated further.
-  Depending on how PeerId is used, one may be able to link between a querying node
-  and its queried topics despite hiding the IP address-->
-  - By deploying secure 2-party computations in which the querying node
-  obtains the historical messages of a certain topic,
-  the queried node learns nothing about the query.
-  Examples of such 2PC protocols are secure one-way Private Set Intersections (PSI).
-  <!-- TODO: add a reference for PSIs? -->
-  <!-- TODO: more techniques to be included -->
+
+- By hiding the source of the request i.e., anonymous communication.
+That is the querying node shall hide all its PII in its history 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 historical requests does not embody any piece of PII, otherwise,
+such data fields must be treated carefully to achieve query anonymity.
+<!-- TODO: if nodes have to disclose their PeerIDs
+(e.g., for authentication purposes) when connecting to other nodes in the store protocol,
+then Tor does not preserve anonymity since it only helps in hiding the IP.
+So, the PeerId usage in switches must be investigated further.
+Depending on how PeerId is used, one may be able to link between a querying node 
+and its queried topics despite hiding the IP address-->
+- By deploying secure 2-party computations
+in which the querying node obtains the historical messages of a certain topic,
+the queried node learns nothing about the query.
+Examples of such 2PC protocols are secure one-way Private Set Intersections (PSI).
+<!-- TODO: add a reference for PSIs? --> <!-- TODO: more techniques to be included -->
 <!-- TODO: Censorship resistant:
 this is about a node that hides the historical messages from other nodes.
-This attack is not included in the specs
-since it does not fit the passive adversarial model
-(the attacker needs to deviate from the store protocol).-->
+This attack is not included in the specs since it does not fit the
+passive adversarial model (the attacker needs to deviate from the store protocol).-->
 
-- **Robust and verifiable timestamps**:
-Messages timestamp is a way to show that the message existed
-prior to some point in time.
+- **Robust and verifiable timestamps**: Messages timestamp is a way to show that
+the message existed prior to some point in time.
 However, the lack of timestamp verifiability can create room for a range of attacks,
 including injecting messages with invalid timestamps pointing to the far future.
 To better understand the attack,
@@ -317,31 +408,25 @@ that are sorted based on their timestamp.
 An attacker sends a message with an arbitrary large timestamp e.g.,
 10 hours ahead of the correct clock `(m',2021-01-01 10:00:30)`.
 The store node places `m'` at the end of the list,
-
-```text
-(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20),(m',2021-01-01 10:00:30).
-```
-
+`(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20),
+(m',2021-01-01 10:00:30)`.
 Now another message arrives with a valid timestamp e.g.,
 `(m11, 2021-01-01 00:00:45)`.
 However, since its timestamp precedes the malicious message `m'`,
 it gets placed before `m'` in the list i.e.,
-
-```text
-(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20), (m11, 2021-01-01 00:00:45), (m',2021-01-01 10:00:30).
-```
-
+`(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20),
+(m11, 2021-01-01 00:00:45), (m',2021-01-01 10:00:30)`.
 In fact, for the next 10 hours,
 `m'` will always be considered as the most recent message and
-served as the last message to the querying nodes irrespective
-of how many other messages arrive afterward.
+served as the last message to the querying nodes irrespective of how many other
+messages arrive afterward.
 
-A robust and verifiable timestamp allows the receiver of a message
-to verify that a message has been generated prior to the claimed timestamp.
+A robust and verifiable timestamp allows the receiver of a message to verify that
+a message has been generated prior to the claimed timestamp.
 One solution is the use of [open timestamps](https://opentimestamps.org/) e.g.,
 block height in Blockchain-based timestamps.
-That is, messages contain the most recent block height
-perceived by their senders at the time of message generation.
+That is, messages contain the most recent block height perceived by their senders
+at the time of message generation.
 This proves accuracy within a range of minutes (e.g., in Bitcoin blockchain) or
 seconds (e.g., in Ethereum 2.0) from the time of origination.
 
@@ -352,7 +437,6 @@ Copyright and related rights waived via
 
 ## References
 
-1. [14/WAKU2-MESSAGE](../14/message.md)
+1. [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md)
 2. [protocol buffers v3](https://developers.google.com/protocol-buffers/)
-3. [11/WAKU2-RELAY](../11/relay.md)
-4. [Open timestamps](https://opentimestamps.org/)
+3. [Open timestamps](https://opentimestamps.org/)

waku/standards/core/14/message.md

@@ -118,7 +118,7 @@ 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 [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md).
 Waku Noise protocol provides symmetric encryption and asymmetric key exchange.
 
 Any `version` value not included in this list is reserved for future specification.
@@ -254,5 +254,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 - [6/WAKU1](../../legacy/6/waku1.md)
 - [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))
+- [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
 - [62/STATUS-PAYLOADS](../../../../status/62/payloads.md/#clock-vs-timestamp-and-message-ordering)

waku/standards/core/15/bridge.md

@@ -7,24 +7,38 @@ tags: waku-core
 editor: Hanno Cornelius <hanno@status.im>
 ---
 
-A bridge between Waku v1 and Waku v2.
+## Abstract
 
-## Bridge
+This specification describes how [6/WAKU1](/waku/standards/legacy/6/waku1.md)
+traffic can be used with [10/WAKU2](/waku/standards/core/10/waku2.md) networks.
+
+## Wire Format
+
+The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
+“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
+“OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt).
 
 A bridge requires supporting both Waku versions:
 
-* Waku v1 - using devp2p RLPx protocol
-* Waku v2 - using libp2p protocols
+* [6/WAKU1](/waku/standards/legacy/6/waku1.md) - using devp2p RLPx protocol
+* [10/WAKU2](/waku/standards/core/10/waku2.md) - using libp2p protocols
 
-Packets received on the Waku v1 network SHOULD be published just once on the
-Waku v2 network. More specifically, the bridge SHOULD publish
-this through the Waku Relay (PubSub domain).
+## Publishing Packets
 
-Publishing such packet will require the creation of a new `Message` with a
-new `WakuMessage` as data field. The `data` and `topic` field from the Waku v1
-`Envelope` MUST be copied to the `payload` and `contentTopic` fields of the
-`WakuMessage`. Other fields such as nonce, expiry and ttl will be dropped as
-they become obsolete in Waku v2.
+Packets received on [6/WAKU1](/waku/standards/legacy/6/waku1.md) networks
+SHOULD be published just once on [10/WAKU2](/waku/standards/core/10/waku2.md) networks.
+More specifically, the bridge SHOULD publish
+this through [11/WAKU2-RELAY](/waku/standards/core/11/relay.md) (PubSub domain).
+
+When publishing such packet,
+the creation of a new `Message` with a new `WakuMessage` as data field is REQUIRED.
+The `data` and
+`topic` field, from the [6/WAKU1](/waku/standards/legacy/6/waku1.md) `Envelope`,
+MUST be copied to the `payload` and `content_topic` fields of the `WakuMessage`.
+See [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md#wire-format)
+for message format details.
+Other fields such as `nonce`, `expiry` and
+`ttl` will be dropped as they become obsolete in [10/WAKU2](/waku/standards/core/10/waku2.md).
 
 Before this is done, the usual envelope verification still applies:
 
@@ -32,37 +46,54 @@ Before this is done, the usual envelope verification still applies:
 * PoW verification
 * Size verification
 
-Bridging SHOULD occur through the `WakuRelay`, but it MAY also be done on other Waku
-v2 protocols (e.g. `WakuFilter`). The latter is however not advised as it will
-increase the complexity of the bridge and because of the
-[Security Considerations](#security-considerations) explained further below.
+Bridging SHOULD occur through the [11/WAKU2-RELAY](/waku/standards/core/11/relay.md),
+but it MAY also be done on other [10/WAKU2](/waku/standards/core/10/waku2.md) protocols
+(e.g. [12/WAKU2-FILTER](/waku/standards/core/12/filter.md)).
+The latter is however not advised as it will
+increase the complexity of the bridge and
+because of the [Security Considerations](#security-considerations) explained further below.
 
-Packets received on the Waku v2 network SHOULD be posted just once on the Waku
-v1 network. The Waku v2 `WakuMessage` contains only the `payload` and
-`contentTopic` fields. The bridge MUST create a new Waku v1 `Envelope` and
-copy over the `payload` and `contentFilter` fields to the `data` and `topic`
-fields. Next, before posting on the network, the bridge MUST set a new expiry
-and ttl and do the PoW nonce calculation.
+Packets received on [10/WAKU2](/waku/standards/core/10/waku2.md) networks,
+SHOULD be posted just once on [6/WAKU1](/waku/standards/legacy/6/waku1.md) networks.
+The [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md) contains only the `payload` and
+`contentTopic` fields.
+The bridge MUST create a new [6/WAKU1](/waku/standards/legacy/6/waku1.md) `Envelope` and
+copy over the `payload` and `contentFilter`
+fields to the `data` and `topic` fields.
+Next, before posting on the network,
+the bridge MUST set a new `expiry`, `ttl` and do the PoW `nonce` calculation.
 
 ### Security Considerations
 
-As mentioned above, a bridge will be posting new Waku v1 envelopes, which
-requires doing the PoW nonce calculation.
+As mentioned above,
+a bridge will be posting new [6/WAKU1](/waku/standards/legacy/6/waku1.md) envelopes,
+which requires doing the PoW `nonce` calculation.
 
-This could be a DoS attack vector, as the PoW calculation will make it more
-expensive to post the message compared to the original publishing on the Waku v2
-network. Low PoW setting will lower this problem, but it is likely that it is
-still more expensive.
+This could be a DoS attack vector,
+as the PoW calculation will make it more expensive to post the message
+compared to the original publishing on [10/WAKU2](/waku/standards/core/10/waku2.md) networks.
+Low PoW setting will lower this problem,
+but it is likely that it is still more expensive.
 
-For this reason, bridges SHOULD probably be run independently of other nodes, so
-that a bridge that gets overwhelmed does not disrupt regular Waku v2 to v2
+For this reason, it is RECOMMENDED to run bridges independently of other nodes,
+so that a bridge that gets overwhelmed does not disrupt regular Waku v2 to v2
 traffic.
 
 Bridging functionality SHOULD also be carefully implemented so that messages do
-not bounce back and forth between the two networks. The bridge SHOULD properly
-track messages with a seen filter so that no amplification can be achieved here.
+not bounce back and forth between the [10/WAKU2](/waku/standards/core/10/waku2.md) and
+[6/WAKU1](/waku/standards/legacy/6/waku1.md) networks.
+The bridge SHOULD properly track messages with a seen filter,
+so that no amplification occurs.
 
 ## Copyright
 
 Copyright and related rights waived via
 [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+* [6/WAKU1](/waku/standards/legacy/6/waku1.md)
+* [10/WAKU2](/waku/standards/core/10/waku2.md)
+* [11/WAKU2-RELAY](/waku/standards/core/11/relay.md)
+* [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md)
+* [12/WAKU2-FILTER](/waku/standards/core/12/filter.md)

waku/standards/core/17/rln-relay.md

@@ -18,7 +18,7 @@ This specification describes the `17/WAKU2-RLN-RELAY` protocol,
 which is an extension of [`11/WAKU2-RELAY`](../11/relay.md)
 to provide spam protection using [Rate Limiting Nullifiers (RLN)](../../../../vac/32/rln-v1.md).
 
-The security objective is to contain spam activity in the (64/WAKU-NETWORK)[]
+The security objective is to contain spam activity in the [64/WAKU-NETWORK](../64/network.md)
 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.
@@ -374,9 +374,10 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References
 
 1. [`11/WAKU2-RELAY`](../11/relay.md)
-2. [RLN](../../../../vac/32/rln-v1.md)
-3. [14/WAKU2-MESSAGE](../14/message.md)
-4. [RLN documentation](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view)
-5. [Public inputs to the RLN circuit](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Public-Inputs)
-6. [Shamir secret sharing scheme used in RLN](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Linear-Equation-amp-SSS)
-7. [RLN internal nullifier](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Nullifiers)
+2. [64/WAKU-NETWORK](../64/network.md)
+3. [RLN](../../../../vac/32/rln-v1.md)
+4. [14/WAKU2-MESSAGE](../14/message.md)
+5. [RLN documentation](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view)
+6. [Public inputs to the RLN circuit](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Public-Inputs)
+7. [Shamir secret sharing scheme used in RLN](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Linear-Equation-amp-SSS)
+8. [RLN internal nullifier](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Nullifiers)

waku/standards/core/19/lightpush.md

@@ -50,7 +50,7 @@ message PushRPC {
 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)
+or forward the `PushRequest` via 19/LIGHTPUSH on a [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/master/standards/application/dandelion.md)
 stem.
 If they are unable to do so for some reason,
 they SHOULD return an error code in `PushResponse`.
@@ -71,5 +71,5 @@ 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)
+* [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/master/standards/application/dandelion.md)
 * [17/WAKU2-RLN-RELAY](../17/rln-relay.md)

waku/standards/core/33/discv5.md

@@ -41,8 +41,8 @@ within the network.
 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)
+* [`DNS discovery`](/waku/standards/10/waku2.md/#discovery-domain) (based on [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459))
+* [`34/WAKU2-PEER-EXCHANGE`](/waku/standards/core/34/peer-exchange.md)
 * `33/WAKU2-DISCV5` (specified in this document)
 
 The purpose of ambient node discovery within [10/WAKU2](../10/waku2.md)
@@ -74,7 +74,7 @@ This also increases decentralization.
 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).
+and filtering Waku nodes based on whether they support [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md).
 This solution is more resilient towards eclipse attacks.
 However, this discovery method is very inefficient
 for small percentages of Waku nodes
@@ -205,20 +205,20 @@ raises research questions that we will address in future stages of our discv5 ro
 ## 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. [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. [`EIP-1459`](https://eips.ethereum.org/EIPS/eip-1459)
-1. [`GossipSub`](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
-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)
-1. [implementation: Go](https://github.com/status-im/go-waku/blob/master/waku/v2/discv5/discover.go)
+2. [`34/WAKU2-PEER-EXCHANGE`](/waku/standards/core/34/peer-exchange.md)
+3. [11/WAKU2-RELAY](../11/relay.md)
+4. [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
+5. [Node Discovery Protocol v5 (`discv5`)](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md)
+6. [`discv5` semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md).
+7. [`discv5` wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md)
+8. [`discv5` topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement)
+9. [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md)
+10. [`EIP-1459`](https://eips.ethereum.org/EIPS/eip-1459)
+11. [`GossipSub`](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
+12. [Waku discv5 roadmap discussion](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121)
+13. [discovery efficiency estimation](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121/8)
+14. [implementation: Nim](https://github.com/kaiserd/nim-eth/blob/add-selectable-protocol-id-static/eth/p2p/discoveryv5/encoding.nim)
+15. [implementation: Go](https://github.com/status-im/go-waku/blob/master/waku/v2/discv5/discover.go)
 
 ## Copyright
 

waku/standards/core/34/images/protocol.svg

@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="279pt" height="156pt" viewBox="0 0 279 156" version="1.1">
+<defs>
+<g>
+<symbol overflow="visible" id="glyph0-0">
+<path style="stroke:none;" d="M 0.640625 2.265625 L 0.640625 -9.015625 L 7.03125 -9.015625 L 7.03125 2.265625 Z M 1.359375 1.546875 L 6.328125 1.546875 L 6.328125 -8.296875 L 1.359375 -8.296875 Z M 1.359375 1.546875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-1">
+<path style="stroke:none;" d="M 5.265625 -5.921875 C 5.128906 -5.992188 4.984375 -6.046875 4.828125 -6.078125 C 4.679688 -6.117188 4.519531 -6.140625 4.34375 -6.140625 C 3.6875 -6.140625 3.179688 -5.925781 2.828125 -5.5 C 2.484375 -5.082031 2.3125 -4.476562 2.3125 -3.6875 L 2.3125 0 L 1.15625 0 L 1.15625 -7 L 2.3125 -7 L 2.3125 -5.90625 C 2.5625 -6.332031 2.878906 -6.648438 3.265625 -6.859375 C 3.648438 -7.066406 4.117188 -7.171875 4.671875 -7.171875 C 4.753906 -7.171875 4.84375 -7.164062 4.9375 -7.15625 C 5.03125 -7.144531 5.132812 -7.128906 5.25 -7.109375 Z M 5.265625 -5.921875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-2">
+<path style="stroke:none;" d="M 7.1875 -3.78125 L 7.1875 -3.21875 L 1.90625 -3.21875 C 1.957031 -2.425781 2.195312 -1.820312 2.625 -1.40625 C 3.050781 -1 3.644531 -0.796875 4.40625 -0.796875 C 4.84375 -0.796875 5.269531 -0.847656 5.6875 -0.953125 C 6.101562 -1.066406 6.515625 -1.226562 6.921875 -1.4375 L 6.921875 -0.359375 C 6.515625 -0.179688 6.09375 -0.046875 5.65625 0.046875 C 5.21875 0.140625 4.78125 0.1875 4.34375 0.1875 C 3.21875 0.1875 2.328125 -0.132812 1.671875 -0.78125 C 1.023438 -1.4375 0.703125 -2.320312 0.703125 -3.4375 C 0.703125 -4.582031 1.007812 -5.488281 1.625 -6.15625 C 2.25 -6.832031 3.085938 -7.171875 4.140625 -7.171875 C 5.078125 -7.171875 5.816406 -6.863281 6.359375 -6.25 C 6.910156 -5.644531 7.1875 -4.820312 7.1875 -3.78125 Z M 6.046875 -4.125 C 6.035156 -4.75 5.859375 -5.25 5.515625 -5.625 C 5.171875 -6 4.71875 -6.1875 4.15625 -6.1875 C 3.507812 -6.1875 2.992188 -6.003906 2.609375 -5.640625 C 2.222656 -5.285156 2 -4.78125 1.9375 -4.125 Z M 6.046875 -4.125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-3">
+<path style="stroke:none;" d="M 1.890625 -3.5 C 1.890625 -2.644531 2.0625 -1.976562 2.40625 -1.5 C 2.757812 -1.019531 3.238281 -0.78125 3.84375 -0.78125 C 4.457031 -0.78125 4.9375 -1.019531 5.28125 -1.5 C 5.632812 -1.976562 5.8125 -2.644531 5.8125 -3.5 C 5.8125 -4.34375 5.632812 -5.003906 5.28125 -5.484375 C 4.9375 -5.960938 4.457031 -6.203125 3.84375 -6.203125 C 3.238281 -6.203125 2.757812 -5.960938 2.40625 -5.484375 C 2.0625 -5.003906 1.890625 -4.34375 1.890625 -3.5 Z M 5.8125 -1.046875 C 5.570312 -0.628906 5.265625 -0.316406 4.890625 -0.109375 C 4.523438 0.0859375 4.082031 0.1875 3.5625 0.1875 C 2.71875 0.1875 2.03125 -0.148438 1.5 -0.828125 C 0.96875 -1.503906 0.703125 -2.394531 0.703125 -3.5 C 0.703125 -4.59375 0.96875 -5.476562 1.5 -6.15625 C 2.03125 -6.832031 2.71875 -7.171875 3.5625 -7.171875 C 4.082031 -7.171875 4.523438 -7.066406 4.890625 -6.859375 C 5.265625 -6.660156 5.570312 -6.351562 5.8125 -5.9375 L 5.8125 -7 L 6.953125 -7 L 6.953125 2.65625 L 5.8125 2.65625 Z M 5.8125 -1.046875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-4">
+<path style="stroke:none;" d="M 1.09375 -2.765625 L 1.09375 -7 L 2.234375 -7 L 2.234375 -2.8125 C 2.234375 -2.144531 2.363281 -1.644531 2.625 -1.3125 C 2.882812 -0.976562 3.269531 -0.8125 3.78125 -0.8125 C 4.40625 -0.8125 4.894531 -1.007812 5.25 -1.40625 C 5.613281 -1.800781 5.796875 -2.34375 5.796875 -3.03125 L 5.796875 -7 L 6.953125 -7 L 6.953125 0 L 5.796875 0 L 5.796875 -1.078125 C 5.515625 -0.648438 5.191406 -0.332031 4.828125 -0.125 C 4.460938 0.0820312 4.035156 0.1875 3.546875 0.1875 C 2.742188 0.1875 2.132812 -0.0625 1.71875 -0.5625 C 1.300781 -1.0625 1.09375 -1.796875 1.09375 -2.765625 Z M 3.984375 -7.171875 Z M 3.984375 -7.171875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-5">
+<path style="stroke:none;" d="M 5.671875 -6.796875 L 5.671875 -5.703125 C 5.347656 -5.867188 5.007812 -5.992188 4.65625 -6.078125 C 4.300781 -6.160156 3.9375 -6.203125 3.5625 -6.203125 C 3 -6.203125 2.570312 -6.113281 2.28125 -5.9375 C 2 -5.769531 1.859375 -5.507812 1.859375 -5.15625 C 1.859375 -4.882812 1.957031 -4.671875 2.15625 -4.515625 C 2.363281 -4.367188 2.773438 -4.226562 3.390625 -4.09375 L 3.78125 -4 C 4.601562 -3.832031 5.1875 -3.585938 5.53125 -3.265625 C 5.875 -2.941406 6.046875 -2.5 6.046875 -1.9375 C 6.046875 -1.28125 5.785156 -0.757812 5.265625 -0.375 C 4.753906 0 4.050781 0.1875 3.15625 0.1875 C 2.78125 0.1875 2.390625 0.148438 1.984375 0.078125 C 1.578125 0.00390625 1.144531 -0.101562 0.6875 -0.25 L 0.6875 -1.4375 C 1.113281 -1.21875 1.53125 -1.050781 1.9375 -0.9375 C 2.351562 -0.832031 2.765625 -0.78125 3.171875 -0.78125 C 3.710938 -0.78125 4.128906 -0.875 4.421875 -1.0625 C 4.710938 -1.25 4.859375 -1.507812 4.859375 -1.84375 C 4.859375 -2.15625 4.753906 -2.394531 4.546875 -2.5625 C 4.335938 -2.726562 3.875 -2.890625 3.15625 -3.046875 L 2.765625 -3.140625 C 2.046875 -3.285156 1.53125 -3.515625 1.21875 -3.828125 C 0.90625 -4.140625 0.75 -4.566406 0.75 -5.109375 C 0.75 -5.765625 0.976562 -6.269531 1.4375 -6.625 C 1.90625 -6.988281 2.570312 -7.171875 3.4375 -7.171875 C 3.851562 -7.171875 4.25 -7.140625 4.625 -7.078125 C 5 -7.015625 5.347656 -6.921875 5.671875 -6.796875 Z M 5.671875 -6.796875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-6">
+<path style="stroke:none;" d="M 2.34375 -8.984375 L 2.34375 -7 L 4.71875 -7 L 4.71875 -6.109375 L 2.34375 -6.109375 L 2.34375 -2.3125 C 2.34375 -1.738281 2.421875 -1.367188 2.578125 -1.203125 C 2.734375 -1.046875 3.050781 -0.96875 3.53125 -0.96875 L 4.71875 -0.96875 L 4.71875 0 L 3.53125 0 C 2.644531 0 2.03125 -0.164062 1.6875 -0.5 C 1.351562 -0.832031 1.1875 -1.4375 1.1875 -2.3125 L 1.1875 -6.109375 L 0.34375 -6.109375 L 0.34375 -7 L 1.1875 -7 L 1.1875 -8.984375 Z M 2.34375 -8.984375 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-7">
+<path style="stroke:none;" d="M 2.3125 -1.046875 L 2.3125 2.65625 L 1.15625 2.65625 L 1.15625 -7 L 2.3125 -7 L 2.3125 -5.9375 C 2.5625 -6.351562 2.867188 -6.660156 3.234375 -6.859375 C 3.597656 -7.066406 4.039062 -7.171875 4.5625 -7.171875 C 5.40625 -7.171875 6.09375 -6.832031 6.625 -6.15625 C 7.15625 -5.476562 7.421875 -4.59375 7.421875 -3.5 C 7.421875 -2.394531 7.15625 -1.503906 6.625 -0.828125 C 6.09375 -0.148438 5.40625 0.1875 4.5625 0.1875 C 4.039062 0.1875 3.597656 0.0859375 3.234375 -0.109375 C 2.867188 -0.316406 2.5625 -0.628906 2.3125 -1.046875 Z M 6.234375 -3.5 C 6.234375 -4.34375 6.054688 -5.003906 5.703125 -5.484375 C 5.359375 -5.960938 4.882812 -6.203125 4.28125 -6.203125 C 3.664062 -6.203125 3.179688 -5.960938 2.828125 -5.484375 C 2.484375 -5.003906 2.3125 -4.34375 2.3125 -3.5 C 2.3125 -2.644531 2.484375 -1.976562 2.828125 -1.5 C 3.179688 -1.019531 3.664062 -0.78125 4.28125 -0.78125 C 4.882812 -0.78125 5.359375 -1.019531 5.703125 -1.5 C 6.054688 -1.976562 6.234375 -2.644531 6.234375 -3.5 Z M 6.234375 -3.5 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-8">
+<path style="stroke:none;" d="M 3.921875 -6.1875 C 3.304688 -6.1875 2.816406 -5.945312 2.453125 -5.46875 C 2.097656 -4.988281 1.921875 -4.332031 1.921875 -3.5 C 1.921875 -2.65625 2.097656 -1.992188 2.453125 -1.515625 C 2.804688 -1.035156 3.296875 -0.796875 3.921875 -0.796875 C 4.535156 -0.796875 5.019531 -1.035156 5.375 -1.515625 C 5.726562 -2.003906 5.90625 -2.664062 5.90625 -3.5 C 5.90625 -4.320312 5.726562 -4.972656 5.375 -5.453125 C 5.019531 -5.941406 4.535156 -6.1875 3.921875 -6.1875 Z M 3.921875 -7.171875 C 4.921875 -7.171875 5.703125 -6.84375 6.265625 -6.1875 C 6.835938 -5.539062 7.125 -4.644531 7.125 -3.5 C 7.125 -2.351562 6.835938 -1.453125 6.265625 -0.796875 C 5.703125 -0.140625 4.921875 0.1875 3.921875 0.1875 C 2.910156 0.1875 2.117188 -0.140625 1.546875 -0.796875 C 0.984375 -1.453125 0.703125 -2.351562 0.703125 -3.5 C 0.703125 -4.644531 0.984375 -5.539062 1.546875 -6.1875 C 2.117188 -6.84375 2.910156 -7.171875 3.921875 -7.171875 Z M 3.921875 -7.171875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-9">
+<path style="stroke:none;" d="M 7.015625 -4.21875 L 7.015625 0 L 5.875 0 L 5.875 -4.1875 C 5.875 -4.851562 5.742188 -5.347656 5.484375 -5.671875 C 5.222656 -6.003906 4.835938 -6.171875 4.328125 -6.171875 C 3.703125 -6.171875 3.207031 -5.972656 2.84375 -5.578125 C 2.488281 -5.179688 2.3125 -4.640625 2.3125 -3.953125 L 2.3125 0 L 1.15625 0 L 1.15625 -7 L 2.3125 -7 L 2.3125 -5.90625 C 2.59375 -6.332031 2.914062 -6.648438 3.28125 -6.859375 C 3.65625 -7.066406 4.085938 -7.171875 4.578125 -7.171875 C 5.378906 -7.171875 5.984375 -6.921875 6.390625 -6.421875 C 6.804688 -5.921875 7.015625 -5.1875 7.015625 -4.21875 Z M 7.015625 -4.21875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-10">
+<path style="stroke:none;" d="M 5.8125 -5.9375 L 5.8125 -9.71875 L 6.953125 -9.71875 L 6.953125 0 L 5.8125 0 L 5.8125 -1.046875 C 5.570312 -0.628906 5.265625 -0.316406 4.890625 -0.109375 C 4.523438 0.0859375 4.082031 0.1875 3.5625 0.1875 C 2.71875 0.1875 2.03125 -0.148438 1.5 -0.828125 C 0.96875 -1.503906 0.703125 -2.394531 0.703125 -3.5 C 0.703125 -4.59375 0.96875 -5.476562 1.5 -6.15625 C 2.03125 -6.832031 2.71875 -7.171875 3.5625 -7.171875 C 4.082031 -7.171875 4.523438 -7.066406 4.890625 -6.859375 C 5.265625 -6.660156 5.570312 -6.351562 5.8125 -5.9375 Z M 1.890625 -3.5 C 1.890625 -2.644531 2.0625 -1.976562 2.40625 -1.5 C 2.757812 -1.019531 3.238281 -0.78125 3.84375 -0.78125 C 4.457031 -0.78125 4.9375 -1.019531 5.28125 -1.5 C 5.632812 -1.976562 5.8125 -2.644531 5.8125 -3.5 C 5.8125 -4.34375 5.632812 -5.003906 5.28125 -5.484375 C 4.9375 -5.960938 4.457031 -6.203125 3.84375 -6.203125 C 3.238281 -6.203125 2.757812 -5.960938 2.40625 -5.484375 C 2.0625 -5.003906 1.890625 -4.34375 1.890625 -3.5 Z M 1.890625 -3.5 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-11">
+<path style="stroke:none;" d=""/>
+</symbol>
+<symbol overflow="visible" id="glyph0-12">
+<path style="stroke:none;" d="M 1.25 -9.328125 L 2.515625 -9.328125 L 2.515625 -1.0625 L 7.0625 -1.0625 L 7.0625 0 L 1.25 0 Z M 1.25 -9.328125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-13">
+<path style="stroke:none;" d="M 1.203125 -7 L 2.359375 -7 L 2.359375 0 L 1.203125 0 Z M 1.203125 -9.71875 L 2.359375 -9.71875 L 2.359375 -8.265625 L 1.203125 -8.265625 Z M 1.203125 -9.71875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-14">
+<path style="stroke:none;" d="M 9.359375 -6.296875 L 2.921875 -4 L 9.359375 -1.71875 L 9.359375 -0.59375 L 1.359375 -3.5 L 1.359375 -4.53125 L 9.359375 -7.4375 Z M 9.359375 -6.296875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-15">
+<path style="stroke:none;" d="M 1.25 -9.328125 L 7.15625 -9.328125 L 7.15625 -8.265625 L 2.515625 -8.265625 L 2.515625 -5.5 L 6.953125 -5.5 L 6.953125 -4.4375 L 2.515625 -4.4375 L 2.515625 -1.0625 L 7.265625 -1.0625 L 7.265625 0 L 1.25 0 Z M 1.25 -9.328125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-16">
+<path style="stroke:none;" d="M 1.25 -9.328125 L 2.953125 -9.328125 L 7.09375 -1.53125 L 7.09375 -9.328125 L 8.3125 -9.328125 L 8.3125 0 L 6.609375 0 L 2.484375 -7.796875 L 2.484375 0 L 1.25 0 Z M 1.25 -9.328125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-17">
+<path style="stroke:none;" d="M 5.6875 -4.375 C 5.957031 -4.28125 6.21875 -4.082031 6.46875 -3.78125 C 6.726562 -3.488281 6.984375 -3.078125 7.234375 -2.546875 L 8.515625 0 L 7.171875 0 L 5.96875 -2.390625 C 5.664062 -3.015625 5.367188 -3.425781 5.078125 -3.625 C 4.785156 -3.832031 4.390625 -3.9375 3.890625 -3.9375 L 2.515625 -3.9375 L 2.515625 0 L 1.25 0 L 1.25 -9.328125 L 4.109375 -9.328125 C 5.171875 -9.328125 5.960938 -9.101562 6.484375 -8.65625 C 7.015625 -8.207031 7.28125 -7.535156 7.28125 -6.640625 C 7.28125 -6.054688 7.140625 -5.566406 6.859375 -5.171875 C 6.585938 -4.785156 6.195312 -4.519531 5.6875 -4.375 Z M 2.515625 -8.296875 L 2.515625 -4.984375 L 4.109375 -4.984375 C 4.710938 -4.984375 5.171875 -5.125 5.484375 -5.40625 C 5.796875 -5.6875 5.953125 -6.097656 5.953125 -6.640625 C 5.953125 -7.179688 5.796875 -7.59375 5.484375 -7.875 C 5.171875 -8.15625 4.710938 -8.296875 4.109375 -8.296875 Z M 2.515625 -8.296875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-18">
+<path style="stroke:none;" d="M 1.359375 -6.296875 L 1.359375 -7.4375 L 9.359375 -4.53125 L 9.359375 -3.5 L 1.359375 -0.59375 L 1.359375 -1.71875 L 7.796875 -4 Z M 1.359375 -6.296875 "/>
+</symbol>
+</g>
+</defs>
+<g id="surface3285">
+<rect x="0" y="0" width="279" height="156" style="fill:rgb(100%,100%,100%);fill-opacity:1;stroke:none;"/>
+<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 30.7 0 L 34.7 0 L 34.7 1.2 L 30.7 1.2 Z M 30.7 0 " transform="matrix(20,0,0,20,-612,2)"/>
+<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
+  <use xlink:href="#glyph0-1" x="10" y="18.005968"/>
+  <use xlink:href="#glyph0-2" x="15" y="18.005968"/>
+  <use xlink:href="#glyph0-3" x="22.777778" y="18.005968"/>
+  <use xlink:href="#glyph0-4" x="30.833333" y="18.005968"/>
+  <use xlink:href="#glyph0-2" x="38.888889" y="18.005968"/>
+  <use xlink:href="#glyph0-5" x="46.666667" y="18.005968"/>
+  <use xlink:href="#glyph0-6" x="53.333333" y="18.005968"/>
+  <use xlink:href="#glyph0-2" x="58.333333" y="18.005968"/>
+  <use xlink:href="#glyph0-1" x="66.111111" y="18.005968"/>
+</g>
+<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 40.5 0 L 44.5 0 L 44.5 1.2 L 40.5 1.2 Z M 40.5 0 " transform="matrix(20,0,0,20,-612,2)"/>
+<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
+  <use xlink:href="#glyph0-1" x="206" y="18.005968"/>
+  <use xlink:href="#glyph0-2" x="211" y="18.005968"/>
+  <use xlink:href="#glyph0-5" x="218.777778" y="18.005968"/>
+  <use xlink:href="#glyph0-7" x="225.444444" y="18.005968"/>
+  <use xlink:href="#glyph0-8" x="233.5" y="18.005968"/>
+  <use xlink:href="#glyph0-9" x="241.277778" y="18.005968"/>
+  <use xlink:href="#glyph0-10" x="249.333333" y="18.005968"/>
+  <use xlink:href="#glyph0-2" x="257.388889" y="18.005968"/>
+  <use xlink:href="#glyph0-1" x="265.166667" y="18.005968"/>
+</g>
+<path style="fill:none;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 32.7 1.2 L 32.7 7.6 " transform="matrix(20,0,0,20,-612,2)"/>
+<path style="fill:none;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 42.5 1.2 L 42.5 7.6 " transform="matrix(20,0,0,20,-612,2)"/>
+<path style="fill:none;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 32.7 2.4 L 42.016211 3.445703 " transform="matrix(20,0,0,20,-612,2)"/>
+<path style="fill-rule:evenodd;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 42.388867 3.4875 L 41.864063 3.680273 L 42.016211 3.445703 L 41.919922 3.183398 Z M 42.388867 3.4875 " transform="matrix(20,0,0,20,-612,2)"/>
+<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
+  <use xlink:href="#glyph0-11" x="96" y="106.005968"/>
+  <use xlink:href="#glyph0-12" x="100.166667" y="106.005968"/>
+  <use xlink:href="#glyph0-13" x="107.388889" y="106.005968"/>
+  <use xlink:href="#glyph0-5" x="111" y="106.005968"/>
+  <use xlink:href="#glyph0-6" x="117.666667" y="106.005968"/>
+  <use xlink:href="#glyph0-14" x="122.666667" y="106.005968"/>
+  <use xlink:href="#glyph0-15" x="133.5" y="106.005968"/>
+  <use xlink:href="#glyph0-16" x="141.555556" y="106.005968"/>
+  <use xlink:href="#glyph0-17" x="151" y="106.005968"/>
+  <use xlink:href="#glyph0-18" x="159.888889" y="106.005968"/>
+</g>
+<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
+  <use xlink:href="#glyph0-1" x="112" y="52.005968"/>
+  <use xlink:href="#glyph0-2" x="117" y="52.005968"/>
+  <use xlink:href="#glyph0-3" x="124.777778" y="52.005968"/>
+  <use xlink:href="#glyph0-4" x="132.833333" y="52.005968"/>
+  <use xlink:href="#glyph0-2" x="140.888889" y="52.005968"/>
+  <use xlink:href="#glyph0-5" x="148.666667" y="52.005968"/>
+  <use xlink:href="#glyph0-6" x="155.333333" y="52.005968"/>
+</g>
+<path style="fill:none;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 42.5 5.3 L 33.184375 6.250586 " transform="matrix(20,0,0,20,-612,2)"/>
+<path style="fill-rule:evenodd;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 32.811133 6.288672 L 33.283203 5.989258 L 33.184375 6.250586 L 33.333984 6.486523 Z M 32.811133 6.288672 " transform="matrix(20,0,0,20,-612,2)"/>
+</g>
+</svg>

waku/standards/core/34/peer-exchange.md

@@ -0,0 +1,231 @@
+---
+slug: 34
+title: 34/WAKU2-PEER-EXCHANGE
+name: Waku2 Peer Exchange
+status: draft
+category: Standards Track
+tags: waku/core-protocol
+editor: Hanno Cornelius <hanno@status.im> 
+contributors:
+- Daniel Kaiser <danielkaiser@status.im>
+---
+
+## Abstract
+
+This document specifies a simple request-response peer exchange protocol.
+Responders send information about a requested number of peers.
+The main purpose of this protocol is providing resource restricted devices with peers.
+
+***Protocol Identifier***
+
+> /vac/waku/peer-exchange/2.0.0-alpha1
+
+## Background and Motivation
+
+It may not be feasible, on resource restricted devices,
+to take part in distributed random sampling ambient peer discovery protocols,
+such as [33/WAKU2-DISCV5](/waku/standards/core/33/discv5.md).
+The Waku peer discovery protocol, specified in this document,
+allows resource restricted devices to request a list of peers from a service node.
+Network parameters necessary to connect to this service node COULD be learned
+from a static bootstrapping method or
+using [EIP-1459: Node Discovery via DNS](https://eips.ethereum.org/EIPS/eip-1459).
+The advantage of using Waku peer exchange to discover new peers,
+compared to relying on a static peer list or DNS discovery, is a more even load distribution.
+If a lot of resource restricted nodes would use the same service nodes as relay
+or store nodes, the load on these would be very high.
+Heavily used static nodes also add a centralized element.
+Downtime of such a node might significantly impact the network.
+
+However, the resource efficiency of this protocol comes at an anonymity cost,
+which is explained in the
+[Security/Privacy Considerations](#security-considerations) section.
+This protocol SHOULD only be used if [33/WAKU2-DISCV5](/waku/standards/core/33/discv5.md) is infeasible.
+
+## Theory and Protocol Semantics
+
+The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
+“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
+“OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+The peer exchange protocol, specified in this document,
+is a simple request-response protocol.
+As Figure 1 illustrates, the requesting node sends a request to a peer,
+which acts as the responder.
+The responder replies with a list of ENRs as specified in [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md).
+The [multiaddresses](https://docs.libp2p.io/concepts/addressing/)
+used to connect to the respective peers can be extracted from the ENRs.
+
+![Figure 1: The responder provides a list of ENRs to the requester. These ENRs contain the information necessary for connecting to the respective peers.](./images/protocol.svg)
+
+In order to protect its anonymity,
+the responder MUST NOT provide peers from its actively used peer list
+as this opens pathways to *Neighbourhood Surveillance* attacks, as described in the
+[Security/Privacy Considerations Section](#security-considerations).
+The responder SHOULD provide a set of peers
+that has been retrieved using ambient peer discovery methods supporting random sampling,
+e.g. [33/WAKU2-DISCV5](/waku/standards/core/33/discv5.md).
+This both protects the responder's anonymity as well as helps distributing load.
+
+To allow for fast responses, responders SHOULD retrieve peers unsolicited
+(before receiving a query) and
+maintain a queue of peers for the purpose of providing them in peer exchange responses.
+To get the best anonymity properties with respect to response peer sets,
+responders SHOULD use each of these peers only once.
+
+To save bandwidth, and as a trade off to anonymity,
+responders MAY maintain a larger cache of exchange peers and
+randomly sample response sets from this local cache.
+The size of the cache SHOULD be large enough to allow randomly sampling peer sets
+that (on average) do not overlap too much.
+The responder SHOULD periodically replace the oldest peers in the cache.
+The RECOMMENDED options for the cache size are described in the
+[Implementation Suggestions Section](#implementation-suggestions).
+
+Requesters, in the context of the specified peer exchange protocol,
+SHOULD be resource restricted devices.
+While any node could technically act as a requester,
+using the peer exchange protocol comes with two drawbacks:
+
+* reducing [anonymity](#security-considerations)
+* causing load on responder nodes
+
+## Wire Format Specification
+
+```protobuf
+syntax = "proto3";
+
+message PeerInfo {
+  bytes enr = 1;
+}
+
+message PeerExchangeQuery {
+  uint64 num_peers = 1;
+}
+
+message PeerExchangeResponse {
+  repeated PeerInfo peer_infos = 1;
+}
+
+message PeerExchangeRPC {
+  PeerExchangeQuery query = 1;
+  PeerExchangeResponse response = 2;
+}
+
+```
+
+The `enr` field contains a Waku ENR as specified in [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md).
+
+Requesters send a `PeerExchangeQuery` to a peer.
+Responders SHOULD include a maximum of `num_peers` `PeerInfo` instances into a response.
+Responders send a `PeerExchangeResponse` to requesters
+containing a list of `PeerInfo` instances, which in turn hold an ENR.
+
+## Implementation Suggestions
+
+### Discovery Interface
+
+Implementations can implement the libp2p discovery interface:
+
+* [nim](https://github.com/status-im/nim-libp2p/issues/140)
+* [javascript](https://github.com/libp2p/js-libp2p-interfaces/tree/master/packages/interface-peer-discovery).
+
+### Exchange Peer Cache Size
+
+The size of the (optional) exchange peer cache discussed in
+[Theory and Protocol Semantics](#theory-and-protocol-semantics)
+depends on the average number of requested peers,
+which is expected to be the outbound degree of the underlying
+[libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md)
+mesh network.
+The RECOMMENDED value for this outbound degree is 6 (see parameter `D` in [29/WAKU2-CONFIG](/waku/informational/29/config.md)).
+It is RECOMMENDED for the cache to hold at least 10 times as many peers (60).
+
+The RECCOMENDED cache size also depends on the number of requesters a responder
+is expected to serve within a *refresh cycle*.
+A refresh cycle is the time interval in which all peers in the cache
+are expected to be replaced.
+If the number of requests expected per refresh cycle exceeds 600
+(10 times the above recommended 60),
+it is RECOMMENDED to increase the cache size to at least a tenth of that number.
+
+## Security Considerations
+
+### Privacy and Anonymity
+
+The peer exchange protocol specified in this document comes with anonymity and
+security implications.
+We differentiate these implications into the requester and responder side, respectively.
+
+### Requester
+
+With a simple peer exchange protocol,
+the requester is inherently susceptible to both *neighbourhood surveillance* and
+*controlled neighbourhood* attacks.
+
+To mount a *neighbourhood surveillance* attack,
+an attacker has to connect to the peers of the victim node.
+The peer exchange protocol allows a malicious responder to easily get into this position.
+The responder connects to a set of peers and
+simply returns this set of peers to the requester.
+
+The peer exchange protocol also makes it much easier to get into the position
+required for the *controlled neighbourhood* attack:
+A malicious responder provides controlled peers in the response peer list.
+
+More on these attacks may be found in our [research log article](https://vac.dev/wakuv2-relay-anon).
+
+As a weak mitigation the requester MAY ask several peers and
+select a subset of the returned peers.
+
+### Responder
+
+Responders that answer with active mesh peers are more vulnerable
+to a *neighbourhood surveillance* attack.
+Responding with the set of active mesh peers allows a malicious requester to
+get into the required position more easily.
+It takes away the first hurdle of the *neighbourhood surveillance* attack:
+The attacker knows which peers to try to connect to.
+This increased vulnerability can be avoided by only responding
+with randomly sampled sets of peers,
+e.g. by requesting a random peer set via [33/WAKU2-DISCV5](/waku/standards/core/33/discv5.md).
+(As stated in the [Theory and Protocol Semantics Section](#theory-and-protocol-semantics),
+these peer sets SHOULD be retrieved unsolicitedly before
+receiving requests to achieve faster response times.)
+
+Responders are also susceptible to amplification DoS attacks.
+Requesters send a simple message request which causes responders to
+engage in ambient peer discovery to retrieve a new random peer set.
+As a mitigation, responders MAY feature a `seen cache` for requests and
+only answer once per time interval.
+The exchange-peer cache discussed in [Theory and Protocol Semantics Section](#theory-and-protocol-semantics)
+also provides mitigation.
+Still, frequent queries can tigger the refresh cycle more often.
+The `seen cache` MAY be used in conjunction to provide additional mitigation.
+
+### Further Considerations
+
+The response field contains ENRs as specified in [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md).
+While ENRs contain signatures, they do not violate the [Waku relay no-sign policy](/waku/standards/core/11/relay.md#signature-policy),
+because they are part of the discovery domain and
+are not propagated in the relay domain.
+However, there might still be some form of leakage:
+ENRs could be used to track peers and facilitate linking attacks.
+We will investigate this further in our Waku anonymity analysis.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+* [33/WAKU2-DISCV5](/waku/standards/core/33/discv5.md)
+* [EIP-1459: Node Discovery via DNS](https://eips.ethereum.org/EIPS/eip-1459)
+* [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
+* [multiaddress](https://docs.libp2p.io/concepts/addressing/)
+* [libp2p discovery interface in nim](https://github.com/status-im/nim-libp2p/issues/140)
+* [libp2p discovery interface in javascript](https://github.com/libp2p/js-libp2p-interfaces/tree/master/packages/interface-peer-discovery)
+* [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md)
+* [29/WAKU2-CONFIG](/waku/informational/29/config.md)
+* [Waku Relay Anonymity](https://vac.dev/wakuv2-relay-anon)
+* [Waku relay no-sign policy](/waku/standards/core/11/relay.md#signature-policy)

waku/standards/core/64/network.md

@@ -50,16 +50,16 @@ routed on the combination of the eight pubsub topics:
 /waku/2/rs/1/7
 ```
 
-A node MUST use [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md)
+A node MUST use [66/WAKU2-METADATA](../66/metadata.md)
 protocol to identify the `<cluster_id>` that every
 inbound/outbound peer that attempts to connect supports.
 In any of the following cases, the node MUST trigger a disconnection:
 
-* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md)
+* [66/WAKU2-METADATA](../66/metadata.md)
 dial fails.
-* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md)
+* [66/WAKU2-METADATA](../66/metadata.md)
 reports an empty `<cluster_id>`.
-* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md)
+* [66/WAKU2-METADATA](../66/metadata.md)
 reports a `<cluster_id>` different than `1`.
 
 ## Roles
@@ -370,7 +370,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [17/WAKU2-RLN-RELAY](../17/rln-relay.md)
 * [11/WAKU2-RELAY](../11/relay.md)
 * [WAKU2-RELAY-SHARDING](../../core/relay-sharding.md)
-* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md)
+* [66/WAKU2-METADATA](../66/metadata.md)
 * [EIP-1459 DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459)
 * [33/WAKU2-DISCV5](../33/discv5.md)
 * [12/WAKU2-FILTER](../12/filter.md)