vacp2p · jimstir · Jan 6, 2024 · Jan 7, 2024 · Jan 7, 2024 · Jan 7, 2024
diff --git a/content/docs/rfcs/14/README.md b/content/docs/rfcs/14/README.md
@@ -16,10 +16,13 @@ contributors:
 # Abstract
 
 Waku v2 is a family of modular peer-to-peer protocols for secure communication.
-These protocols are designed to be secure, privacy-preserving, and censorship-resistant and can run in resource-restricted environments.
+These protocols are designed to be secure, privacy-preserving, and censorship-resistant and 
+can run in resource-restricted environments.
 At a high level, Waku v2 implements a Pub/Sub messaging pattern over libp2p and adds capabilities.
 
-The present document specifies the Waku v2 message format, a way to encapsulate the messages sent with specific information security goals, and Whisper/Waku v1 backward compatibility.
+The present document specifies the Waku v2 message format, 
+a way to encapsulate the messages sent with specific information security goals, and 
+Whisper/Waku v1 backward compatibility.
 
 
 # Motivation
@@ -36,10 +39,12 @@ This specification attempts to provide for these various requirements.
 
 
 # Semantics
+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 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
 ## Waku Message
 
-A Waku message is constituted by the combination of data payload and attributes that, for example, a *publisher* sends to a *topic* and is eventually delivered to *subscribers*.
+A Waku message is constituted by the combination of data payload and attributes that, for example, 
+a *publisher* sends to a *topic* and is eventually delivered to *subscribers*.
 
 Waku message attributes are key-value pairs of metadata associated with a message. 
 And the message data payload is the part of the transmitted Waku message that is the actual message information.
@@ -51,22 +56,29 @@ The data payload is also treated as a Waku message attribute for convenience.
 
 * The `content_topic` attribute MUST specify a string identifier that can be used for content-based filtering.
 
-* The `meta` attribute, if present, contains an arbitrary application-specific variable-length byte array with a maximum length limit of 64 bytes.
-This attribute can be utilized to convey supplementary details to various Waku protocols, thereby enabling customized processing based on its contents.
+* The `meta` attribute, if present,
+contains an arbitrary application-specific variable-length byte array with a maximum length limit of 64 bytes.
+This attribute can be utilized to convey supplementary details to various Waku 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.
+* 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 `timestamp` attribute, if present, signifies the time at which the message was generated by its sender.
+* The `timestamp` attribute, if present,
+signifies the time at which the message was generated by its sender.
 This attribute MAY contain the Unix epoch time in nanoseconds.
 If the attribute is omitted, it SHOULD be interpreted as timestamp 0.
 
-* The `ephemeral` attribute, if present, signifies the transient nature of the message.
+* The `ephemeral` attribute, if present,
+signifies the transient nature of the message.
 For example, an ephemeral message SHOULD not be persisted by the Waku network.
-If this attribute is set to `true`, the message SHOULD be interpreted as ephemeral.
-If, instead, the attribute is omitted or set to `false`, the message SHOULD be interpreted as non-ephemeral.
+If this attribute is set to `true`,
+the message SHOULD be interpreted as ephemeral.
+If, instead, the attribute is omitted or set to `false`,
+the message SHOULD be interpreted as non-ephemeral.
 
