vacp2p/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-09 22:08:07 -05:00
Code Issues Packages Projects Releases Wiki Activity

Removing version usage

Browse Source 
`version` forces a developer to leak application concerns (encryption used on payload) to the routing layer.

This is unnecessary, as the content topic should be used to discriminate what
messages to decrypt with what scheme and key (as it is application dependent).
This commit is contained in:
fryorcraken
2025-08-06 15:41:32 +10:00
parent 4361e2958f
commit 8b8622cf48
1 changed files with 13 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
waku/standards/core/14/message.md
View File

@@ -4,7 +4,7 @@ title: 14/WAKU2-MESSAGE
name: Waku v2 Message
status: stable
category: Standards Track
tags: waku/core-protocol
tags: [waku-core-protocol]
editor: Hanno Cornelius <hanno@status.im>
contributors:
- Sanaz Taheri <sanaz@status.im>
@@ -12,6 +12,7 @@ contributors:
- Lorenzo Delgado <lorenzo@status.im>
- Abhimanyu Rawat <abhi@status.im>
- Oskar Thorén <oskarth@titanproxy.com>
- Franck Royer <franck@status.im>
---
## Abstract
@@ -42,7 +43,7 @@ This specification attempts to provide for these various requirements.
## Semantics
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
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).
@@ -72,9 +73,10 @@ This attribute can be utilized to convey supplementary details
to various [10/WAKU2](/waku/standards/core/10/waku2.md) protocols,
thereby enabling customized processing based on its contents.
- The `version` attribute, if present,
contains a version number to discriminate different types of payload encryption.
If omitted, the value SHOULD be interpreted as version 0.
- The `version` attribute SHOULD NOT be written or read.
If omitted, the value SHOULD be interpreted as version `0`.
Its usage is now deprecated, and may return if routing-level discrimination is needed.
Versions `1` and `2` SHOULD NOT be used and considered deprecated.
- The `timestamp` attribute, if present,
signifies the time at which the message was generated by its sender.
@@ -113,26 +115,10 @@ An example proto file following this specification can be found [here (vacp2p/wa
## Payload encryption
The `WakuMessage` payload MAY be encrypted.
The message `version` attribute indicates
the schema used to encrypt the payload data.
- **Version 0:**
The payload SHOULD be interpreted as unencrypted; additionally,
it CAN indicate that the message payload has been encrypted
at the application layer.
- **Version 1:**
The payload SHOULD be encrypted using [6/WAKU1](/waku/standards/legacy/6/waku1.md) payload encryption specified in [26/WAKU-PAYLOAD](/waku/standards/application/26/payload.md).
This provides asymmetric and symmetric encryption.
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 [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md).
The Waku Noise protocol provides symmetric encryption and asymmetric key exchange.
Any `version` value not included in this list is reserved for future specification.
And, in this case, the payload SHOULD be interpreted as unencrypted by the Waku layer.
It is up to the application developer to determine encryption schemes and mechanisms.
Whether a message is encrypted does not need to be expressed at the routing layer.
An application developer SHOULD use the message content topics to segregate messages encrypted in different manner,
if necessary.
## Whisper/[6/WAKU1](/waku/standards/legacy/6/waku1.md) envelope compatibility
@@ -245,7 +231,7 @@ Applications using [10/WAKU2](/waku/standards/core/10/waku2.md) messages’ `tim
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 [62/STATUS-PAYLOADS](/status/62/payloads.md/#clock-vs-timestamp-and-message-ordering).
see [62/STATUS-PAYLOADS](/status/62/payloads.md#clock-vs-timestamp-and-message-ordering).
### Reliability of the `ephemeral` attribute
@@ -270,4 +256,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
- [protocol buffers v3](https://developers.google.com/protocol-buffers/)
- [26/WAKU-PAYLOAD](/waku/standards/application/26/payload.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)
- [62/STATUS-PAYLOADS](/status/62/payloads.md#clock-vs-timestamp-and-message-ordering)