Removing version usage

`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).

waku/standards/application/53/x3dh.md

@@ -7,11 +7,12 @@ category: Standards Track
 tags: waku-application
 editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
-- Andrea Piana <andreap@status.im>
-- Pedro Pombeiro <pedro@status.im>
-- Corey Petty <corey@status.im>
-- Oskar Thorén <oskarth@titanproxy.com>
-- Dean Eigenmann <dean@status.im>
+ - Andrea Piana <andreap@status.im>
+ - Pedro Pombeiro <pedro@status.im>
+ - Corey Petty <corey@status.im>
+ - Oskar Thorén <oskarth@titanproxy.com>
+ - Dean Eigenmann <dean@status.im>
+ - Filip Dimitrijevic <filip@status.im>
 ---
 
 ## Abstract
@@ -38,7 +39,7 @@ without other nodes network being able to read their messages.
 which provide assurances that session keys will not be compromised
 even if the private keys of the participants are compromised.
 Specifically, past messages cannot be decrypted by a third-party
-who manages to get a hold of a private key.
+who manages to obtain those private key.
 
 - **Secret channel** describes a communication channel
 where a Double Ratchet algorithm is in use.
@@ -73,7 +74,7 @@ The main cryptographic protocol is a Double Ratchet protocol,
 which is derived from the
 [Off-the-Record protocol](https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html),
 using a different ratchet.
-[The Waku v2 protocol](../../core/10/waku2.md)
+[The Waku v2 protocol](/waku/standards/core/10/waku2.md)
 subsequently encrypts the message payload, using symmetric key encryption.
 Furthermore, the concept of prekeys
 (through the use of [X3DH](https://signal.org/docs/specifications/x3dh/))
@@ -234,38 +235,41 @@ Where:
     ([reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L47))
 
 ```protobuf
-    message X3DHHeader {
-      // Alice's ephemeral key `EK_A`
-      bytes key = 1;
-      // Bob's bundle signed prekey
-      bytes id = 4;
-    }
+message X3DHHeader {
+  // Alice's ephemeral key `EK_A`
+  bytes key = 1;
+  // Bob's bundle signed prekey
+  bytes id = 4;
+}
 ```
 
 - `DR_header`: Double ratchet header ([reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L31)).
 Used when Bob's public bundle is available:
 
 ``` protobuf
-    message DRHeader {
-      // Alice's current ratchet public key (as mentioned in [DR spec section 2.2](https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet))
-      bytes key = 1;
-      // number of the message in the sending chain
-      uint32 n = 2;
-      // length of the previous sending chain
-      uint32 pn = 3;
-      // Bob's bundle ID
-      bytes id = 4;
-    }
+message DRHeader {
+  // Alice's current ratchet public key
+  bytes key = 1;
+  // number of the message in the sending chain
+  uint32 n = 2;
+  // length of the previous sending chain
+  uint32 pn = 3;
+  // Bob's bundle ID
+  bytes id = 4;
+}
 ```
 
+Alice's current ratchet public key (above) is mentioned in
+[DR spec section 2.2](https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet)
+
 - `DH_header`: Diffie-Hellman header (used when Bob's bundle is not available):
     ([reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L42))
 
 ``` protobuf
