diff --git a/waku/standards/core/13/STORE.md b/waku/standards/core/13/store.md similarity index 94% rename from waku/standards/core/13/STORE.md rename to waku/standards/core/13/store.md index aa1cbbc..446804e 100644 --- a/waku/standards/core/13/STORE.md +++ b/waku/standards/core/13/store.md @@ -11,7 +11,7 @@ contributors: - Aaryamann Challani --- -# Abstract +## 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. @@ -24,7 +24,7 @@ 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 +## 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). @@ -37,11 +37,11 @@ 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`](/spec/14) affects `13/WAKU2-STORE` as well. -Nodes running `13/WAKU2-STORE` SHOULD support `ephemeral` messages as specified in [14/WAKU2-MESSAGE](/spec/14). +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 +## 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, @@ -58,12 +58,12 @@ The following are not considered as part of the adversarial model: - 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 +## 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 +### Payloads ```protobuf syntax = "proto3"; @@ -114,17 +114,17 @@ message HistoryRPC { } ``` -### Index +#### 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](/spec/14)). + 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 `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` @@ -132,18 +132,18 @@ each `WakuMessage` stored at a node running the `13/WAKU2-STORE` protocol is ass - `cursor`: holds the `Index` of a `WakuMessage`. - `direction`: indicates the direction of paging which can be either `FORWARD` or `BACKWARD`. -### ContentFilter +#### 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](/spec/14). + This field maps to the `contentTopic` field of the [14/WAKU2-MESSAGE](../14/message.md). -### HistoryQuery +#### 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`](/spec/11). + 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. @@ -163,7 +163,7 @@ RPC call to query historical messages. 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 +#### 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. @@ -176,33 +176,33 @@ a `cursor` obtained from one node can be consistently used to query from another 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 +#### HistoryResponse RPC call to respond to a HistoryQuery call. - The `messages` field MUST contain the messages found, -these are [14/WAKU2-MESSAGE](/spec/14) types. +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](/spec/14). + 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 +## 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 +## 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](/spec/14) they are interested in. +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](/spec/14). +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. @@ -247,13 +247,13 @@ That is, messages contain the most recent block height perceived by their sender 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 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -# References -1. [14/WAKU2-MESSAGE](/spec/14) +## References +1. [14/WAKU2-MESSAGE](../14/message.md) 2. [protocol buffers v3](https://developers.google.com/protocol-buffers/) -3. [11/WAKU2-RELAY](/spec/11) +3. [11/WAKU2-RELAY](../11/relay.md) 4. [Open timestamps](https://opentimestamps.org/)