-# Wire Format
+## Wire Format
 
 The Waku message wire format is specified using [protocol buffers v3](https://developers.google.com/protocol-buffers/).
 
@@ -82,11 +94,17 @@ message WakuMessage {
   optional bool ephemeral = 31;
 }
 ```
+## Waku Message Vaildator
 
-An example proto file following this specification can be found [here (vacp2p/waku)](https://github.com/vacp2p/waku/blob/main/waku/message/v1/message.proto).
+A message MUST be vaildated as a vaild `WakuMessage`.
+The [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/) SHOULD validate the `content_topic` and `payload` attributes.
+If a message is invalid during validation,
+the message SHOULD be dropped from the network.
 
+If the message is valid during validation,
+the message MUST be sent to peers who have subscribed to the `content_topic`.
 
-# Payload encryption
+## Payload Encryption
 
 The Waku message payload MAY be encrypted.
 The message `version` attribute indicates the schema used to encrypt the payload data.
@@ -108,32 +126,42 @@ Any `version` value not included in this list is reserved for future specificati
 And, in this case, the payload SHOULD be interpreted as unencrypted by the Waku layer.
 
 
-# Whisper/Waku v1 envelope compatibility
+## Whisper/Waku v1 Envelope Compatibility
 
 Whisper/Waku v1 envelopes are compatible with Waku v2 messages format.
 
 * Whisper/Waku v1 `topic` field SHOULD be mapped to Waku v2 message's `content_topic` attribute.
 * Whisper/Waku v1 `data` field SHOULD be mapped to Waku v2 message's `payload` attribute.
 
 Waku v2 implements a pub/sub messaging pattern over libp2p.
-This makes redundant some Whisper/Waku v1 envelope fields (e.g., `expiry`, `ttl`, `topic`, etc.), so they can be ignored.
+This makes redundant some Whisper/Waku v1 envelope fields (e.g., `expiry`, `ttl`, `topic`, etc.), so 
+they can be ignored.
 
-# Deterministic message hashing
+## Deterministic Message Hashing
 
-In Protocol Buffers v3, the deterministic serialization is not canonical across the different implementations and languages.
+In Protocol Buffers v3, 
+the deterministic serialization is not canonical across the different implementations and languages.
 It is also unstable across different builds with schema changes due to unknown fields. 
 
-To overcome this interoperability limitation, a Waku v2 message's hash MUST be computed following this schema:
+To overcome this interoperability limitation, 
+a Waku v2 message's hash MUST be computed following this schema:
 
 ```
 message_hash = sha256(concat(pubsub_topic, message.payload, message.content_topic, message.meta, message.timestamp))
 ```
 
-If an optional attribute, such as `meta`, is absent, the concatenation of attributes SHOULD exclude it. This recommendation is made to ensure that the concatenation process proceeds smoothly when certain attributes are missing and to maintain backward compatibility.
+If an optional attribute, such as `meta`, is absent, 
+the concatenation of attributes SHOULD exclude it. 
+This is RECOMMENDED to ensure that the concatenation process proceeds smoothly when certain attributes are missing and 
+to maintain backward compatibility.
 
-This hashing schema is deemed appropriate for use cases where a cross-implementation deterministic hash is needed, such as message deduplication and integrity validation. The collision probability offered by this hashing schema can be considered negligible. This is due to the deterministic concatenation order of the message attributes, coupled with using a SHA-2 (256-bit) hashing algorithm.
+This hashing schema is deemed appropriate for use cases where a cross-implementation deterministic hash is needed, 
+such as message deduplication and integrity validation. 
+The collision probability offered by this hashing schema can be considered negligible. 
+This is due to the deterministic concatenation order of the message attributes, 
+coupled with using a SHA-2 (256-bit) hashing algorithm.
 
-## Test vectors
+## Test Vectors
 
 Waku message hash computation (`meta` size of 12 bytes):
 ```
@@ -184,25 +212,32 @@ message_hash = 0x483ea950cb63f9b9d6926b262bb36194d3f40a0463ce8446228350bd44e96de
 
 ## Confidentiality, integrity, and authenticity
 
-The level of confidentiality, integrity, and authenticity of the Waku message payload is discretionary.
-Accordingly, the application layer shall utilize the encryption and signature schemes supported by Waku v2 to meet the application-specific privacy needs.
+The level of confidentiality, integrity, and 
+authenticity of the Waku message payload is discretionary.
+Accordingly, the application layer shall utilize the encryption and 
+signature schemes supported by Waku v2 to meet the application-specific privacy needs.
 
 ## Reliability of the `timestamp` attribute
 
 The Waku message `timestamp` attribute is set by the sender.
-Therefore, because message timestamps aren’t independently verified, this attribute is prone to exploitation and misuse.
+Therefore, because message timestamps aren’t independently verified, 
+this attribute is prone to exploitation and misuse.
 It should not solely be relied upon for operations such as message ordering.
-For example, a malicious actor can arbitrarily set the `timestamp` of a Waku message to a high value so that it always shows up as the most recent message in a chat application.
-Applications using Waku messages’ `timestamp` attribute 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).
+For example, a malicious actor can arbitrarily set the `timestamp` of a Waku message to a high value, so 
+that it always shows up as the most recent message in a chat application.
+Applications using Waku messages’ `timestamp` attribute 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](/spec/62).
 
 ## Reliability of the `ephemeral` attribute
 
 The Waku message `ephemeral` attribute is set by the sender.
-Since there is currently no incentive mechanism for network participants to behave correctly, this attribute is inherently insecure.
-A malicious actor can tamper with the value of a Waku message’s `ephemeral` attribute, and the receiver would not be able to verify the integrity of the message.
+Since there is currently no incentive mechanism for network participants to behave correctly, 
+this attribute is inherently insecure.
+A malicious actor can tamper with the value of a Waku message’s `ephemeral` attribute, and 
+the receiver would not be able to verify the integrity of the message.
 
-## Copyright
+# Copyright
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
 
@@ -211,6 +246,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 - [6/WAKU1](/spec/6/)
 - [Google Protocol buffers v3](https://developers.google.com/protocol-buffers/)
+- [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/)
 - [26/WAKU-PAYLOAD](/spec/26)
 - [35/WAKU2-NOISE](/spec/35)
-- [6/PAYLOADS](https://specs.status.im/spec/6#clock-vs-timestamp-and-message-ordering)
+- [62/STATUS-PAYLOADS](https://specs.status.im/spec/6#clock-vs-timestamp-and-message-ordering)