-    message DHHeader {
-      // Alice's compressed ephemeral public key.
-      bytes key = 1;
-    }
+message DHHeader {
+  // Alice's compressed ephemeral public key.
+  bytes key = 1;
+}
 ```
 
 #### 3. Chain key update
@@ -286,7 +290,7 @@ The message key MUST be used to encrypt the next message to be sent.
 1. Inherits the security considerations of [X3DH](https://signal.org/docs/specifications/x3dh/#security-considerations)
 and [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/#security-considerations).
 
-2. Inherits the security considerations of the [Waku v2 protocol](../../core/10/waku2.md).
+2. Inherits the security considerations of the [Waku v2 protocol](/waku/standards/core/10/waku2.md).
 
 3. The protocol is designed to be used in a decentralized manner, however,
 it is possible to use a centralized server to serve prekey bundles.
@@ -299,7 +303,8 @@ It is possible to link messages signed by the same keypair.
 
 ## 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/).
 
 ## References
 
@@ -308,7 +313,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 - [Signal's Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
 - [Protobuf](https://developers.google.com/protocol-buffers/)
 - [Off-the-Record protocol](https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html)
-- [The Waku v2 protocol](../../core/10/waku2.md)
+- [The Waku v2 protocol](/waku/standards/core/10/waku2.md)
 - [HKDF](https://www.rfc-editor.org/rfc/rfc5869)
 - [2/ACCOUNT](https://specs.status.im/spec/2#x3dh-prekey-bundles)
 - [reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L12)

waku/standards/core/14/message.md

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

waku/standards/core/66/metadata.md

@@ -3,9 +3,10 @@ slug: 66
 title: 66/WAKU2-METADATA
 name: Waku Metadata Protocol
 status: draft
-editor: Alvaro Revuelta <alrevuelta@status.im>
+editor: Franck Royer <franck@status.im>
 contributors:
- - Filip Dimitrijevic <filip@status.im>
+  - Filip Dimitrijevic <filip@status.im>
+  - Alvaro Revuelta <alrevuelta@status.im>
 ---
 
 ## Abstract
@@ -15,16 +16,19 @@ that can be associated with a [10/WAKU2](/waku/standards/core/10/waku2.md) node.
 
 ## Metadata Protocol
 
-Waku specifies a req/resp protocol that provides information about the node's medatadata.
-Such metadata is meant to be used by the node to decide if a peer is worth connecting
-or not.
+The keywords “MUST”, // List style “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,
+“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 specifies a req/resp protocol that provides information about the node's capabilities.
+Such metadata MAY be used by other peers for subsequent actions such as light protocol requests or disconnection.
+
 The node that makes the request,
 includes its metadata so that the receiver is aware of it,
-without requiring an extra interaction.
+without requiring another round trip.
 The parameters are the following:
 
 * `clusterId`: Unique identifier of the cluster that the node is running in.
-* `shards`: Shard indexes that the node is subscribed to.
+* `shards`: Shard indexes that the node is subscribed to via [`11/WAKU2-RELAY`](/waku/standards/core/11/relay.md).
 
 ***Protocol Identifier***
 
@@ -48,6 +52,51 @@ message WakuMetadataResponse {
 }
 ```
 
+## Implementation Suggestions
+
+### Triggering Metadata Request
+
+A node SHOULD proceed with metadata request upon first connection to a remote node.
+A node SHOULD use the remote node's libp2p peer id as identifier for this heuristic.
+
+A node MAY proceed with metadata request upon reconnection to a remote peer.
+
+A node SHOULD store the remote peer's metadata information for future reference.
+A node MAY implement a TTL regarding a remote peer's metadata, and refresh it upon expiry by initiating another metadata request.
+It is RECOMMENDED to set the TTL to 6 hours.
+
+A node MAY trigger a metadata request after receiving an error response from a remote note
+stating they do not support a specific cluster or shard.
+For example, when using a request-response service such as [`19/WAKU2-LIGHTPUSH`](/waku/standards/core/19/lightpush.md).
+
+### Providing Cluster Id
+
+A node MUST include their cluster id into their metadata payload.
+It is RECOMMENDED for a node to operate on a single cluster id.
+
+### Providing Shard Information
+
+* Nodes that mount [`11/WAKU2-RELAY`](/waku/standards/core/11/relay.md) MAY include the shards they are subscribed to in their metadata payload.
+* Shard-relevant services are message related services,
+  such as [`13/WAKU2-STORE`](/waku/standards/core/13/store.md), [12/WAKU2-FILTER](/waku/standards/core/12/filter.md)
+  and [`19/WAKU2-LIGHTPUSH`](/waku/standards/core/19/lightpush.md)
+  but not [`34/WAKU2-PEER-EXCHANGE`](/waku/standards/core/34/peer-exchange.md)
+* Nodes that mount [`11/WAKU2-RELAY`](/waku/standards/core/11/relay.md) and a shard-relevant service SHOULD include the shards they are subscribed to in their metadata payload.
+* Nodes that do not mount [`11/WAKU2-RELAY`](/waku/standards/core/11/relay.md) SHOULD NOT include any shard information
+
+### Using Cluster Id
+
+When reading the cluster id of a remote peer, the local node MAY disconnect if their cluster id is different from the remote peer.
+
+### Using Shard Information
+
+It is NOT RECOMMENDED to disconnect from a peer based on the fact that their shard information is different from the local node.
+
+Ahead of doing a shard-relevant request,
+a node MAY use the previously received metadata shard information to select a peer that support the targeted shard.
+
+For non-shard-relevant requests, a node SHOULD NOT discriminate a peer based on medata shard information.
+
 ## Copyright
 
 Copyright and related rights waived via