vacp2p
/
rfc
mirror of https://github.com/vacp2p/rfc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

14/WAKU2-MESSAGE: General improvements (#319)

This commit is contained in:
Oskar Thorén 2021-04-06 12:23:02 +08:00 committed by GitHub
parent d899e6af79
commit 5c95d2c312
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
content/docs/rfcs/14/README.md
View File

@ -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/).