From 5c95d2c3120a0c7df2022ebba50db6daa52f9935 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oskar=20Thor=C3=A9n?= Date: Tue, 6 Apr 2021 12:23:02 +0800 Subject: [PATCH] 14/WAKU2-MESSAGE: General improvements (#319) --- content/docs/rfcs/14/README.md | 35 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/content/docs/rfcs/14/README.md b/content/docs/rfcs/14/README.md index d0131533..25bccbb7 100644 --- a/content/docs/rfcs/14/README.md +++ b/content/docs/rfcs/14/README.md @@ -12,7 +12,7 @@ This specification provides a way to encapsulate messages sent over Waku with sp # Motivation -When using Waku to send messages over Waku there are multiple concerns: +When sending messages over Waku there are multiple concerns: - We may have a separate encryption layer as part of our application - We may want to provide efficient routing for resource restricted devices - We may want to provide compatibility with Waku v1 envelopes @@ -27,9 +27,11 @@ A `WakuMessage` is what is being passed around by the other protocols, such as W The `payload` field SHOULD contain whatever payload is being sent. See section below on payload encryption. -The `contentTopic` field SHOULD be filled out to allow for content-based filtering. See [Waku Filter spec](waku-filter.md) for details. +The `contentTopic` field SHOULD be filled out to allow for content-based filtering. +See [12/WAKU2-FILTER](/spec/12) and [13/WAKU2-STORE](/spec/13) for details. -The `version` field MAY be filled out to allow for various types of payload encryption. Omitting it means the version is 0. +The `version` field MAY be filled out to allow for various types of payload encryption. +Omitting it means the version is 0. ## Protobuf @@ -49,30 +51,27 @@ Payload encryption depends on the `version` field. This indicates that the payload SHOULD be either unencrypted or that encryption is done at a separate layer outside of Waku. -### Version 1 (not yet implemented in Waku v2) +### Version 1 -This indicates that payloads MUST be encrypted using [Waku v1 envelope data -format spec](https://specs.vac.dev/specs/waku/v1/envelope-data-format.html). +This indicates that payloads MUST be encrypted using [7/WAKU-DATA envelope data format spec](/spec/7). -This provides for asymmetric and symmetric encryption. Key agreement is out of band. It also provides an encrypted signature and padding for some form of unlinkability. +This provides for asymmetric and symmetric encryption. +Key agreement is out of band. +It also provides an encrypted signature and padding for some form of unlinkability. # Differences from Whisper / Waku v1 envelopes -In Whisper and Waku v1, an envelope contains the following fields: `expiry, ttl, -topic, data, nonce`. +In Whisper and Waku v1, an envelope contains the following fields: `expiry, ttl, topic, data, nonce`. -Since Waku v2 is using libp2p PubSub, some of these fields can be dropped. The previous `topic` -field corresponds to `contentTopic`. The previous `data` field corresponds to the `payload` field. +Since Waku v2 is using libp2p PubSub, some of these fields can be dropped. +The previous `topic` field corresponds to `contentTopic`. +The previous `data` field corresponds to the `payload` field. # Security Consideration -In Waku, the confidentiality, integrity, and authenticity of the data must be addressed at the `WakuMessage` level. That is, the `payload` shall be encrypted or signed properly to meet the application-specific privacy needs. - -# Changelog - -Initial release on [2020-10-22](https://github.com/vacp2p/specs/pull/222/commits/dbab6c7084b414b62818150588266abedd09315f). +In Waku, the confidentiality, integrity, and authenticity of the data must be addressed at the `WakuMessage` level. +That is, the `payload` shall be encrypted or signed properly to meet the application-specific privacy needs. # Copyright -Copyright and related rights waived via -[CC0](https://creativecommons.org/publicdomain/zero/1.0/). +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).