diff --git a/content/docs/rfcs/13/README.md b/content/docs/rfcs/13/README.md index 92816910..782f9a74 100644 --- a/content/docs/rfcs/13/README.md +++ b/content/docs/rfcs/13/README.md @@ -8,6 +8,7 @@ editor: Sanaz Taheri contributors: - Dean Eigenmann - Oskar Thorén + - Aaryamann Challani --- This specification explains the Waku `13/WAKU2-STORE` protocol which enables querying of messages received through relay protocol and stored by other nodes. @@ -21,6 +22,11 @@ As such, they are required to be *highly available* and in specific have a *high 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 that 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](/spec/13) SHOULD support "ephemeral" messages as specified in [14/WAKU2-MESSAGE](/spec/14). +Nodes running [13/WAKU2-STORE](/spec/13) SHOULD NOT store messages with the `ephemeral` flag set to `true`. + + # Security Consideration The main security consideration to take into account while using `13/WAKU2-STORE` is that a querying node have to reveal their content filters of interest to the queried node, hence potentially compromising their privacy. diff --git a/content/docs/rfcs/14/README.md b/content/docs/rfcs/14/README.md index 5ea2fdbc..e30dc4a4 100644 --- a/content/docs/rfcs/14/README.md +++ b/content/docs/rfcs/14/README.md @@ -6,6 +6,7 @@ status: draft editor: Oskar Thorén contributors: - Sanaz Taheri + - Aaryamann Challani --- This specification provides a way to encapsulate messages sent over Waku with specific information security goals. @@ -38,6 +39,12 @@ The `timestamp` field MAY be filled out to signify the time at which the message This field holds the Unix epoch time in nanoseconds. Omitting it means the timestamp is unspecified. +The `ephemeral` field MAY be set to signify the transient nature of the message. +If the message should be stored by the [store protocol](/spec/13), then this field MUST be set to `false`, which is equivalent to omitting the field. +If the message should not be stored by the [store protocol](/spec/13), then this field MUST be set to `true`. + +See [13/WAKU2-STORE](/spec/13) for more details. + ## Payloads Payloads are implemented using [protocol buffers v3](https://developers.google.com/protocol-buffers/). @@ -50,6 +57,7 @@ message WakuMessage { string contentTopic = 2; uint32 version = 3; sint64 timestamp = 10; + bool ephemeral = 31; } ``` @@ -101,6 +109,12 @@ For example, a malicious node can arbitrarily set the `timestamp` of a `WakuMes Applications using the `WakuMessage`'s `timestamp` field are recommended to use additional methods for more robust message ordering. An example of how to deal with message ordering against adversarial message timestamps can be found in the Status protocol, see [6/PAYLOADS](https://specs.status.im/spec/6#clock-vs-timestamp-and-message-ordering). +## Reliability of the ephemeral flag + +The `ephemeral` field in `WakuMessage` is set by the sender. +Since there is currently no incentive mechanism for nodes that implement [13/WAKU2-STORE](/spec/13) and [11/WAKU2-RELAY](/spec/11) to behave correctly, this field is inherently unsecure. +Malicious nodes that implement [11/WAKU2-RELAY](/spec/11) can flip the value of the ephemeral flag, and nodes that receive such messages would have no mechanism to verify the integrity of the message. + # Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).