Create block-header.md

# What does this PR resolve? 🚀
- Changes title inside Waku/README.md from h2 to h1
- Changes title inside Waku/Deprecated/README.md from h2 to h1

# Details 📝
The syntax for the title of the markdown seems to not be proper one
comparing to other README documents.
It's important to define titles with h1(#) to be able to parse it
properly later on by the website

.github/workflows/markdown-lint.yml

@@ -0,0 +1,32 @@
+name: markdown-linting
+
+on:
+
+  push:
+    branches: 
+      - '**'
+  pull_request:
+    branches: 
+      - '**'
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v2
+      
+      - name: Get changed files
+        continue-on-error: true
+        run: |
+          echo "CHANGED_FILES<<EOF" >> $GITHUB_ENV
+          gh pr diff ${{ github.event.number }} --name-only | sed -e 's|$|,|' | xargs -i echo "{}" >> $GITHUB_ENV
+          echo "EOF" >> $GITHUB_ENV
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      
+      - name: Markdown Linter
+        uses: DavidAnson/markdownlint-cli2-action@v15
+        with:
+          globs: ${{ env.CHANGED_FILES }}

.github/workflows/website-sync.yml

@@ -0,0 +1,41 @@
+name: Website Sync
+
+on:
+  pull_request:
+    types: [closed]
+    branches:
+      - main
+
+jobs:
+  sync:
+    if: github.event.pull_request.merged == true
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v2
+
+      - name: Clone Website Repo
+        run: |
+          git clone git@github.com:vacp2p/rfc-website.git
+          cd rfc-website
+          git config --local user.email "actions@github.com"
+          git config --local user.name "GitHub Actions"
+
+      - name: List of changed files
+        id: changed_files
+        run: |
+          echo "::set-output name=files::$(git diff --name-only ${{ github.event.before }} ${{ github.sha }})"
+      
+      - name: Copy changed files to Website Repo
+        run: |
+          for file in ${{ steps.changed_files.outputs.files }}; do
+            cp --parents "$file" rfc-website/
+          done
+
+      - name: Push changes to Website Repo
+        run: |
+          cd rfc-website
+          git add .
+          git commit -m "Sync website"
+          git push origin main

README.md

@@ -2,21 +2,38 @@
 
 *NOTE*: This repo is WIP. We are currently restructuring the RFC process.
 
-## RFC Process
-
 This repository contains specifications from the [Waku](https://waku.org/), [Nomos](https://nomos.tech/), 
 [Codex](https://codex.storage/), and [Status](https://status.app/) projects that are part of the [IFT portfolio](https://free.technology/).
-[Vac](https://vac.dev) is an [IFT service](https://free.technology/services) that will manage the RFC process within this repository.
-The goal of the RFC, [Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments),
-process is to standardize technical specifications. 
-Specifications will adhere to [1/COSS](./vac/1/coss.md) by obtaining a rough consensus within each project.
+[Vac](https://vac.dev) is an [IFT service](https://free.technology/services) that will manage the RFC, [Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments), process within this repository. 
 
-**See [rfc.vac.dev](https://rfc.vac.dev) for an easy to browse index of all RFCs.**
+## New RFC Process
+
+This repository replaces the previous `rfc.vac.dev` resource.
+Each project will maintain initial specifications in separate repositories, 
+which may be considered as a **raw** specification.
+All [Vac](https://vac.dev) **raw** specifications and discussions will live in the Vac subdirectory.
+When projects have reached some level of maturity for a specification living in their repository,
+the process of updating the status to **draft** may begin in this repository.
+Specifications will adhere to [1/COSS](./vac/1/coss.md) before obtaining **draft** status.
+
+Implementations should follow specifications as described,
+and all contributions will be discussed before the **stable** status is obtained.
+The goal of this RFC process will to engage all interseted parities and 
+reach a rough consensus for techcinal specifications.
 
 ## Contributing
 
-Please see [1/COSS](https://rfc.vac.dev/spec/1/) for general guidelines and specification lifecycle.
+Please see [1/COSS](./vac/1/coss.md) for general guidelines and specification lifecycle.
 
 Feel free to join the [Vac discord](https://discord.gg/Vy54fEWuqC). 
 
 Here's the project board used by core contributors and maintainers: [Projects](https://github.com/orgs/vacp2p/projects/5)
+
+## IFT Projects' Raw Specifications
+
+The repository for each project **raw** specifications:
+- [Vac Raw Specifications](./vac/raw)
+- [Status Raw Specifications](./status/raw)
+- [Waku Raw Specificiations](https://github.com/waku-org/specs/tree/master)
+- [Codex Raw Specifications]()
+- [Nomos Raw Specifications](https://github.com/logos-co/nomos-specs)

nomos/block-header.md

@@ -0,0 +1,19 @@
+---
+slug: 
+title: NOMOS-Block-Header
+name: Nomos Block Header
+status: raw
+tags: nomos
+editor: 
+contributors:
+  
+---
+
+## Abstract
+
+This specification describes the block header that is included in the creation of new blocks within Nomos Zones. 
+
+
+## Motivation
+
+## Specification

status/55/1to1-chat.md

@@ -40,7 +40,7 @@ This document describes how 2 peers communicate with each other to send messages
 This protocol MAY use any key-exchange mechanism previously discussed -
 
 1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) 
-2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)
+2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
 
 This protocol can provide end-to-end encryption to give peers a strong degree of privacy and security. 
 Public chat messages are publicly readable by anyone since there's no permission model for who is participating in a public chat.
@@ -67,7 +67,7 @@ It is handled by the key-exchange protocol used. For example,
 
 1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md), the session management is described in [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md)
 
-2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md), the session management is described in [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise-sessions/noise-sessions.md)
+2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md), the session management is described in [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md)
 
 ## Negotiation of a 1:1 chat amongst multiple participants (group chat)
 
@@ -203,7 +203,7 @@ To change the display image of the group chat, group admins MUST use an `IMAGE_C
 
 ## Security Considerations
 
-1. Inherits the security considerations of the key-exchange mechanism used, e.g., [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) or [WAKU2-NOISE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)
+1. Inherits the security considerations of the key-exchange mechanism used, e.g., [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) or [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
 
 ## Copyright
 
@@ -212,10 +212,10 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References
 
 1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md)
-2. [35/WAKU2-NOISE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)
+2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
 3. [65/STATUS-ACCOUNT](../65/account-address.md)
 4. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md)
-5. [37/WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise-sessions/noise-sessions.md)
+5. [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md)
 6. [56/STATUS-COMMUNITIES](../56/communities.md)
 7. [chat_message.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/chat_message.proto#L1)
 8. [emoji_reaction.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/emoji_reaction.proto)

status/61/community-history-service.md

@@ -321,7 +321,7 @@ There are two scenarios in which member nodes can receive such a magnet link mes
 2. The member node requests messages for a time range of up to 30 days from store nodes (this is the case when a new community member joins a community)
 
 ### Downloading message archives
-When member nodes receive a message with a `CommunityMessageHistoryArchive` ([62/STATUS-PAYLOAD](../62/payload.md)) from the aforementioned channnel, they MUST extract the `magnet_uri` and pass it to their underlying BitTorrent client so they can fetch the latest message history archive index, which is the `index` file of the torrent (see [Creating message archive torrents](#creating-message-archive-torrents)).
+When member nodes receive a message with a `CommunityMessageHistoryArchive` ([62/STATUS-PAYLOADS](../62/payloads.md)) from the aforementioned channnel, they MUST extract the `magnet_uri` and pass it to their underlying BitTorrent client so they can fetch the latest message history archive index, which is the `index` file of the torrent (see [Creating message archive torrents](#creating-message-archive-torrents)).
 
 Due to the nature of distributed systems, there's no guarantee that a received message is the "last" message. This is especially true when member nodes request historical messages from store nodes. 
 
@@ -389,4 +389,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [Extensions for Peers to Send Metadata Files](https://www.bittorrent.org/beps/bep_0009.html)
 * [org channels spec](../56/communities.md)
 * [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md)
-* [62/STATUS-PAYLOAD](../62/payload.md)
+* [62/STATUS-PAYLOADS](../62/payloads.md)

status/raw/simple-scaling.md

@@ -1,5 +1,5 @@
 ---
-slug: 57
+
 title: 57/STATUS-Simple-Scaling
 name: Status Simple Scaling
 status: raw
@@ -325,26 +325,29 @@ is done via a register query:
 REGISTER{my-app, {QmA, AddrA}}
 ```
 
-The app name, `my-app` is used to encode a single shard in the form:
+The app name, `my-app` contains the encoding of a single shard in string form:
 
 ```
-<rs (utf8 encoded)> | <2-byte shard cluster index> | <2-byte shard index>
+"rs/"| to_string(<2-byte shard cluster index>) | "/" | to_string(<2-byte shard index>)
 ```
+The string conversion SHOULD remove leading zeros.
+
+> *Note:* Since the [ns](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#protobuf) field is of type string,
+a more efficient byte encoding is not utilized.
 
 Registering shard 2 in the Status shard cluster (with shard cluster index 16, see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md),
 the register query would look like
 
 ```
-REGISTER{0x727300100002, {QmA, AddrA}}
+REGISTER{"rs/16/2", {QmA, AddrA}}
 ```
 
 Participation in further shards is registered with further queries; one register query per shard.
-(0x7273 is the encoding of `rs`.)
 
 A discovery query for nodes that are part of this shard would look like
 
 ```
-DISCOVER{ns: 0x727300100002}
+DISCOVER{ns: "rs/16/2"}
 ```
 
 ## DoS Protection

status/raw/status-waku-usage.md

@@ -0,0 +1,204 @@
+---
+title: STATUS-WAKU2-USAGE
+name: Status Waku2 Usage
+status: raw
+category: Best Current Practice
+description: Defines how the Status application uses the Waku protocols.
+editor: Aaryamann Challani <aaryamann@status.im>
+contributors: 
+- Jimmy Debe <jimmy@status.im>
+
+---
+
+## Abstract
+
+Status is a chat application which has several features, including, but not limited to -
+- Private 1:1 chats, described by [55/STATUS-1TO1-CHAT](/spec/55)
+- Large scale group chats, described by [56/STATUS-COMMUNITIES](/spec/56)
+
+This specification describes how a Status implementation will make use of the underlying infrastructure, 
+Waku, which is described in [10/WAKU2](/spec/10).
+
+## Background 
+
+The Status application aspires to achieve censorship resistance and incorporates specific privacy features, 
+leveraging the comprehensive set of protocols offered by Waku to enhance these attributes. 
+Waku protocols provide secure communication capabilities over decentralized networks. 
+Once integrated, an application will benefit from privacy-preserving, 
+censorship resistance and spam protected communcation. 
+
+Since Status uses a large set of Waku protocols, 
+it is imperative to describe how each are used. 
+
+## Terminology
+
+| Name  | Description |
+| --------------- | --------- |
+| `RELAY`| This refers to the Waku Relay protocol, described in [11/WAKU2-RELAY](/spec/11) |
+| `FILTER` | This refers to the Waku Filter protocol, described in [12/WAKU2-FILTER](/spec/12) |
+| `STORE` | This refers to the Waku Store protocol, described in [13/WAKU2-STORE](/spec/13) |
+| `MESSAGE` | This refers to the Waku Message format, described in [14/WAKU2-MESSAGE](/spec/14) |
+| `LIGHTPUSH` | This refers to the Waku Lightpush protocol, described in [19/WAKU2-LIGHTPUSH](/spec/19) |
+| Discovery | This refers to a peer discovery method used by a Waku node. |
+| `Pubsub Topic` / `Content Topic` | This refers to the routing of messages within the Waku network, described in [23/WAKU2-TOPICS](/spec/23/) |
+
+### Waku Node:
+
+Software that is configured with a set of Waku protocols.
+A Status client comprises of a Waku node that is a `RELAY` node or a non-relay node.
+
+
+### Light Client:
+
+A Status client that operates within resource constrained environments is a node configured as light client.
+Light clients do not run a `RELAY`.
+Instead, Status light clients,
+can request services from other `RELAY` node that provide `LIGHTPUSH` service.
+
+## Protocol Usage
+
+The key words “MUST”, “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).
+
+The following is a list of Waku Protocols used by a Status application.
+
+### 1. `RELAY`
+
+The `RELAY` MUST NOT be used by Status light clients.
+The `RELAY` is used to broadcast messages between Status clients.
+All Status messages are transformed into [14/WAKU2-MESSAGE](/spec/14), which are sent over the wire.
+
+All Status message types are described in [62/STATUS-PAYLOAD](/spec/62).
+Status Clients MUST transform the following object into a `MESSAGE` as described below -
+
+```go
+
+type StatusMessage struct {
+    SymKey[]     []byte // [optional] The symmetric key used to encrypt the message
+    PublicKey    []byte // [optional] The public key to use for asymmetric encryption
+    Sig          string // [optional] The private key used to sign the message
+    PubsubTopic  string // The Pubsub topic to publish the message to     
+    ContentTopic string // The Content topic to publish the message to
+    Payload      []byte // A serialized representation of a Status message to be sent
+    Padding      []byte // Padding that must be applied to the Payload
+    TargetPeer   string // [optional] The target recipient of the message
+    Ephemeral    bool   // If the message is not to be stored, this is set to `true` 
+}
+
+```
+
+1. A user MUST only provide either a Symmetric key OR an Asymmetric keypair to encrypt the message.
+If both are received, the implementation MUST throw an error.
+2. `WakuMessage.Payload` MUST be set to `StatusMessage.Payload` 
+3. `WakuMessage.Key` MUST be set to `StatusMessage.SymKey`
+4. `WakuMessage.Version` MUST be set to `1`
+5. `WakuMessage.Ephemeral` MUST be set to `StatusMessage.Ephemeral`
+6. `WakuMessage.ContentTopic` MUST be set to `StatusMessage.ContentTopic`
+7. `WakuMessage.Timestamp` MUST be set to the current Unix epoch timestamp (in nanosecond precision)
+
+### 2. `STORE`
+
+This protocol MUST remain optional according to the user's preferences,
+it MAY be enabled on Light clients as well.
+
+Messages received via [11/WAKU2-RELAY](/spec/11), are stored in a database.
+When Waku node running this protocol is service node, 
+it MUST provide the complete list of network messages.
+Status clients SHOULD request historical messages from this service node.
+
+The messages that have the `WakuMessage.Ephemeral` flag set to true will not be stored.
+
+The Status client MAY provide a method to prune the database of older records to save storage.
+
+### 3. `FILTER`
+
+This protocol SHOULD be enabled on Light clients.
+
+This protocol SHOULD be used to filter messages based on a given criteria, such as the `Content Topic` of a `MESSAGE`.
+This allows a reduction in bandwidth consumption by the Status client.
+
+#### Content filtering protocol identifers:
+The `filter-subcribe` SHOULD be implemented on `RELAY` nodes to provide `FILTER` services.
+
+`filter-subscribe`:
+
+    /vac/waku/filter-subscribe/2.0.0-beta1
+
+The `filter-push` SHOULD be implemented on light clients to receive messages.
+
+`filter-push`:
+
+    /vac/waku/filter-push/2.0.0-beta1
+
+Status clients SHOULD apply a filter for all the `Content Topic` they are interested in, 
+such as `Content Topic` derived from -
+1. 1:1 chats with other users, described in [55/STATUS-1TO1-CHAT](/spec/55)
+2. Group chats
+3. Community Channels, described in [56/STATUS-COMMUNITIES](/spec/56)
+
+### 4. `LIGHTPUSH`
+
+The `LIGHTPUSH` protocol MUST be enabled on Status light clients.
+A Status `RELAY` node MAY implement `LIGHTPUSH` to support light clients. 
+Peers will be able to publish messages,
+without running a full-fledged [11/WAKU2-RELAY](/spec/11) protocol.
+
+When a Status client is publishing a message, 
+it MUST check if Light mode is enabled,
+and if so, it MUST publish the message via this protocol.
+
+### 5. Discovery
+
+A discovery method MUST be supported by Light clients and Full clients
+
+Status clients SHOULD make use of the following peer discovery methods that are provided by Waku,
+such as -
+
+1. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459)
+2. [33/WAKU2-DISCV5](/spec/33): 
+A node discovery protocol to create decentralized network of interconnected Waku nodes. 
+3. [34/WAKU2-PEER-EXCHANGE](/spec/34):
+A peer discovery protocol for resource restricted devices.
+
+Status clients MAY use any combination of the above peer discovery methods, 
+which is suited best for their implementation.
+
+## Security/Privacy Considerations
+
+This specification inherits the security and privacy considerations from the following specifications -
+
+1. [10/WAKU2](/spec/10)
+2. [11/WAKU2-RELAY](/spec/11)
+3. [12/WAKU2-FILTER](/spec/12)
+4. [13/WAKU2-STORE](/spec/13)
+5. [14/WAKU2-MESSAGE](/spec/14)
+6. [23/WAKU2-TOPICS](/spec/23)
+7. [19/WAKU2-LIGHTPUSH](/spec/19)
+8. [55/STATUS-1TO1-CHAT](/spec/55)
+9. [56/STATUS-COMMUNITIES](/spec/56)
+10. [62/STATUS-PAYLOAD](/spec/62)
+11. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459)
+12. [33/WAKU2-DISCV5](/spec/33)
+13. [34/WAKU2-PEER-EXCHANGE](/spec/34)
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+
+1. [55/STATUS-1TO1-CHAT](/spec/55)
+2. [56/STATUS-COMMUNITIES](/spec/56)
+3. [10/WAKU2](/spec/10)
+4. [11/WAKU2-RELAY](/spec/11)
+5. [12/WAKU2-FILTER](/spec/12)
+6. [13/WAKU2-STORE](/spec/13)
+7. [14/WAKU2-MESSAGE](/spec/14)
+8. [23/WAKU2-TOPICS](/spec/23)
+9. [19/WAKU2-LIGHTPUSH](/spec/19)
+10. [64/WAKU2-NETWORK](/spec/64)
+11. [62/STATUS-PAYLOAD](/spec/62)
+12. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459)
+13. [33/WAKU2-DISCV5](/spec/33)
+14. [34/WAKU2-PEER-EXCHANGE](/spec/34)

vac/25/libp2p-dns-discovery.md

@@ -9,7 +9,7 @@ contributors:
 
 `25/LIBP2P-DNS-DISCOVERY` specifies a scheme to implement [`libp2p`](https://libp2p.io/) peer discovery via DNS for Waku v2.
 The generalised purpose is to retrieve an arbitrarily long, authenticated, updateable list of [`libp2p` peers](https://docs.libp2p.io/concepts/peer-id/) to bootstrap connection to a `libp2p` network.
-Since [`10/WAKU2`](https://rfc.vac.dev/spec/10/) currently specifies use of [`libp2p` peer identities](https://docs.libp2p.io/concepts/peer-id/),
+Since [`10/WAKU2`](../../waku/standards/core/10/waku2.md) currently specifies use of [`libp2p` peer identities](https://docs.libp2p.io/concepts/peer-id/),
 this method is suitable for a new Waku v2 node to discover other Waku v2 nodes to connect to.
 
 This specification is largely based on [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459),
@@ -126,7 +126,7 @@ Copyright and related rights waived via
 
 # References
 
-1. [`10/WAKU2`](https://rfc.vac.dev/spec/10/)
+1. [`10/WAKU2`](../../waku/standards/core/10/waku2.md)
 1. [EIP-1459: Client Protocol](https://eips.ethereum.org/EIPS/eip-1459#client-protocol)
 1. [EIP-1459: Node Discovery via DNS ](https://eips.ethereum.org/EIPS/eip-1459)
 1. [`libp2p`](https://libp2p.io/)

vac/32/rln-v1.md

@@ -52,7 +52,7 @@ Depending on the application requirements, the registration can be implemented i
 - centralized registrations, by using a central server
 - decentralized registrations, by using a smart contract
 
-What is important is that the users' identity commitments (explained in section [User Indetity](#user-identity)) are stored in a Merkle tree,
+What is important is that the users' identity commitments (explained in section [User Identity](#user-identity)) are stored in a Merkle tree,
 and the users can obtain a Merkle proof proving that they are part of the group.
 
 Also depending on the application requirements,

vac/70/eth-secpm.md

@@ -1,7 +1,7 @@
 ---
 slug: 70
 title: 70/ETH-SECPM
-name: Private 1:1 messages over Ethereum
+name: Secure channel setup using Ethereum accounts
 status: raw
 category: Standards Track
 tags:
@@ -9,227 +9,802 @@ editor: Ramses Fernandez <ramses@status.im>
 contributors:
 ---
 
-## Abstract
-This document specifies an Ethereum-based private messaging service. 
-This proposal is built upon this [model](../../waku/standards/application/20/toy-eth-pm.md) and 
-amends the limitations of the latter concerning forward privacy and authentication. 
-The document is still work in progress. 
-Next steps will include a description of how to implement the different functions and algorithms in terms of the Noise framework.
+## Motivation
+The need for secure communications has become paramount. 
+Traditional centralized messaging protocols are susceptible to various security threats, 
+including unauthorized access, data breaches, and single points of failure. 
+Therefore a decentralized approach to secure communication becomes increasingly relevant, 
+offering a robust solution to address these challenges.
 
-## Background
+This specification outlines a private messaging service using the Ethereum blockchain as authentication service. 
+Rooted in the existing [model](../../waku/standards/application/20/toy-eth-pm.md), 
+this proposal addresses the deficiencies related to forward privacy and authentication inherent in the current framework.
+The specification is divided into 3 sections:
 
-Alice wants to send an encrypted message to Bob. 
-Here Bob is the only individual able to decrypt the message.
-Alice has access to Bob’s Ethereum address.
+- Private 1-to-1 communications protocol, based on [Signal's double ratchet](https://signal.org/docs/specifications/doubleratchet/).
+- Private group messaging protocol, based on the [MLS protocol](https://datatracker.ietf.org/doc/rfc9420/).
+- Description of an Ethereum-based authentication protocol, based on [SIWE](https://eips.ethereum.org/EIPS/eip-4361).
 
-## Theory and Description of the Protocol
 
-The proposed protocol must adhere to the following design requirements:
+## Private 1-to-1 communications protocol
+
+### Theory
+The specification is based on the noise protocol framework.
+It corresponds to the double ratchet scheme combined with the X3DH algorithm, which will be used to initialize the former. 
+We chose to express the protocol in noise to be be able to use the noise streamlined implementation and proving features.
+The X3DH algorithm provides both authentication and forward secrecy, as stated in the [X3DH specification](https://signal.org/docs/specifications/x3dh/).
+
+This protocol will consist of several stages:
+
+1.  Key setting for X3DH: this step will produce prekey bundles for Bob which will be fed into X3DH. It will also allow Alice to generate the keys required to run the X3DH algorithm correctly.
+2.  Execution of X3DH: This step will output a common secret key `SK` together with an additional data vector `AD`. Both will be used in the double ratchet algorithm initialization.
+3.  Execution of the double ratchet algorithm for forward secure, authenticated communications, using the common secret key `SK`, obtained from X3DH, as a root key.
+
+The protocol assumes the following requirements:
 -   Alice knows Bob’s Ethereum address.
 -   Bob is willing to participate in the protocol, and publishes his public key.
 -   Bob’s ownership of his public key is verifiable,
 -   Alice wants to send message M to Bob.
 -   An eavesdropper cannot read M’s content even if she is storing it or relaying it.
 
-The specification is based on the noise protocol framework.
-It corresponds to the double ratchet scheme combined with the X3DH algorithm, which will be used to initialize the former. 
-We chose to express the protocol in noise to be be able to use the noise streamlined implementation and proving features.
-The X3DH algorithm provides both authentication and forward secrecy, as stated in the [X3DH specification](https://signal.org/docs/specifications/x3dh/).
+### Syntax
+#### Cryptographic suite
+The following cryptographic functions MUST be used:
+- `X488` as Diffie-Hellman function `DH`.
+- `SHA256` as KDF.
+- `AES256-GCM` as AEAD algorithm.
+- `SHA512` as hash function.
+- `XEd448` for digital signatures.
 
-## High level description
-This protocol will consist of several stages:
+#### X3DH initialization
+This scheme MUST work on the curve curve448.
+The X3DH algorithm corresponds to the IX pattern in Noise.
 
-1.  Key setting for X3DH: this step will produce prekey bundles for Bob which will be fed into X3DH. It will also allow Alice to generate the keys required to run the X3DH algorithm correctly.
-2.  Execution of X3DH: This step will output a common secret key SK together with an additional data vector AD. Both will be used in the Double Ratchet algorithm initialization.
-3.  Execution of the Double Ratchet algorithm for forward secure, authenticated communications, using the common secret key SK, obtained from X3DH, as a root key.
+Bob and Alice MUST define personal key pairs `(ik_B, IK_B)` and `(ik_A, IK_A)` respectively where:
+-   The key `ik` must be kept secret,
+-   and the key `IK` is public.
 
-## Cryptographic functions required
--   XEd448 for digital signatures involved in the X3DH key generation.
--   SHA512 for hashing and the generation of HMACs.
--   AES256-CBC for the encryption/decryption of messages.
+Bob MUST generate new keys using `(ik_B, IK_B) = GENERATE_KEYPAIR(curve = curve448)`.
 
-## Considerations on the X3DH initialization
-This scheme requires working on specific elliptic curves which differ from those used by Ethereum. 
-To be precise, Ethereum makes use of the curve secp256k1, whereas X3DH requires either X25519 or X448. For security reasons one must work on the curve X448.
+Bob MUST also generate a public key pair `(spk_B, SPK_B) = GENERATE_KEYPAIR(curve = curve448)`.
 
-Bob and Alice must define a key pair (ik, IK) where:
--   The key ik must be kept secret,
--   and the key IK is public.
-
-Bob will not be able to use his Ethereum public key during this stage due to incompatibilities with the involved elliptic curves, therefore it will be required to generate new keys. 
-This can be done using the basepoint $G$ for X448 and $ik \in \mathbb{Z}_p$ a random integer:
-
-$$ IK = ik \cdot G $$
-
-The scheme X3DH will also require the generation of a public key SPK which will be generated repeating the above process: one takes $spk \in \mathbb{Z}_p$ a secret random integer and computes:
-
-$$ SPK = spk \cdot G $$
-
-SPK is a public key generated and stored at medium-term. 
-It is called a signed prekey because Bob also needs to store a public key certificate of SPK using IK. 
-Both signed prekey and the certificate must undergo periodic replacement, 
-a process that entails the generation of a fresh signed prekey. 
+`SPK` is a public key generated and stored at medium-term. 
+Both signed prekey and the certificate MUST undergo periodic replacement. 
 After replacing the key, 
-Bob keeps the old private key of SPK for some interval, dependant on the implementation.
+Bob keeps the old private key of `SPK` for some interval, dependant on the implementation.
 This allows Bob to decrypt delayed messages. 
-It is important that Bob does not reuse SPKs. 
-This action is pivotal for ensuring forward secrecy, as these keys are integral for recalculating the shared secret employed in decrypting historical messages.
 
-It will be required to sign SPK for authentication. Following the specification of X3DH, one will use the digital signature scheme XEd448 and define:
+Bob MUST sign `SPK` for authentication: `SigSPK = XEd448(ik, Encode(SPK))`
 
-$$ SigSPK = XEd448(ik, Encode(SPK)) $$
+A final step requires the definition of `prekey_bundle = (IK, SPK, SigSPK, OPK_i)`
 
-A final step requires the definition of a  _prekey bundle_  given by the tuple
+One-time keys `OPK` MUST be generated as `(opk_B, OPK_B) = GENERATE_KEYPAIR(curve = curve448)`.
 
-$$ prekey\_bundle = (IK, SPK, SigSPK, \{OPK_i\}_i) $$
+Before sending an initial message to Bob, Alice MUST generate an AD: `AD = Encode(IK_A) || Encode(IK_B)`.
 
-Where the different one-time keys OPK are points in X448 generated from a random integer $opk \in \mathbb{Z}_p$ and computed by performing
+Alice MUST generate ephemeral key pairs `(ek, EK) = GENERATE_KEYPAIR(curve = curve448)`.
 
-$$ OPK = opk\cdot G $$
-
-Before sending an initial message to Bob, Alice will generate an AD vector as described in the documentation:
-
-$$ AD = Encode(IK_A)|| Encode(IK_B) $$
-
-Alice will also need to generate ephemeral key pairs (ek, EK) following the above mechanisms, that is: ek is a random integer modulo p, and EK is the associated public key obtained from the product
-
-$$ EK = ek \cdot G $$
-
-The function Encode() transforms an X448 public key into a byte sequence. 
-The recommended encoding consists of a single-byte constant to represent the type of curve, followed by little-endian encoding of the u-coordinate. 
+The function `Encode()` transforms an curve448 public key into a byte sequence. 
 This is specified in the [RFC 7748](http://www.ietf.org/rfc/rfc7748.txt) on elliptic curves for security.
 
-## Using X3DH in Double Ratchet
+One MUST consider `q = 2^446 - 13818066809895115352007386748515426880336692474882178609894547503885` for digital signatures with `(XEd448_sign, XEd448_verify)`:
+```
+XEd448_sign((ik, IK), message):
+    Z = randbytes(64)  
+    r = SHA512(2^456 - 2 || ik || message || Z )
+    R = (r * convert_mont(5)) % q
+    h = SHA512(R || IK || M)
+    s = (r + h * ik) % q
+    return (R || s)
+```
+```
+XEd448_verify(u, message, (R || s)):
+    if (R.y >= 2^448) or (s >= 2^446): return FALSE
+    h = (SHA512(R || 156326 || message)) % q
+    R_check = s * convert_mont(5) - h * 156326
+    if R == R_check: return TRUE
+    return FALSE 
+```
+```
+convert_mont(u):
+    u_masked = u % mod 2^448
+    inv = ((1 - u_masked)^(2^448 - 2^224 - 3)) % (2^448 - 2^224 - 1)
+    P.y = ((1 + u_masked) * inv)) % (2^448 - 2^224 - 1)
+    P.s = 0
+    return P
+```
 
-According to [Signal specifications](https://signal.org/docs/specifications/doubleratchet/) 
-this specification uses the double ratchet in combination with X3DH using the following data as initialization for the former:
+#### Use of X3DH
+This specification combines the double ratchet with X3DH using the following data as initialization for the former:
 
--   The SK output from X3DH becomes the SK input of the double ratchet. See section 3.3 of [Signal Specification](https://signal.org/docs/specifications/doubleratchet/) for a detailed description.
--   The AD output from X3DH becomes the AD input of the double ratchet. See sections 3.4 and 3.5 of  [Signal Specification](https://signal.org/docs/specifications/doubleratchet/)  for a detailed description.
--   Bob’s signed prekey SigSPKB from X3DH is used as Bob’s initial ratchet public key of the double ratchet.
-
-Once this initialization has been set, Alice and Bob can start exchanging messages with forward secrecy and authentication.
-
-## Specification as a Noise protocol
+-   The `SK` output from X3DH becomes the `SK` input of the double ratchet. See section 3.3 of [Signal Specification](https://signal.org/docs/specifications/doubleratchet/) for a detailed description.
+-   The `AD` output from X3DH becomes the `AD` input of the double ratchet. See sections 3.4 and 3.5 of  [Signal Specification](https://signal.org/docs/specifications/doubleratchet/)  for a detailed description.
+-   Bob’s signed prekey `SigSPKB` from X3DH is used as Bob’s initial ratchet public key of the double ratchet.
 
 X3DH has three phases:
 
-1.  Bob publishes his identity key and prekeys to a server, or dedicated smart contract.
-2.  Alice fetches a "prekey bundle" from the server, and uses it to send an initial message to Bob.
+1.  Bob publishes his identity key and prekeys to a server, a network, or dedicated smart contract.
+2.  Alice fetches a prekey bundle from the server, and uses it to send an initial message to Bob.
 3.  Bob receives and processes Alice's initial message.
 
-One observes that, at the beginning of the protocol, the receiver gets the public key through a server, a smart contract in our situation, together with an encrypted ephemeral key. 
-This corresponds to the Noise pattern  **IX**:
+Alice MUST perform the following computations:
+```
+dh1 = DH(IK_A, SPK_B, curve = curve448)
+dh2 = DH(EK_A, IK_B, curve = curve448)
+dh3 = DH(EK_A, SPK_B)
+SK = KDF(dh1 || dh2 || dh3)
+```
+Alice MUST send to Bob a message containing: 
 
-→ e, s \
-← e, s, es, se, ee
+-  `IK_A, EK_A`.
+-  An identifier to Bob's prekeys used.
+-  A message encrypted with AES256-GCM using `AD` and `SK`.
 
-The Diffie-Hellman ratchet is run using the valid private key of the receiver in combination with the valid public included in the message coming from the sender. 
-This process is encoded, in Noise terms, as the DH() function. 
-This function will have inputs the secret key of the user running the function, and the public key of the external user. 
-Receiver and sender MUST generate valid key pairs, i.e. points of the X448, using the Noise function GENERATE_KEYPAIR().
+Upon reception of the initial message, Bob MUST:
+1. Perform the same computations above with the `DH()` function.
+2. Derive `SK` and construct `AD`.
+3. Decrypt the initial message encrypted with `AES256-GCM`.
+4. If decryption fails, abort the protocol.
 
-The Key Derivation Function (KDF) ratchet and the associated encryption protocols used by the double ratchet are also included by the Noise framework: 
-SHA256 for the KDF and AES256 for AEAD encryption.
+#### Initialization of the double datchet
+In this stage Bob and Alice have generated key pairs and agreed a shared secret `SK` using X3DH.
 
-Consequently, according to the Noise framework specifications, the X3DH algorithm is encoded as  **Noise_IX_448_AES256GCM_SHA256**
+Alice calls `RatchetInitAlice()` defined below:
+```
+RatchetInitAlice(SK, IK_B):
+    state.DHs = GENERATE_KEYPAIR(curve = curve448)
+    state.DHr = IK_B
+    state.RK, state.CKs = HKDF(SK, DH(state.DHs, state.DHr)) 
+    state.CKr = None
+    state.Ns, state.Nr, state.PN = 0
+    state.MKSKIPPED = {}
+```
+The HKDF function MUST be the proposal by [Krawczyk and Eronen](http://www.ietf.org/rfc/rfc5869.txt).
+In this proposal `chaining_key` and `input_key_material` MUST be replaced with `SK` and the output of `DH` respectively.
 
-## Retrieving information
+Similarly, Bob calls the function `RatchetInitBob()` defined below:
+```
+RatchetInitBob(SK, (ik_B,IK_B)):
+    state.DHs = (ik_B, IK_B)
+    state.Dhr = None
+    state.RK = SK
+    state.CKs, state.CKr = None
+    state.Ns, state.Nr, state.PN = 0
+    state.MKSKIPPED = {}
+```
+#### Encryption
+This function performs the symmetric key ratchet.
+
+```
+RatchetEncrypt(state, plaintext, AD):
+    state.CKs, mk = HMAC-SHA256(state.CKs)
+    header = HEADER(state.DHs, state.PN, state.Ns)
+    state.Ns = state.Ns + 1
+	return header, AES256-GCM_Enc(mk, plaintext, AD || header)
+```
+The `HEADER` function creates a new message header containing the public key from the key pair output of the `DH`function.  
+It outputs the previous chain length `pn`, and the message number `n`. 
+The returned header object contains ratchet public key `dh` and integers `pn` and `n`.
+
+#### Decryption
+The function `RatchetDecrypt()` decrypts incoming messages:
+```
+RatchetDecrypt(state, header, ciphertext, AD):
+    plaintext = TrySkippedMessageKeys(state, header, ciphertext, AD)
+    if plaintext != None:
+        return plaintext
+    if header.dh != state.DHr:
+        SkipMessageKeys(state, header.pn)
+        DHRatchet(state, header)
+    SkipMessageKeys(state, header.n)
+    state.CKr, mk = HMAC-SHA256(state.CKr)
+    state.Nr = state.Nr + 1
+    return AES256-GCM_Dec(mk, ciphertext, AD || header)
+```
+Auxiliary functions follow:
+
+```
+DHRatchet(state, header):
+    state.PN = state.Ns
+    state.Ns = state.Nr = 0
+    state.DHr = header.dh
+    state.RK, state.CKr = HKDF(state.RK, DH(state.DHs, state.DHr))
+    state.DHs = GENERATE_KEYPAIR(curve = curve448)
+    state.RK, state.CKs = HKDF(state.RK, DH(state.DHs, state.DHr))
+```
+```
+SkipMessageKeys(state, until):
+    if state.NR + MAX_SKIP < until:
+        raise Error
+    if state.CKr != none:
+        while state.Nr < until:
+            state.CKr, mk = HMAC-SHA256(state.CKr)
+            state.MKSKIPPED[state.DHr, state.Nr] = mk
+            state.Nr = state.Nr + 1
+```
+```
+TrySkippedMessageKey(state, header, ciphertext, AD):
+    if (header.dh, header.n) in state.MKSKIPPED:
+        mk = state.MKSKIPPED[header.dh, header.n]
+        delete state.MKSKIPPED[header.dh, header.n]
+        return AES256-GCM_Dec(mk, ciphertext, AD || header)
+    else: return None
+```
+
+## Information retrieval
 
 ### Static data
+Some data, such as the key pairs `(ik, IK)` for Alice and Bob, MAY NOT be regenerated after a period of time. 
+Therefore the prekey bundle MAY be stored in long-term storage solutions, such as a dedicated smart contract which outputs such a key pair when receiving an Ethereum wallet address.
 
-Some data, such as the key pairs (ik, IK) for Alice and Bob, do not need to be regenerated after a period of time. 
-Therefore the public keys IK can be stored in long-term storage solutions, such as a dedicated smart contract which outputs such a key pair when receiving an Ethereum wallet address.
+Storing static data is done using a dedicated smart contract `PublicKeyStorage` which associates the Ethereum wallet address of a user with his public key.
+This mapping is done by `PublicKeyStorage` using a `publicKeys` function, or a `setPublicKey` function.
+This mapping is done if the user passed an authorization process.
+A user who wants to retrieve a public key associated with a specific wallet address calls a function `getPublicKey`.
+The user provides the wallet address as the only input parameter for `getPublicKey`.
+The function outputs the associated public key from the smart contract.
 
 ### Ephemeral data
-
-Storing ephemeral data on Ethereum can be done using a combination of on-chain and off-chain solutions. 
+Storing ephemeral data on Ethereum MAY be done using a combination of on-chain and off-chain solutions. 
 This approach provides an efficient solution to the problem of storing updatable data in Ethereum.
-1. Ethereum can store a reference or a hash that points to the off-chain data.
+1. Ethereum stores a reference or a hash that points to the off-chain data.
 2. Off-chain solutions can include systems like IPFS, traditional cloud storage solutions, or decentralized storage networks such as a [Swarm](https://www.ethswarm.org). 
 In any case, the user stores the associated IPFS hash, URL or reference in Ethereum.
 
 The fact of a user not updating the ephemeral information can be understood as Bob not willing to participate in any communication.
 
-### Interaction with Ethereum
+This applies to `KeyPackage`, which in the MLS specification are meant to be stored in a directory provided by the delivery service.
+If such an element does not exist, `KeyPackage` MUST be stored according to one of the two options outlined above.
 
-Storing static data is done using a dedicated smart contract *PublicKeyStorage* which associates the Ethereum wallet address of a user with his public key.
-This mapping is done by PublicKeyStorage using a *publicKeys* function, or a *setPublicKey* function.
-This mapping is done if the user passed an authorization process.
-A user who wants to retrieve a public key associated with a specific wallet address calls a function *getPublicKey*.
-The user provides the wallet address as the only input parameter for *getPublicKey*.
-The function outputs the associated public key from the smart contract.
+## Private group messaging protocol
+### Theory
+The [Messaging Layer Security](https://datatracker.ietf.org/doc/rfc9420/)(MLS) protocol aims at providing a group of users with end-to-end encryption in an authenticated and asynchronous way. 
+The main security characteristics of the protocol are: Message confidentiality and authentication, sender authentication, 
+membership agreement, post-remove and post-update security, and forward secrecy and post-compromise security.
+The MLS protocol achieves: low-complexity, group integrity, synchronization and extensibility.
 
-## Extension to group chat
+The extension to group chat described in forthcoming sections is built upon the [MLS](https://datatracker.ietf.org/doc/rfc9420/) protocol.
 
-### 1-to-1 version
+### Syntax
+Each MLS session uses a single cipher suite that specifies the primitives to be used in group key computations. The cipher suite MUST use:
+- `X488` as Diffie-Hellman function.
+- `SHA256` as KDF.
+- `AES256-GCM` as AEAD algorithm.
+- `SHA512` as hash function.
+- `XEd448` for digital signatures.
 
-In order to extend the protocol to a group chat, this document specifies using an Asynchronous Distributed Key Generation (ADKG) to replace the X3DH step in the previous combination X3DH + Double Ratchet.
+Formats for public keys, signatures and public-key encryption MUST follow Section 5.1 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
 
-Distributed Key Generation (DKG) is a method for initiating threshold cryptosystems in a decentralized manner, all without the need for a trusted third party. 
-DKG serves as a fundamental component for numerous decentralized protocols, including systems like randomness beacons, threshold signatures, Byzantine consensus, and multiparty computation.
+### Hash-based identifiers
+Some MLS messages refer to other MLS objects by hash.
+These identifiers MUST be computed according to Section 5.2 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
 
-Most DKG protocols assume synchronous networks. 
-Asynchronous DKG (ADKG) has been studied only recently and the state-of-the-art high-threshold ADKG protocols is very inefficient compared to its low-threshold counterpart. 
+### Credentials
+Each member of a group presents a credential that provides one or more identities for the member and associates them with the member's signing key. 
+The identities and signing key are verified by the Authentication Service in use for a group.
 
-Here low-threshold means that the reconstruction threshold is set to be one higher than the number of corrupt nodes, 
-whereas high-threshold protocols admit reconstruction thresholds much higher than the number of malicious nodes.
+Credentials MUST follow the specifications of section 5.3 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).  
 
-Existing ADKG constructions tend to become inefficient when the reconstruction threshold surpasses one-third of the total nodes. 
-In this proposal we suggest using the scheme by [Kokoris-Kogias et al.](https://eprint.iacr.org/2022/1389) which is designed for $n = 3t + 1$ nodes. 
+### Message framing
+Handshake and application messages use a common framing structure providing encryption to ensure confidentiality within the group, and signing to authenticate the sender.
 
-This protocol can withstand the presence of up to t malicious nodes and can adapt to any reconstruction threshold in $l \in [t, n-t-1]$. 
-The key point of the proposal is an asynchronous method for securely distributing a random polynomial of degree $l\geq t$. 
-The proposal includes [Python and Rust implementations](https://github.com/sourav1547/htadkg).
+The structure is:
+- `PublicMessage`: represents a message that is only signed, and not encrypted.
+The definition and the encoding/decoding of a `PublicMessage` MUST follow the specification in section 6.2 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+- `PrivateMessage`: represents a signed and encrypted message, with protections for both the content of the message and related metadata.
+The definition, and the encoding/decoding of a `PrivateMessage` MUST follow the specification in section 6.3 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
 
-The DKG suggested makes assumes the existence of a PKI. 
-In case of requiring removing such assumption, one can replace the VSS scheme with the [Alhaddad et al.](https://eprint.iacr.org/2021/118) at the price of increasing the complexity.
+Applications MUST use `PrivateMessage` to encrypt application messages. 
 
-The output of the DKG may be an integer (modulo a prime), 
-meaning that one should apply a KDF to that output 
-in order to obtain a result which could be used as an input for the double ratchet.
+Applications SHOULD use `PrivateMessage` to encode handshake messages.
 
-One observes that using an ADKG allows a set of users, 
-which want to define a group chat, 
-defining a common secret key which will be used as a root key for the double ratchet. 
-Using an ADKG defines a room key, 
-which essentially defines the group itself.
+Each encrypted MLS message carries a "generation" number which is a per-sender incrementing counter. 
+If a group member observes a gap in the generation sequence for a sender, 
+then they know that they have missed a message from that sender.
 
+### Nodes contents
+The nodes of a ratchet tree contain several types of data:
 
-This approach share similarities with the point of view of [Farcaster](https://github.com/farcasterxyz/protocol/discussions/99).
+- Leaf nodes describe individual members.
+- Parent nodes describe subgroups.
 
-Once the double ratchet is initialized, 
-the communication in this group is 1-to-1, 
-meaning that group member C cannot see the messages between group members A and B. 
-The fact of defining a room key makes impossible for outsiders to communicate with group members if the latter are not willing to.
+Contents of each kind of node, and its structure MUST follow the indications described in sections 7.1 and 7.2 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
 
-### n-to-n version
+### Leaf node validation
+`KeyPackage` objects describe the client's capabilities and provides keys that can be used to add the client to a group.
 
-Using the above approach leads to a situation where a group of users can set a group for 1-to-1 messages,
-meaning that any group member external to a communication between any other two members will not be able to read the contents of the messages.
+The validity of a leaf node needs to be verified at the following stages:
+- When a leaf node is downloaded in a `KeyPackage`, before it is used to add the client to the group.
+- When a leaf node is received by a group member in an Add, Update, or Commit message.
+- When a client validates a ratchet tree.
 
-An approach to generalize this situation to the setting of a group of users exchanging messages without any kind of restriction is using asynchronous ratcheting trees, as suggested in the proposal from [Cohn-Gordon et al.](https://eprint.iacr.org/2017/666) where a group of people can derive a shared secret key even in the event of if no two users are ever online at the same time. 
-The proposal suggested provides both forward secrecy and post-compromise security. 
-The shared key can be then used in any symmetric encryption scheme, such as AES256.
+A client MUST verify the validity of a leaf node following the instructions of section 7.3 in [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Ratchet tree evolution
+Whenever a member initiates an epoch change, they MAY need to refresh the key pairs of their leaf and of the nodes on their direct path. This is done to keep forward secrecy and post-compromise security.
+The member initiating the epoch change MUST follow this procedure procedure.
+A member updates the nodes along its direct path as follows:
+- Blank all the nodes on the direct path from the leaf to the root.
+- Generate a fresh HPKE key pair for the leaf.
+- Generate a sequence of path secrets, one for each node on the leaf's filtered direct path.
+It MUST follow the procedure described in section 7.4 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+- Compute the sequence of HPKE key pairs `(node_priv,node_pub)`, one for each node on the leaf's direct path.
+It MUST follow the procedure described in section 7.4 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Views of the tree synchronization
+After generating fresh key material and applying it to update their local tree state, the generator broadcasts this update to other members of the group.
+This operation MUST be done according to section 7.5 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Leaf synchronization
+Changes to group memberships MUST be represented by adding and removing leaves of the tree.
+This corresponds to increasing or decreasing the depth of the tree, resulting in the number of leaves being doubled or halved.
+These operations MUST be done as described in section 7.7 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Tree and parent hashing
+Group members can agree on the cryptographic state of the group by generating a hash value that represents the contents of the group ratchet tree and the member’s credentials. 
+The hash of the tree is the hash of its root node, defined recursively from the leaves.
+Tree hashes summarize the state of a tree at point in time.
+The hash of a leaf is the hash of the `LeafNodeHashInput` object. 
+At the same time, the hash of a parent node including the root, is the hash of a `ParentNodeHashInput` object.
+Parent hashes capture information about how keys in the tree were populated.
+
+Tree and parent hashing MUST follow the directions in Sections 7.8 and 7.9 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Key schedule
+Group keys are derived using the `Extract` and `Expand` functions from the KDF for the group's cipher suite, as well as the functions defined below:
+
+```
+ExpandWithLabel(Secret, Label, Context, Length) = KDF.Expand(Secret, KDFLabel, Length)
+DeriveSecret(Secret, Label) = ExpandWithLabel(Secret, Label, "", KDF.Nh)
+```
+`KDFLabel` MUST be specified as:
+```
+struct {
+    uint16 length;
+    opaque label<V>;
+    opaque context<V>;
+} KDFLabel;
+```
+The fields of `KDFLabel` MUST be:
+```
+length = Length;
+label = "MLS 1.0 " + Label;
+context = Context;
+```
+
+Each member of the group MUST maintaint a `GroupContext` object summarizing the state of the group. 
+The sturcture of such object MUST be:
+
+```
+struct {
+ProtocolVersion version = mls10;
+CipherSuite cipher_suite;
+opaque group_id<V>;
+uint64 epoch;
+opaque tree_hash<V>;
+opaque confirmed_trasncript_hash<V>;
+Extension extension<V>;
+} GroupContext;
+```
+
+The use of key scheduling MUST follow the indications in sections 8.1 - 8.7 in [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Secret trees
+For the generation of encryption keys and nonces, the key schedule begins with the `encryption_secret` at the root and derives a tree of secrets with the same structure as the group's ratchet tree.
+Each leaf in the secret tree is associated with the same group member as the corresponding leaf in the ratchet tree.
+
+If `N` is a parent node in the secret tree, the secrets of the children of `N` MUST be defined following section 9 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+#### Encryption keys
+
+MLS encrypts three different types of information:
+- Metadata (sender information).
+- Handshake messages (Proposal and Commit).
+- Application messages.
+
+For handshake and application messages, a sequence of keys is derived via a sender ratchet. 
+Each sender has their own sender ratchet, and each step along the ratchet is called a generation. These procedures MUST follow section 9.1 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+#### Deletion schedule
+
+All security-sensitive values MUST be deleted as soon as they are consumed. 
+A sensitive value S is consumed if:
+
+- S was used to encrypt or (successfully) decrypt a message. 
+- A key, nonce, or secret derived from S has been consumed.
+
+The deletion procedure MUST follow the instruction described in section 9.2 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Key packages
+KeyPackage objects are used to ease the addition of clients to a group asynchronously.
+A KeyPackage object specifies:
+
+- Protocol version and cipher suite supported by the client.
+- Public keys that can be used to encrypt Welcome messages. Welcome messages provide new members with the information to initialize their state for the epoch in which they were added or in which they want to add themselves to the group
+- The content of the leaf node that should be added to the tree to represent this client.
+
+KeyPackages are intended to be used only once and SHOULD NOT be reused. 
+
+Clients MAY generate and publish multiple KeyPackages to support multiple cipher suites.
+
+The structure of the object MUST be:
+```
+struct {
+ProtocolVersion version;
+CipherSuite cipher_suite;
+HPKEPublicKey init_key;
+LeafNode leaf_node;
+Extension extensions<V>;
+/* SignWithLabel(., "KeyPackageTBS", KeyPackageTBS) */
+opaque signature<V>;
+}
+```
+```
+struct {
+ProtocolVersion version;
+CipheSuite cipher_suite;
+HPKEPublicKey init_key;
+LeafNode leaf_node;
+Extension extensions<V>;
+}
+```
+`KeyPackage` object MUST be verified when:
+- A `KeyPackage` is downloaded by a group member, before it is used to add the client to the group.
+- When a `KeyPackage` is received by a group member in an `Add` message.
+
+Verification MUST be done as follows:
+- Verify that the cipher suite and protocol version of the `KeyPackage` match those in the `GroupContext`.
+- Verify that the `leaf_node` of the `KeyPackage` is valid for a `KeyPackage`.
+- Verify that the signature on the `KeyPackage` is valid.
+- Verify that the value of `leaf_node.encryption_key` is different from the value of the `init_key field`.
+
+HPKE public keys are opaque values in a format defined by Section 4 of [RFC9180](https://datatracker.ietf.org/doc/rfc9180/).
+
+Signature public keys are represented as opaque values in a format defined by the cipher suite's signature scheme.
+
+### Group creation
+A group is always created with a single member. 
+Other members are then added to the group using the usual Add/Commit mechanism.
+The creator of a group MUST set:
+- the group ID. 
+- cipher suite.
+- initial extensions for the group. 
+
+If the creator intends to add other members at the time of creation, then it SHOULD fetch `KeyPackages` for those members, and select a cipher suite and extensions according to their capabilities. 
+
+The creator MUST use the capabilities information in these `KeyPackages` to verify that the chosen version and cipher suite is the best option supported by all members.
+
+Group IDs SHOULD be constructed so they are unique with high probability. 
+
+To initialize a group, the creator of the group MUST initialize a one-member group with the following initial values:
+- Ratchet tree: A tree with a single node, a leaf node containing an HPKE public key and credential for the creator.
+- Group ID: A value set by the creator.
+- Epoch: `0`.
+- Tree hash: The root hash of the above ratchet tree.
+- Confirmed transcript hash: The zero-length octet string.
+- Epoch secret: A fresh random value of size `KDF.Nh`.
+- Extensions: Any values of the creator's choosing.
+
+The creator MUST also calculate the interim transcript hash:
+- Derive the `confirmation_key` for the epoch according to Section 8 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+- Compute a `confirmation_tag` over the empty `confirmed_transcript_hash` using the `confirmation_key` as described in Section 8.1 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+- Compute the updated `interim_transcript_hash` from the `confirmed_transcript_hash` and the `confirmation_tag` as described in Section 8.2 [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+All members of a group MUST support the cipher suite and protocol version in use. Additional requirements MAY be imposed by including a `required_capabilities` extension in the `GroupContext`.
+
+```
+struct {
+ExtensionType extension_types<V>;
+ProposalType proposal_types<V>;
+CredentialType credential_types<V>;
+}
+```
+
+### Group evolution
+Group membership can change, and existing members can change their keys in order to achieve post-compromise security. 
+In MLS, each such change is accomplished by a two-step process:
+- A proposal to make the change is broadcast to the group in a Proposal message.
+- A member of the group or a new member broadcasts a Commit message that causes one or more proposed changes to enter into effect.
+
+The group evolves from one cryptographic state to another each time a Commit message is sent and processed. 
+These states are called epochs and are uniquely identified among states of the group by eight-octet epoch values. 
+
+Proposals are included in a `FramedContent` by way of a `Proposal` structure that indicates their type:
+
+```
+struct {
+ProposalType proposal_type;
+select (Proposal.proposal_type) {
+case add:			Add:
+case update:			Update;
+case remove:			Remove;
+case psk:			PreSharedKey;
+case reinit:			ReInit;
+case external_init:		ExternalInit;
+case group_context_extensions:	GroupContextExtensions;
+}
+```
+On receiving a `FramedContent` containing a `Proposal`, a client MUST verify the signature inside `FramedContentAuthData` and that the epoch field of the enclosing FramedContent is equal to the epoch field of the current GroupContext object. 
+If the verification is successful, then the Proposal SHOULD be cached in such a way that it can be retrieved by hash in a later Commit message.
+
+Proposals are organized as follows:
+- `Add`: requests that a client with a specified KeyPackage be added to the group.
+- `Update`: similar to Add, it replaces the sender's LeafNode in the tree instead of adding a new leaf to the tree.
+- `Remove`: requests that the member with the leaf index removed be removed from the group.
+- `ReInit`: requests to reinitialize the group with different parameters.
+- `ExternalInit`: used by new members that want to join a group by using an external commit.
+- `GroupContentExtensions`: it is used to update the list of extensions in the GroupContext for the group.
+
+Proposals structure and semantics MUST follow sections 12.1.1 - 12.1.7 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+Any list of commited proposals MUST be validated either by a the group member who created the commit, or any group member processing such commit.
+The validation MUST be done according to one of the procedures described in Section 12.2 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+When creating or processing a Commit, a client applies a list of proposals to the ratchet tree and `GroupContext`. 
+The client MUST apply the proposals in the list in the order described in Section 12.3 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Commit messages
+Commit messages initiate new group epochs. 
+It informs group members to update their representation of the state of the group by applying the proposals and advancing the key schedule.
+
+Each proposal covered by the Commit is included by a `ProposalOrRef` value.
+`ProposalOrRef` identify the proposal to be applied by value or by reference. 
+Commits that refer to new Proposals from the committer can be included by value. 
+Commits for previously sent proposals from anyone can be sent by reference. 
+Proposals sent by reference are specified by including the hash of the `AuthenticatedContent`.
+
+Group members that have observed one or more valid proposals within an epoch MUST send a Commit message before sending application data.
+A sender and a receiver of a Commit MUST verify that the committed list of proposals is valid.
+The sender of a Commit SHOULD include all valid proposals received during the current epoch.
+
+Functioning of commits MUST follow the instructions of Section 12.4 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Application messages
+Handshake messages provide an authenticated group key exchange to clients. 
+To protect application messages sent among the members of a group, the `encryption_secret` provided by the key schedule is used to derive a sequence of nonces and keys for message encryption.
+
+Each client MUST maintain their local copy of the key schedule for each epoch during which they are a group member. 
+They derive new keys, nonces, and secrets as needed. This data MUST be deleted as soon as they have been used.
+
+Group members MUST use the AEAD algorithm associated with the negotiated MLS ciphersuite to encrypt and decrypt Application messages according to the Message Framing section.
+The group identifier and epoch allow a device to know which group secrets should be used and from which Epoch secret to start computing other secrets and keys. 
+Application messages SHOULD be padded to provide resistance against traffic analysis techniques. 
+This avoids additional information to be provided to an attacker in order to guess the length of the encrypted message.
+Padding SHOULD be used on messages with zero-valued bytes before AEAD encryption.
+
+Functioning of application messages MUST follow the instructions of Section 15 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+### Considerations with respect to decentralization
+The MLS protocol assumes the existence on a (central, untrusted) *delivery service*, whose responsabilites include:
+
+- Acting as a directory service providing the initial keying material for clients to use.
+- Routing MLS messages among clients.
+
+The central delivery service can be avoided in protocols using the publish/gossip approach, such as [gossipsub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub).
+
+Concerning keys, each node can generate and disseminate their encryption key among the other nodes, so they can create a local version of the tree that allows for the generation of the group key.
+
+Another important component is the *authentication service*, which is replaced with SIWE in this specification. 
+
+## Ethereum-based authentication protocol
+### Theory
+Sign-in with Ethereum describes how Ethereum accounts authenticate with off-chain services by signing a standard message format 
+parameterized by scope, session details, and security mechanisms.
+Sign-in with Ethereum (SIWE), which is described in the [EIP 4361](https://eips.ethereum.org/EIPS/eip-4361), MUST be the authentication method required. 
+
+### Syntax
+#### Message format (ABNF)
+A SIWE Message MUST conform with the following Augmented Backus–Naur Form ([RFC 5234](https://datatracker.ietf.org/doc/html/rfc5234)) expression.
+
+```
+sign-in-with-ethereum =
+    [ scheme "://" ] domain %s" wants you to sign in with your Ethereum account:" LF
+    address LF
+    LF
+    [ statement LF ]
+    LF
+    %s"URI: " uri LF
+    %s"Version: " version LF
+    %s"Chain ID: " chain-id LF
+    %s"Nonce: " nonce LF
+    %s"Issued At: " issued-at
+    [ LF %s"Expiration Time: " expiration-time ]
+    [ LF %s"Not Before: " not-before ]
+    [ LF %s"Request ID: " request-id ]
+    [ LF %s"Resources:"
+    resources ]
+
+scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
+    ; See RFC 3986 for the fully contextualized
+    ; definition of "scheme".
+
+domain = authority
+    ; From RFC 3986:
+    ;     authority     = [ userinfo "@" ] host [ ":" port ]
+    ; See RFC 3986 for the fully contextualized
+    ; definition of "authority".
+
+address = "0x" 40*40HEXDIG
+    ; Must also conform to captilization
+    ; checksum encoding specified in EIP-55
+    ; where applicable (EOAs).
+
+statement = *( reserved / unreserved / " " )
+    ; See RFC 3986 for the definition
+    ; of "reserved" and "unreserved".
+    ; The purpose is to exclude LF (line break).
+
+uri = URI
+    ; See RFC 3986 for the definition of "URI".
+
+version = "1"
+
+chain-id = 1*DIGIT
+    ; See EIP-155 for valid CHAIN_IDs.
+
+nonce = 8*( ALPHA / DIGIT )
+    ; See RFC 5234 for the definition
+    ; of "ALPHA" and "DIGIT".
+
+issued-at = date-time
+expiration-time = date-time
+not-before = date-time
+    ; See RFC 3339 (ISO 8601) for the
+    ; definition of "date-time".
+
+request-id = *pchar
+    ; See RFC 3986 for the definition of "pchar".
+
+resources = *( LF resource )
+
+resource = "- " URI
+```
+
+This specification defines the following SIWE Message fields that can be parsed from a SIWE Message by following the rules in ABNF Message Format:
+
+- `scheme` OPTIONAL. The URI scheme of the origin of the request. 
+Its value MUST be a [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) URI scheme.
+
+- `domain` REQUIRED. The domain that is requesting the signing. 
+Its value MUST be a [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) authority. The authority includes an OPTIONAL port. 
+If the port is not specified, the default port for the provided scheme is assumed. 
+
+If scheme is not specified, HTTPS is assumed by default.
+- `address` REQUIRED. The Ethereum address performing the signing. 
+Its value SHOULD be conformant to mixed-case checksum address encoding specified in ERC-55 where applicable.
+
+- `statement` OPTIONAL. A human-readable ASCII assertion that the user will sign which MUST NOT include '\n' (the byte 0x0a).
+- `uri` REQUIRED. An [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) URI referring to the resource that is the subject of the signing.
+
+- `version` REQUIRED. The current version of the SIWE Message, which MUST be 1 for this specification.
+
+- `chain-id` REQUIRED. The EIP-155 Chain ID to which the session is bound, and the network where Contract Accounts MUST be resolved.
+
+- `nonce` REQUIRED. A random string (minimum 8 alphanumeric characters) chosen by the relying party and used to prevent replay attacks.
+
+- `issued-at` REQUIRED. The time when the message was generated, typically the current time. 
+Its value MUST be an ISO 8601 datetime string.
+
+- `expiration-time` OPTIONAL. The time when the signed authentication message is no longer valid. 
+Its value MUST be an ISO 8601 datetime string.
+
+- `not-before` OPTIONAL. The time when the signed authentication message will become valid. 
+Its value MUST be an ISO 8601 datetime string.
+
+- `request-id` OPTIONAL. An system-specific identifier that MAY be used to uniquely refer to the sign-in request.
+
+- `resources` OPTIONAL. A list of information or references to information the user wishes to have resolved as part of authentication by the relying party. 
+Every resource MUST be a RFC 3986 URI separated by "\n- " where \n is the byte 0x0a.
+
+#### Signing and Verifying Messages with Ethereum Accounts
+- For Externally Owned Accounts, the verification method specified in [ERC-191](https://eips.ethereum.org/EIPS/eip-191) MUST be used.
+
+- For Contract Accounts,
+
+	- The verification method specified in [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271) SHOULD be used. 
+Otherwise, the implementer MUST clearly define the verification method to attain security and interoperability for both wallets and relying parties.
+
+	- When performing [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271) signature verification, the contract performing the verification MUST be resolved from the specified `chain-id`.
+
+	- Implementers SHOULD take into consideration that [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271) implementations are not required to be pure functions. 
+They can return different results for the same inputs depending on blockchain state. 
+This can affect the security model and session validation rules.
+
+#### Resolving Ethereum Name Service (ENS) Data
+- The relying party or wallet MAY additionally perform resolution of ENS data, as this can improve the user experience by displaying human-friendly information that is related to the `address`. 
+Resolvable ENS data include:
+	- The primary ENS name.
+	- The ENS avatar.
+	- Any other resolvable resources specified in the ENS documentation.
+
+- If resolution of ENS data is performed, implementers SHOULD take precautions to preserve user privacy and consent. 
+Their `address` could be forwarded to third party services as part of the resolution process.
+
+#### Implementer steps: specifying the request origin
+The `domain` and, if present, the `scheme`, in the SIWE Message MUST correspond to the origin from where the signing request was made. 
+
+#### Implementer steps: verifying a signed message
+The SIWE Message MUST be checked for conformance to the ABNF Message Format and its signature MUST be checked as defined in Signing and Verifying Messages with Ethereum Accounts.
+
+#### Implementer steps: creating sessions
+Sessions MUST be bound to the address and not to further resolved resources that can change.
+
+#### Implementer steps: interpreting and resolving resources
+Implementers SHOULD ensure that that URIs in the listed resources are human-friendly when expressed in plaintext form.
+
+#### Wallet implementer steps: verifying the message format
+The full SIWE message MUST be checked for conformance to the ABNF defined in ABNF Message Format.
+
+Wallet implementers SHOULD warn users if the substring `"wants you to sign in with your Ethereum account"` appears anywhere in an [ERC-191](https://eips.ethereum.org/EIPS/eip-191) message signing request unless the message fully conforms to the format defined ABNF Message Format.
+
+#### Wallet implementer steps: verifying the request origin
+Wallet implementers MUST prevent phishing attacks by verifying the origin of the request against the `scheme` and `domain` fields in the SIWE Message. 
+
+The origin SHOULD be read from a trusted data source such as the browser window or over WalletConnect [ERC-1328](https://eips.ethereum.org/EIPS/eip-1328) sessions for comparison against the signing message contents.
+
+Wallet implementers MAY warn instead of rejecting the verification if the origin is pointing to localhost.
+
+The following is a RECOMMENDED algorithm for Wallets to conform with the requirements on request origin verification defined by this specification.
+
+The algorithm takes the following input variables:
+
+- fields from the SIWE message.
+- `origin` of the signing request: the origin of the page which requested the signin via the provider.
+- `allowedSchemes`: a list of schemes allowed by the Wallet.
+- `defaultScheme`: a scheme to assume when none was provided. Wallet implementers in the browser SHOULD use https.
+- developer mode indication: a setting deciding if certain risks should be a warning instead of rejection. Can be manually configured or derived from `origin` being localhost.
+
+The algorithm is described as follows:
+
+- If `scheme` was not provided, then assign `defaultScheme` as scheme.
+- If `scheme` is not contained in `allowedSchemes`, then the `scheme` is not expected and the Wallet MUST reject the request. 
+Wallet implementers in the browser SHOULD limit the list of allowedSchemes to just 'https' unless a developer mode is activated.
+- If `scheme` does not match the scheme of origin, the Wallet SHOULD reject the request. 
+Wallet implementers MAY show a warning instead of rejecting the request if a developer mode is activated. 
+In that case the Wallet continues processing the request.
+- If the `host` part of the `domain` and `origin` do not match, the Wallet MUST reject the request unless the Wallet is in developer mode. 
+In developer mode the Wallet MAY show a warning instead and continues procesing the request.
+- If `domain` and `origin` have mismatching subdomains, the Wallet SHOULD reject the request unless the Wallet is in developer mode. 
+In developer mode the Wallet MAY show a warning instead and continues procesing the request.
+- Let `port` be the port component of `domain`, and if no port is contained in domain, assign port the default port specified for the scheme.
+- If `port` is not empty, then the Wallet SHOULD show a warning if the `port` does not match the port of `origin`.
+- If `port` is empty, then the Wallet MAY show a warning if `origin` contains a specific port.
+- Return request origin verification completed.
+
+#### Wallet implementer steps: creating SIWE interfaces
+Wallet implementers MUST display to the user the following fields from the SIWE Message request by default and prior to signing, if they are present: `scheme`, `domain`, `address`, `statement`, and `resources`. 
+Other present fields MUST also be made available to the user prior to signing either by default or through an extended interface.
+
+Wallet implementers displaying a plaintext SIWE Message to the user SHOULD require the user to scroll to the bottom of the text area prior to signing.
+
+Wallet implementers MAY construct a custom SIWE user interface by parsing the ABNF terms into data elements for use in the interface. 
+The display rules above still apply to custom interfaces.
+
+#### Wallet implementer steps: supporting internationalization (i18n)
+After successfully parsing the message into ABNF terms, translation MAY happen at the UX level per human language.
 
 ## Privacy and Security Considerations
-
+- The double ratchet "recommends" using AES in CBC mode. Since encryption must be with an AEAD encryption scheme, we will use AES in GCM mode instead (supported by Noise).
 - For the information retrieval, the algorithm MUST include a access control mechanisms to restrict who can call the set and get functions.
 - One SHOULD include event logs to track changes in public keys.
-- The curve X448 MUST be chosen as the elliptic curve, since it offers a higher security level: 224-bit security instead of the 128-bit security provided by X25519.
-- Concerning the hardness of the ADKG, the proposal lies on the Discrete Logarithm assumption.
+- The curve vurve448 MUST be chosen due to its higher security level: 224-bit security instead of the 128-bit security provided by X25519.
+- It is important that Bob MUST NOT reuse `SPK`.
 
 ## Copyright
-
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
 
-## References
-
-- [model](../../waku/standards/application/20/toy-eth-pm.md)
-- https://signal.org/docs/specifications/x3dh/
-- https://signal.org/docs/specifications/doubleratchet/
-- https://eprint.iacr.org/2022/1389
-- https://github.com/sourav1547/htadkg
-- https://github.com/farcasterxyz/protocol/discussions/99
-
-
+# References
+- [Augmented BNF for Syntax Specifications](https://datatracker.ietf.org/doc/html/rfc5234)
+- [Gossipsub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub)
+- [HMAC-based Extract-and-Expand Key Derivation Function](https://www.ietf.org/rfc/rfc5869.txt)
+- [Hybrid Public Key Encryption](https://datatracker.ietf.org/doc/rfc9180/)
+- [Security Analysis and Improvements for the IETF MLS Standard for Group Messaging](https://eprint.iacr.org/2019/1189.pdf)
+- [Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191)
+- [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361)
+- [Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271)
+- [The Double Ratchet Algorithm](https://signal.org/docs/specifications/doubleratchet/)
+- [The Messaging Layer Security Protocol](https://datatracker.ietf.org/doc/rfc9420/)
+- [The X3DH Key Agreement Protocol](https://signal.org/docs/specifications/x3dh/)
+- [Toy Ethereum Private Messaging Protocol](https://rfc.vac.dev/spec/20/)
+- [Uniform Resource Identifier](https://datatracker.ietf.org/doc/html/rfc3986)
+- [WalletConnect URI Format](https://eips.ethereum.org/EIPS/eip-1328)

vac/raw/README.md

@@ -0,0 +1,4 @@
+# Vac Raw Specifications
+
+All Vac specifications that have not reached **draft** status will live in this repository.
+To learn more about **raw** specifications, take a look at [1/COSS](../1/coss.md).

vac/raw/rln-stealth-commitments.md

@@ -0,0 +1,105 @@
+---
+title: RLN-STEALTH-COMMITMENTS
+name: RLN Stealth Commitment Usage
+category: Standards Track
+editor: Aaryamann Challani <aaryamann@status.im>
+contributors:
+- Jimmy Debe <jimmy@status.im>
+---
+
+## Abstract
+
+This specification describes the usage of stealth commitments to add prospective users to a network-governed [32/RLN-V1](./32/rln-v1.md) membership set.
+
+## Motivation
+
+When [32/RLN-V1](./32/rln-v1.md) is enforced in [10/Waku2](../waku/standards/core/10/waku2.md), 
+all users are required to register to a membership set.
+The membership set will store user identities allowing the secure interaction within an application.
+Forcing a user to do an on-chain transaction to join a membership set is an onboarding friction, 
+and some projects may be opposed to this method.
+To improve the user experience,
+stealth commitments can be used by a counterparty to register identities on the user's behalf,
+while maintaining the user's anonymity.
+
+This document specifies a privacy-preserving mechanism,
+allowing a counterparty to utilize [32/RLN-V1](./32/rln-v1.md) to register an `identityCommitment` on-chain.
+Counterparties will be able to register members to a RLN membership set without exposing the user's private keys.
+
+## Background
+The [32/RLN-V1](./32/rln-v1.md) protocol, 
+consists of a smart contract that stores a `idenitityCommitment` in a membership set.
+In order for a user to join the membership set,
+the user is required to make a transaction on the blockchain.
+A set of public keys is used to compute a stealth commitment for a user,
+as described in [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564).
+This specification is an implementation of the [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) scheme, 
+tailored to the curve that is used in the [32/RLN-V1](./32/rln-v1.md) protocol.
+
+This can be used in a couple of ways in applications:
+1. Applications can add users to the [32/RLN-V1](./32/rln-v1.md) membership set in a batch.
+2. Users of the application can register other users to the [32/RLN-V1](./32/rln-v1.md) membership set.
+
+This is useful when the prospective user does not have access to funds on the network that [32/RLN-V1](./32/rln-v1.md) is deployed on.
+
+## Wire Format Specification
+
+The two parties, the requester and the receiver, MUST exchange the following information:
+
+```protobuf
+
+message Request {
+  // The spending public key of the requester
+  bytes spending_public_key = 1;
+
+  // The viewing public key of the requester
+  bytes viewing_public_key = 2;
+}
+
+```
+### Generate Stealth Commitment
+
+The application or user SHOULD generate a `stealth_commitment` after a request to do so is received.
+This commitment MAY be inserted into the corresponding application membership set.
+
+Once the membership set is updated, the receiver SHOULD exchange the following as a response to the request:
+
+```protobuf
+
+message Response {
+  
+  // The used to check if the stealth_commitment belongs to the requester
+  bytes view_tag = 2;
+
+  // The stealth commitment for the requester
+  bytes stealth_commitment = 3;
+
+  // The ephemeral public key used to generate the commitment
+  bytes ephemeral_public_key = 4;
+
+}
+
+```
+
+The receiver MUST generate an `ephemeral_public_key`, `view_tag` and `stealth_commitment`.
+This will be used to check the stealth commitment used to register to the membership set,
+and the user MUST be able to check ownership with their `viewing_public_key`.
+
+## Implementation Suggestions
+
+An implementation of the Stealth Address scheme is available in the [erc-5564-bn254](https://github.com/rymnc/erc-5564-bn254) repository,
+which also includes a test to generate a stealth commitment for a given user.
+
+## Security/Privacy Considerations
+
+This specification inherits the security and privacy considerations of the [Stealth Address](https://eips.ethereum.org/EIPS/eip-5564) scheme.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+- [10/Waku2](../waku/standards/core/10/waku2.md)
+- [32/RLN-V1](./32/rln-v1.md)
+- [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564)

waku/README.md

@@ -1,4 +1,4 @@
-## Waku RFCs
+# Waku RFCs
 
 Waku builds a family of privacy-preserving, censorship-resistant communication protocols for web3 applications.
 

waku/deprecated/16/rpc.md

@@ -2,7 +2,7 @@
 slug: 16
 title: 16/WAKU2-RPC
 name: Waku v2 RPC API
-status: draft
+status: deprecated
 tags: waku-core
 editor: Hanno Cornelius <hanno@status.im>
 ---
@@ -176,7 +176,7 @@ The `get_waku_v2_relay_v1_messages` method returns a list of messages that were
 
 ## Relay Private API
 
-The Private API provides functionality to encrypt/decrypt `WakuMessage` payloads using either symmetric or asymmetric cryptography. This allows backwards compatibility with [Waku v1 nodes](../6/waku1.md).
+The Private API provides functionality to encrypt/decrypt `WakuMessage` payloads using either symmetric or asymmetric cryptography. This allows backwards compatibility with [Waku v1 nodes](../../legacy/6/waku1.md).
 It is the API client's responsibility to keep track of the keys used for encrypted communication. Since keys must be cached by the client and provided to the node to encrypt/decrypt payloads, a Private API SHOULD NOT be exposed on non-local or untrusted nodes.
 
 ### Types

waku/deprecated/18/swap.md

@@ -2,7 +2,7 @@
 slug: 18
 title: 18/WAKU2-SWAP
 name: Waku SWAP Accounting
-status: draft
+status: deprecated
 editor: Oskar Thorén <oskarth@titanproxy.com>
 contributor: Ebube Ud <ebube@status.im>
 ---
@@ -141,7 +141,7 @@ In the soft phase only accounting is performed, without consequence for the
 peers. No disconnect or sending of cheques is performed at this tage.
 
 SWAP protocol is performed in conjunction with another request-reply protocol to account for its usage.
-It SHOULD be done for [13/WAKU2-STORE](../../standards/core/13/store.md)
+It SHOULD be done for [13/WAKU2-STORE](../../core/13/store.md)
 and it MAY be done for other request/reply protocols.
 
 A client SHOULD log accounting state per peer
@@ -173,7 +173,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 1. [Prisoner's Dilemma](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma)
 2. [Axelrod - Evolution of Cooperation (book)](https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation)
 3. [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth)
-4. [13/WAKU2-STORE](../../standards/core/13/store.md)
+4. [13/WAKU2-STORE](../../core/13/store.md)
 
 <!--
 

waku/deprecated/README.md

@@ -1,4 +1,4 @@
-## Deprecated RFCs 
+# Deprecated RFCs 
 
 Deprecated specifications are no longer used in Waku products.
 This subdirectory is for achrive purpose and 

waku/informational/23/topics.md

@@ -89,7 +89,7 @@ This is used for content based filtering.
 See [14/WAKU2-MESSAGE spec](../../standards/core/14/message.md) for where this is specified.
 Note that this doesn't impact routing of messages between relaying nodes,
 but it does impact how request/reply protocols such as 
-[12/WAKU2-FILTER](../../standards/core/14/filter.md) and [13/WAKU2-STORE](../../standards/core/13/store.md) are used.
+[12/WAKU2-FILTER](../../standards/core/12/filter.md) and [13/WAKU2-STORE](../../standards/core/13/store.md) are used.
 
 This is especially useful for nodes that have limited bandwidth,
 and only want to pull down messages that match this given content topic.
@@ -163,7 +163,7 @@ Copyright and related rights waived via
 * [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)
 * [Ethereum 2 P2P spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#topics-and-messages)
 * [14/WAKU2-MESSAGE](../../standards/core/14/message.md)
-* [12/WAKU2-FILTER](../../standards/core/14/filter.md)
+* [12/WAKU2-FILTER](../../standards/core/12/filter.md)
 * [13/WAKU2-STORE](../../standards/core/13/store.md)
 * [6/WAKU1](../../deprecated/5/waku0.md)
 * [15/WAKU-BRIDGE](../../standards/core/15/bridge.md)

waku/informational/27/peers.md

@@ -74,7 +74,7 @@ This requires keeping track of the [last time each peer was disconnected](#track
 
 A Waku v2 client MAY choose to implement a keep-alive mechanism to certain peers.
 If a client chooses to implement keep-alive on a connection,
-it SHOULD do so by sending periodic [libp2p pings](https://docs.libp2p.io/concepts/protocols/#ping) as per `10/WAKU2` [client recommendations](../../standards/core/10/WAKU2.md/#recommendations-for-clients).
+it SHOULD do so by sending periodic [libp2p pings](https://docs.libp2p.io/concepts/protocols/#ping) as per `10/WAKU2` [client recommendations](../../standards/core/10/waku2.md/#recommendations-for-clients).
 The recommended period between pings SHOULD be _at most_ 50% of the shortest idle connection timeout for the specific client and transport.
 For example, idle TCP connections often times out after 10 to 15 minutes.
 
@@ -96,4 +96,4 @@ Copyright and related rights waived via
 - [`18/WAKU2-SWAP`](../../standards/application/18/swap.md)
 - [backing off period](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#prune-backoff-and-peer-exchange)
 - [libp2p pings](https://docs.libp2p.io/concepts/protocols/#ping)
-- [`10/WAKU2` client recommendations](https://rfc.vac.dev/spec/10/#recommendations-for-clients)
+- [`10/WAKU2` client recommendations](../../standards/core/10/waku2.md/#recommendations-for-clients)

waku/standards/application/20/toy-eth-pm.md

@@ -46,10 +46,10 @@ The proposed protocol MUST adhere to the following design requirements:
 2. Bob is willing to participate to Eth-PM, and publishes `B'`,
 3. Bob's ownership of `B'` MUST be verifiable,
 4. Alice wants to send message `M` to Bob,
-5. Bob SHOULD be able to get `M` using [10/WAKU2 spec](../../standards/core/10/waku2.md),
+5. Bob SHOULD be able to get `M` using [10/WAKU2 spec](../../core/10/waku2.md),
 6. Participants only have access to their Ethereum Wallet via the Web3 API,
 7. Carole MUST NOT be able to read `M`'s content even if she is storing it or relaying it,
-8. [Waku Message Version 1](../../standards/application/26/payload.md) Asymmetric Encryption is used for encryption purposes.
+8. [Waku Message Version 1](../26/payload.md) Asymmetric Encryption is used for encryption purposes.
 
 ## Limitations
 
@@ -155,7 +155,7 @@ it is not enough in itself to deduce Bob's Public Key.
 This is why the protocol dictates that Bob MUST send his Public Key first,
 and Alice MUST receive it before she can send him a message.
 
-Moreover, nim-waku, the reference implementation of [13/WAKU2-STORE](../../standards/core/13/store.md)),
+Moreover, nim-waku, the reference implementation of [13/WAKU2-STORE](../../core/13/store.md),
 stores messages for a maximum period of 30 days.
 This means that Bob would need to broadcast his public key at least every 30 days to be reachable.
 
@@ -202,10 +202,10 @@ Alice MAY monitor the Waku v2 to collect Ethereum Address and Encryption Public
 Alice SHOULD verify that the `signature`s of `PublicKeyMessage`s she receives are valid as per EIP-712.
 She SHOULD drop any message without a signature or with an invalid signature.
 
-Using Bob's Encryption Public Key, retrieved via [10/WAKU2](../../standards/core/10/waku2.md), Alice MAY now send an encrypted message to Bob.
+Using Bob's Encryption Public Key, retrieved via [10/WAKU2 spec](../../core/10/waku2.md), Alice MAY now send an encrypted message to Bob.
 
 If she wishes to do so, Alice MUST encrypt her message `M` using Bob's Encryption Public Key `B'`,
-as per [26/WAKU-PAYLOAD Asymmetric Encryption specs](../../standards/application/26/payload.md/#asymmetric).
+as per [26/WAKU-PAYLOAD Asymmetric Encryption specs](../26/payload.md/#asymmetric).
 
 Alice SHOULD now publish this message on the Private Message content topic.
 
@@ -214,12 +214,12 @@ Alice SHOULD now publish this message on the Private Message content topic.
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
 
 ## References
-- [10/WAKU2 spec](../../standards/core/10/waku2.md)
-- [Waku Message Version 1](../../standards/application/26/payload.md)
+- [10/WAKU2 spec](../../core/10/waku2.md)
+- [Waku Message Version 1](../26/payload.md)
 - [X3DH](https://www.signal.org/docs/specifications/x3dh/)
 - [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
 - [Status secure transport spec](https://specs.status.im/spec/5)
 - [EIP-712](https://eips.ethereum.org/EIPS/eip-712)
-- [13/WAKU2-STORE](../../standards/core/13/store.md))
+- [13/WAKU2-STORE](../../core/13/store.md)
 - [The Graph](https://thegraph.com/)
   

waku/standards/application/21/fault-tolerant-store.md

@@ -7,14 +7,14 @@ editor: Sanaz Taheri <sanaz@status.im>
 contributors:
 ---
 
- The reliability of [13/WAKU2-STORE](../../standards/core/13/store.md) protocol heavily relies on the fact that full nodes i.e., those who persist messages have high availability and uptime and do not miss any messages. 
+ The reliability of [13/WAKU2-STORE](../../core/13/store.md) protocol heavily relies on the fact that full nodes i.e., those who persist messages have high availability and uptime and do not miss any messages. 
  If a node goes offline, then it will risk missing all the messages transmitted in the network during that time. 
  In this specification, we provide a method that makes the store protocol resilient in presence of faulty nodes. 
  Relying on this method,  nodes that have been offline for a time window will be able to fix the gap in their message history when getting back online. 
  Moreover, nodes with lower availability and uptime can leverage this method to reliably provide the store protocol services as a full node.
 
 ## Method description 
- As the first step towards making the [13/WAKU2-STORE](../../standards/core/13/store.md) protocol fault-tolerant, we introduce a new type of time-based query through which nodes fetch message history from each other based on their desired time window. 
+ As the first step towards making the [13/WAKU2-STORE](../../core/13/store.md) protocol fault-tolerant, we introduce a new type of time-based query through which nodes fetch message history from each other based on their desired time window. 
  This method operates based on the assumption that the querying node knows some other nodes in the store protocol which have been online for that targeted time window.  
 
 ## Security Consideration
@@ -23,7 +23,7 @@ The main security consideration to take into account while using this method is
 This will gradually result in the extraction of the node's activity pattern which can lead to inference attacks. 
 
 ## Wire Specification
-We extend the [HistoryQuery](../../standards/core/13/store.md/#payloads) protobuf message with two fields of `start_time` and `end_time` to signify the time range to be queried. 
+We extend the [HistoryQuery](../../core/13/store.md/#payloads) protobuf message with two fields of `start_time` and `end_time` to signify the time range to be queried. 
 
 ### Payloads
 
@@ -46,10 +46,10 @@ message HistoryQuery {
 RPC call to query historical messages.
 - `start_time`: this field MAY be filled out to signify the starting point of the queried time window. 
   This field holds the Unix epoch time in nanoseconds.  
-  The `messages` field of the corresponding [`HistoryResponse`](../../standards/core/13/store.md/#HistoryResponse) MUST contain historical waku messages whose [`timestamp`](../../standards/core/14/message.md/#Payloads) is larger than or equal to the `start_time`.
+  The `messages` field of the corresponding [`HistoryResponse`](../../core/13/store.md/#HistoryResponse) MUST contain historical waku messages whose [`timestamp`](../../core/14/message.md/#Payloads) is larger than or equal to the `start_time`.
 - `end_time` this field MAY be filled out to signify the ending point of the queried time window. 
   This field holds the Unix epoch time in nanoseconds.
-  The `messages` field of the corresponding [`HistoryResponse`](../../standards/core/13/store.md/#HistoryResponse) MUST contain historical waku messages whose [`timestamp`](../../standards/core/14/message.md/#Payloads) is less than or equal to the `end_time`.
+  The `messages` field of the corresponding [`HistoryResponse`](../../core/13/store.md/#HistoryResponse) MUST contain historical waku messages whose [`timestamp`](../../core/14/message.md/#Payloads) is less than or equal to the `end_time`.
 
   A time-based query is considered valid if its `end_time` is larger than or equal to the `start_time`. 
   Queries that do not adhere to this condition will not get through e.g. an open-end time query in which the `start_time` is given but no  `end_time` is supplied is not valid. 
@@ -61,7 +61,7 @@ In order to account for nodes asynchrony, and assuming that nodes may be out of
 That is if the original window is [`l`,`r`] then the history query SHOULD be made for `[start_time: l - 20s, end_time: r + 20s]`.
 
 Note that `HistoryQuery` preserves `AND` operation among the queried attributes. 
-As such,  The `messages` field of the corresponding [`HistoryResponse`](../../standards/core/13/store.md/#HistoryResponse) MUST contain historical waku messages that satisfy the indicated  `pubsubtopic` AND `contentFilters` AND the time range [`start_time`, `end_time`]. 
+As such,  The `messages` field of the corresponding [`HistoryResponse`](../../core/13/store.md/#HistoryResponse) MUST contain historical waku messages that satisfy the indicated  `pubsubtopic` AND `contentFilters` AND the time range [`start_time`, `end_time`]. 
 
 ## Copyright
 
@@ -70,5 +70,5 @@ Copyright and related rights waived via
 
 ## References
 
-- [13/WAKU2-STORE](../../standards/core/13/store.md)
+- [13/WAKU2-STORE](../../core/13/store.md)
 - [`timestamp`](../../standards/core/14/message.md/#Payloads)

waku/standards/application/26/payload.md

@@ -8,9 +8,9 @@ contributors:
 ---
 
 This specification describes how Waku provides confidentiality, authenticity, and integrity, as well as some form of unlinkability.
-Specifically, it describes how encryption, decryption and signing works in [6/WAKU1](../../standards/core/6/waku1.md) and in [10/WAKU2 spec](../../standards/core/10/waku2.md) with [14/WAKU-MESSAGE version 1](../../standards/core/14/message.md/#version1).
+Specifically, it describes how encryption, decryption and signing works in [6/WAKU1](../../legacy/6/waku1.md) and in [10/WAKU2 spec](../../core/10/waku2.md) with [14/WAKU-MESSAGE version 1](../../core/14/message.md/#version1).
 
-This specification effectively replaces [7/WAKU-DATA](../../standards/application/7/DATA.md) as well as [6/WAKU1 Payload encryption](../../standards/core/6/waku1.md/#payload-encryption) but written in a way that is agnostic and self-contained for Waku v1 and Waku v2.
+This specification effectively replaces [7/WAKU-DATA](../../legacy/7/data.md) as well as [6/WAKU1 Payload encryption](../../legacy/6/waku1.md/#payload-encryption) but written in a way that is agnostic and self-contained for Waku v1 and Waku v2.
 
 Large sections of the specification originate from [EIP-627: Whisper spec](https://eips.ethereum.org/EIPS/eip-627) as well from [RLPx Transport Protocol spec (ECIES encryption)](https://github.com/ethereum/devp2p/blob/master/rlpx.md#ecies-encryption) with some modifications.
 
@@ -42,9 +42,9 @@ ECIES is using the following cryptosystem:
 
 ## Specification
 
-For 6/WAKU1, the `data` field is used in the `waku envelope`, and the field MAY contain the encrypted payload.
+For [6/WAKU1](../../legacy/6/waku1.md), the `data` field is used in the `waku envelope`, and the field MAY contain the encrypted payload.
 
-For 10/WAKU2, the `payload` field is used in `WakuMessage` and MAY contain the encrypted payload.
+For [10/WAKU2 spec](../../core/10/waku2.md), the `payload` field is used in `WakuMessage` and MAY contain the encrypted payload.
 
 The fields that are concatenated and encrypted as part of the `data` (Waku v1) / `payload` (Waku v2) field are:
  - flags
@@ -142,10 +142,10 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 ## References
 
-1. [6/WAKU1](../../standards/core/6/waku1.md)
-2. [10/WAKU2 spec](../../standards/core/10/waku2.md)
-3. [14/WAKU-MESSAGE version 1](../../standards/core/14/message.md/#version1)
-4. [7/WAKU-DATA](../../standards/application/7/DATA.md)
+1. [6/WAKU1](../../legacy/6/waku1.md)
+2. [10/WAKU2 spec](../../core/10/waku2.md)
+3. [14/WAKU-MESSAGE version 1](../../core/14/message.md/#version1)
+4. [7/WAKU-DATA](../../legacy/7/data.md)
 5. [EIP-627: Whisper spec](https://eips.ethereum.org/EIPS/eip-627)
 6. [RLPx Transport Protocol spec (ECIES encryption)](https://github.com/ethereum/devp2p/blob/master/rlpx.md#ecies-encryption)
 7. [Status 5/SECURE-TRANSPORT](https://specs.status.im/spec/5)

waku/standards/application/53/x3dh.md

@@ -54,7 +54,7 @@ Types used in this specification are defined using the [Protobuf](https://develo
 
 End-to-end encryption (E2EE) takes place between two clients. 
 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](../../standards/core/10/waku2.md) subsequently encrypts the message payload, using symmetric key encryption. 
+[The Waku v2 protocol](../../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/)) is used to allow the protocol to operate in an asynchronous environment.
 It is not necessary for two parties to be online at the same time to initiate an encrypted conversation.
 
@@ -230,7 +230,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](../../standards/core/10/waku2.md).
+2. Inherits the security considerations of the [Waku v2 protocol](../../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. In this case, the server is trusted.
 
@@ -249,7 +249,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](../../standards/core/10/waku2.md)
+- [The Waku v2 protocol](../../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/application/54/x3dh-sessions.md

@@ -19,7 +19,7 @@ contributors:
 This document specifies how to manage sessions based on an X3DH key exchange.
 This includes how to establish new sessions, how to re-establish them, how to maintain them, and how to close them.
 
-[53/WAKU2-X3DH](../../standards/application/53/X3DH.md) specifies the Waku `X3DH` protocol for end-to-end encryption. 
+[53/WAKU2-X3DH](../53/x3dh.md) specifies the Waku `X3DH` protocol for end-to-end encryption. 
 Once two peers complete an X3DH handshake, they SHOULD establish an X3DH session.
 
 ## Session Establishment
@@ -146,7 +146,7 @@ In this case an empty message containing bundle information MUST be sent back, w
 
 ## Security Considerations
 
-1. Inherits all security considerations from [53/WAKU2-X3DH](../../standards/application/53/X3DH.md).
+1. Inherits all security considerations from [53/WAKU2-X3DH](../53/x3dh.md).
 
 ### Recommendations
 
@@ -159,6 +159,6 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 ## References
 
-1. [53/WAKU2-X3DH](../../standards/application/53/X3DH.md)
+1. [53/WAKU2-X3DH](../53/x3dh.md)
 2. [Signal's Sesame Algorithm](https://signal.org/docs/specifications/sesame/)
 

waku/standards/core/10/waku2.md

@@ -3,12 +3,13 @@ slug: 10
 title: 10/WAKU2
 name: Waku v2
 status: draft
-editor: Oskar Thorén <oskarth@titanproxy.com>
+editor: Hanno Cornelius <hanno@status.im> 
 contributors:
   - Sanaz Taheri <sanaz@status.im>
   - Hanno Cornelius <hanno@status.im>
   - Reeshav Khan <reeshav@status.im>
   - Daniel Kaiser <danielkaiser@status.im>
+  - Oskar Thorén <oskarth@titanproxy.com>
 ---
 
 ## Abstract
@@ -23,7 +24,7 @@ These capabilities are things such as:
 
 This makes Waku ideal for running a p2p protocol on mobile and in similarly restricted environments.
 
-Historically, it has its roots in [6/WAKU1](../6/waku1.md),
+Historically, it has its roots in [6/WAKU1](../../legacy/6/waku1.md),
 which stems from [Whisper](https://eips.ethereum.org/EIPS/eip-627), originally part of the Ethereum stack.
 However, Waku v2 acts more as a thin wrapper for PubSub and has a different API.
 It is implemented in an iterative manner where initial focus is on porting essential functionality to libp2p.
@@ -211,7 +212,7 @@ This is used to fetch historical messages for mostly offline devices.
 See [13/WAKU2-STORE spec](../13/store.md) spec for more details.
 
 There is also an experimental fault-tolerant addition to the store protocol that relaxes the high availability requirement.
-See [21/WAKU2-FT-STORE](../../application/21/ft-store.md)
+See [21/WAKU2-FT-STORE](../../application/21/fault-tolerant-store.md)
 
 #### Content filtering
 
@@ -244,9 +245,9 @@ The PubSub topics `pubtopic1` and `pubtopic2` is used for routing and indicates
 Ditto for [13/WAKU2-STORE](../13/store.md) where it indicates that these messages are persisted on that node.
 
 1. Node A creates a WakuMessage `msg1` with a ContentTopic `contentTopic1`.
-See [14/WAKU2-MESSAGE](../core/14/message.md) for more details.
-If WakuMessage version is set to 1, we use the [6/WAKU1](../6/waku1.md) compatible `data` field with encryption.
-See [7/WAKU-DATA](../../application/7/data.md) for more details.
+See [14/WAKU2-MESSAGE](../14/message.md) for more details.
+If WakuMessage version is set to 1, we use the [6/WAKU1](../../legacy/6/waku1.md) compatible `data` field with encryption.
+See [7/WAKU-DATA](../../legacy/7/data.md) for more details.
 
 2. Node F requests to get messages filtered by PubSub topic `pubtopic1` and ContentTopic `contentTopic1`.
 Node D subscribes F to this filter and will in the future forward messages that match that filter.
@@ -362,10 +363,10 @@ This includes Waku v1 specs, as they are used for bridging between the two netwo
 
 | Spec | nim-waku (Nim) | go-waku (Go) | js-waku (Node JS) | js-waku (Browser JS) |
 | ---- | -------------- | ------------ | ----------------- | -------------------- |
-|[6/WAKU1](../6/waku1.md)|✔|||
-|[7/WAKU-DATA](../7/data.md)|✔|✔||
-|[8/WAKU-MAIL](../../application/8/mail.md)|✔|||
-|[9/WAKU-RPC](../9/waku2-rpc.md)|✔|||
+|[6/WAKU1](../../legacy/6/waku1.md)|✔|||
+|[7/WAKU-DATA](../../legacy/7/data.md)|✔|✔||
+|[8/WAKU-MAIL](../../legacy/8/mail.md)|✔|||
+|[9/WAKU-RPC](../../legacy/9/rpc.md)|✔|||
 |[10/WAKU2](../10/waku2.md)|✔|🚧|🚧|🚧|
 |[11/WAKU2-RELAY](../11/relay.md)|✔|✔|✔|✔|
 |[12/WAKU2-FILTER](../12/filter.md)|✔|✔||
@@ -393,7 +394,7 @@ To implement a minimal Waku v2 client, we recommend implementing the following s
 
 To get compatibility with Waku v1:
 
-- [7/WAKU-DATA](../7/data.md)
+- [7/WAKU-DATA](../../legacy/7/data.md)
 - [14/WAKU2-MESSAGE](../14/message.md) - version 1 (encrypted with `7/WAKU-DATA`)
 
 For an interoperable keep-alive mechanism:
@@ -429,7 +430,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 1. [libp2p specs](https://github.com/libp2p/specs)
 
-2. [6/WAKU1](../6/waku1.md)
+2. [6/WAKU1](../../legacy/6/waku1.md)
 
 3. [Whisper spec (EIP627)](https://eips.ethereum.org/EIPS/eip-627)
 
@@ -473,7 +474,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 23. [19/WAKU2-LIGHTPUSH](../19/lightpush.md)
 
-24. [7/WAKU-DATA](../../application/7/data.md)
+24. [7/WAKU-DATA](../../legacy/7/data.md)
 
 25. [15/WAKU-BRIDGE](../15/bridge.md)
 
@@ -487,9 +488,9 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 30. [js-waku (NodeJS and Browser)](https://github.com/status-im/js-waku/)
 
-31. [8/WAKU-MAIL](../../application/8/mail.md)
+31. [8/WAKU-MAIL](../../legacy/8/mail.md)
 
-32. [9/WAKU-RPC](../9/waku2-rpc.md)
+32. [9/WAKU-RPC](../../legacy/9/rpc.md)
 
 33. [16/WAKU2-RPC](../16/rpc.md)
 

waku/standards/core/13/store.md

@@ -4,11 +4,13 @@ title: 13/WAKU2-STORE
 name: Waku v2 Store
 status: draft
 tags: waku-core
-editor: Sanaz Taheri <sanaz@status.im>
+editor: Simon-Pierre Vivier <simvivier@status.im>
 contributors:
   - Dean Eigenmann <dean@status.im>
   - Oskar Thorén <oskarth@titanproxy.com>
   - Aaryamann Challani <aaryamann@status.im>
+  - Sanaz Taheri <sanaz@status.im>
+  - Hanno Cornelius <hanno@status.im>
 ---
 
 ## Abstract

waku/standards/core/14/message.md

@@ -5,12 +5,13 @@ name: Waku v2 Message
 status: draft
 category: Standards Track
 tags: waku/core-protocol
-editor: Oskar Thorén <oskarth@titanproxy.com>
+editor: Hanno Cornelius <hanno@status.im>
 contributors:
   - Sanaz Taheri <sanaz@status.im>
   - Aaryamann Challani <aaryamann@status.im>
   - Lorenzo Delgado <lorenzo@status.im>
   - Abhimanyu Rawat <abhi@status.im>
+  - Oskar Thorén <oskarth@titanproxy.com>
 ---
 
 ## Abstract
@@ -28,7 +29,7 @@ When sending messages over Waku, there are multiple requirements:
 
 - One may have a separate encryption layer as part of the application.
 - One may want to provide efficient routing for resource-restricted devices.
-- One may want to provide compatibility with [Waku v1 envelopes](../6/waku1.md).
+- One may want to provide compatibility with [Waku v1 envelopes](../../legacy/6/waku1.md).
 - One may want encrypted payloads by default.
 - One may want to provide unlinkability to get metadata protection.
 
@@ -195,7 +196,7 @@ Therefore, because message timestamps aren’t independently verified, this attr
 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](../6/waku1.md/#clock-vs-timestamp-and-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).
 
 ### Reliability of the `ephemeral` attribute
 
@@ -210,8 +211,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 ## References
 
-- [6/WAKU1](/spec/6/)
+- [6/WAKU1](../../legacy/6/waku1.md)
 - [Google Protocol buffers v3](https://developers.google.com/protocol-buffers/)
 - [26/WAKU-PAYLOAD](../../application/26/payload.md)
 - [35/WAKU2-NOISE]([/spec/35](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md))
-- [6/PAYLOADS](https://specs.status.im/spec/6#clock-vs-timestamp-and-message-ordering)
+- [62/STATUS-PAYLOADS](../../../../status/62/payloads.md/#clock-vs-timestamp-and-message-ordering)

waku/standards/core/17/rln-relay.md

@@ -4,10 +4,12 @@ title: 17/WAKU2-RLN-RELAY
 name: Waku v2 RLN Relay
 status: draft
 tags: waku-core
-editor: Sanaz Taheri <sanaz@status.im>
+editor: Alvaro Revuelta <alvaro@status.im>
 contributors:
   - Oskar Thorén <oskarth@titanproxy.com>
   - Aaryamann Challani <aaryamann@status.im>
+  - Sanaz Taheri <sanaz@status.im>
+  - Hanno Cornelius <hanno@status.im>
 ---
 
 The `17/WAKU2-RLN-RELAY` protocol is an extension of `11/WAKU2-RELAY` which additionally provides spam protection using [Rate Limiting Nullifiers (RLN)](../../../../vac/32/rln-v1.md). 
@@ -19,16 +21,16 @@ Spammers are also financially punished and removed from the system.
 
 <!-- **Protocol identifier***: `/vac/waku/waku-rln-relay/2.0.0-alpha1` -->
 
-# Motivation
+## Motivation
 
 In open and anonymous p2p messaging networks, one big problem is spam resistance. 
 Existing solutions, such as Whisper’s proof of work are computationally expensive hence not suitable for resource-limited nodes. 
 Other reputation-based approaches might not be desirable, due to issues around arbitrary exclusion and privacy.
 
-We augment the [`11/WAKU2-RELAY`](/spec/11) protocol with a novel construct of [RLN](/spec/32) to enable an efficient economic spam prevention mechanism that can be run in resource-constrained environments.
+We augment the [`11/WAKU2-RELAY`](../11/relay.md) protocol with a novel construct of [RLN](../../../../vac/32/rln-v1.md) to enable an efficient economic spam prevention mechanism that can be run in resource-constrained environments.
 
 
-# Flow
+## Flow
 
 
 The messaging rate is defined by the `period` which indicates how many messages can be sent in a given period.
@@ -40,12 +42,12 @@ The higher-level layers adopting `17/WAKU2-RLN-RELAY` MAY choose to enforce the
 
 
 
-## Setup and Registration
-Peers subscribed to a specific `pubsubTopic` form a [RLN group](/spec/32).
+### Setup and Registration
+Peers subscribed to a specific `pubsubTopic` form a [RLN group](../../../../vac/32/rln-v1.md).
 <!-- link to the RLN group definition in the RLN RFC -->
 Peers MUST be registered to the RLN group to be able to publish messages.
 Registration is moderated through a smart contract deployed on the Ethereum blockchain. 
-Each peer has an [RLN key pair](/spec/32) denoted by `sk`  and `pk`.
+Each peer has an [RLN key pair](../../../../vac/32/rln-v1.md) denoted by `sk`  and `pk`.
 The  secret key `sk` is secret data and MUST be persisted securely by the peer.
 The state of the membership contract contains the list of registered members' public identity keys i.e., `pk`s. 
 For the registration, a peer creates a transaction that invokes the registration function of the contract via which registers its `pk` in the group. 
@@ -60,9 +62,9 @@ An overview of registration is illustrated in Figure 1.
 ![Figure 1: Registration.](./images/rln-relay.png)
 
 
-## Publishing
+### Publishing
 
-To publish at a given `epoch`, the publishing peer proceeds based on the regular [`11/WAKU2-RELAY`](/spec/11) protocol.  
+To publish at a given `epoch`, the publishing peer proceeds based on the regular [`11/WAKU2-RELAY`](../11/relay.md) protocol.  
 However, to protect against spamming, each `WakuMessage` (which is wrapped inside the `data` field of a PubSub message) MUST carry a [`RateLimitProof`](##RateLimitProof) with the following fields. 
 Section [Payload](#payloads) covers the details about the type and encoding of these fields.
 
@@ -74,7 +76,7 @@ The `nullifier` is an internal nullifier acting as a fingerprint that allows spe
 The `nullifier` is a deterministic value derived from `sk` and `epoch` therefore any two messages issued by the same peer (i.e., using the same `sk`) for the same `epoch` are guaranteed to have identical `nullifier`s.
 
 The `share_x` and `share_y` can be seen as partial disclosure of peer's `sk` for the intended `epoch`.
-They are derived deterministically from peer's `sk` and current `epoch` using [Shamir secret sharing scheme](/spec/32). 
+They are derived deterministically from peer's `sk` and current `epoch` using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md). 
 If a peer discloses more than one such pair (`share_x`, `share_y`) for the same `epoch`, it would allow full disclosure of its  `sk` and hence get access to its staked fund in the membership contract.
 
 
@@ -82,13 +84,13 @@ The `proof` field is a zero-knowledge proof signifying that:
 1. The message owner is the current member of the group i.e., her/his identity commitment key `pk` is part of the membership group Merkle tree with the root `merkle_root`.
 2. `share_x` and `share_y`  are correctly computed.
 3. The `nullifier` is constructed correctly.
-For more details about the proof generation check [RLN](/spec/32)
+For more details about the proof generation check [RLN](../../../../vac/32/rln-v1.md)
 The proof generation relies on the knowledge of two pieces of private information i.e., `sk` and `authPath`.
 The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. <!-- TODO refer to RLN RFC for authPath def -->
 The proof generation also requires a set of public inputs which are: the Merkle tree root `merkle_root`, the current `epoch`, and the message for which the proof is going to be generated. 
 In `17/WAKU2-RLN-RELAY`, the message is the concatenation of `WakuMessage`'s  `payload` filed and its `contentTopic` i.e., `payload||contentTopic`. 
 
-## Group Synchronization
+### Group Synchronization
 
 Proof generation relies on the knowledge of Merkle tree root `merkle_root` and `authPath` which both require access to the membership Merkle tree. 
 Getting access to the Merkle tree can be done in various ways. 
@@ -104,17 +106,17 @@ where the delay is due to mining the slashing transaction.
 For the group synchronization, one important security consideration is that peers MUST make sure they always use the most recent Merkle tree root in their proof generation.
 The reason is that using an old root can allow inference about the index of the user's `pk` in the membership tree hence compromising user privacy and breaking message unlinkability.
 
-## Routing
+### Routing
 
-Upon the receipt of a PubSub message via [`11/WAKU2-RELAY`](/spec/11) protocol, the routing peer parses the `data` field as a `WakuMessage` and gets access to the `RateLimitProof` field.  
+Upon the receipt of a PubSub message via [`11/WAKU2-RELAY`](../11/relay.md) protocol, the routing peer parses the `data` field as a `WakuMessage` and gets access to the `RateLimitProof` field.  
 The peer then validates the `RateLimitProof`  as explained next.
 
-### Epoch Validation
+#### Epoch Validation
 If the `epoch` attached to the message is more than `max_epoch_gap` apart from the routing peer's current `epoch` then the message is discarded and considered invalid.
 This is to prevent a newly registered peer from spamming the system by messaging for all the past epochs. 
 `max_epoch_gap` is a system parameter for which we provide some recommendations in section [Recommended System Parameters](#recommended-system-parameters).
 
-### Merkle Root Validation
+#### Merkle Root Validation
 The routing peers MUST check whether the provided Merkle root in the `RateLimitProof` is valid.
 It can do so by maintaining a local set of valid Merkle roots, which consist of `acceptable_root_window_size` past roots.
 These roots refer to the final state of the Merkle tree after a whole block consisting of group changes is processed.
@@ -128,12 +130,12 @@ This also allows peers which are not well connected to the network to be able to
 This network delay is related to the nature of asynchronous network conditions, which means that peers see membership changes asynchronously, and therefore may have differing local Merkle trees.
 See [Recommended System Parameters](#recommended-system-parameters) on choosing an appropriate `acceptable_root_window_size`. 
 
-### Proof Verification
+#### Proof Verification
 The routing peers MUST check whether the zero-knowledge proof `proof` is valid.
-It does so by running the zk verification algorithm as explained in [RLN](/spec/32). 
+It does so by running the zk verification algorithm as explained in [RLN](../../../../vac/32/rln-v1.md). 
 If `proof` is invalid then the message is discarded. 
 
-### Spam detection
+#### Spam detection
 To enable local spam detection and slashing, routing peers MUST record the `nullifier`, `share_x`, and `share_y` of incoming messages which are not discarded i.e., not found spam or with invalid proof or epoch.
 To spot spam messages, the peer checks whether a message with an identical `nullifier` has already been relayed. 
 1. If such a message exists and its `share_x` and `share_y` components are different from the incoming message, then slashing takes place.
@@ -151,10 +153,10 @@ An overview of the routing procedure and slashing is provided in Figure 2.
 
 -------
 
-# Payloads
+## Payloads
 
 Payloads are protobuf messages implemented using [protocol buffers v3](https://developers.google.com/protocol-buffers/).
-Nodes MAY extend the  [14/WAKU2-MESSAGE](/spec/14) with a `rate_limit_proof` field to indicate that their message is not spam.
+Nodes MAY extend the  [14/WAKU2-MESSAGE](../14/message.md) with a `rate_limit_proof` field to indicate that their message is not spam.
 
 ```diff 
 
@@ -179,22 +181,22 @@ message WakuMessage {
 }
 
 ```
-## WakuMessage
+### WakuMessage
 
 `rate_limit_proof` holds the information required to prove that the message owner has not exceeded the message rate limit.
  
-## RateLimitProof
+### RateLimitProof
 Below is the description of the fields of `RateLimitProof` and their types.
 
 | Parameter | Type | Description | 
 | ----: | ----------- | ----------- |
 | `proof` | array of 256 bytes | the zkSNARK proof as explained in the [Publishing process](##Publishing) |
 | `merkle_root` | array of 32 bytes in little-endian order | the root of membership group Merkle tree at the time of publishing the message |
-| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](/spec/32) | <!-- todo specify the poseidon hash setting -->
-| `nullifier`  | array of 32 bytes | internal nullifier derived from `epoch` and peer's `sk` as explained in [RLN construct](/spec/32)|
+| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md) | <!-- todo specify the poseidon hash setting -->
+| `nullifier`  | array of 32 bytes | internal nullifier derived from `epoch` and peer's `sk` as explained in [RLN construct](../../../../vac/32/rln-v1.md)|
 
 
-# Recommended System Parameters
+## Recommended System Parameters
 The system parameters are summarized in the following table, and the recommended values for a subset of them are presented next.
 
 | Parameter | Description |
@@ -205,14 +207,14 @@ The system parameters are summarized in the following table, and the recommended
 | `max_epoch_gap` | the maximum allowed gap between the `epoch` of a routing peer and the incoming message |
 | `acceptable_root_window_size` | The maximum number of past Merkle roots to store |
 
-## Epoch Length
+### Epoch Length
 A sensible value for the `period` depends on the application for which the spam protection is going to be used.
 For example, while the `period` of `1` second i.e., messaging rate of `1` per second, might be acceptable for a chat application, might be too low for communication among Ethereum network validators.
 One should look at the desired throughput of the application to decide on a proper `period` value.
 In the proof of concept implementation of `17/WAKU2-RLN-RELAY` protocol which is available in [nim-waku](https://github.com/status-im/nim-waku), the `period` is set to `1` second.
 Nevertheless, this value is also subject to change depending on user experience.
 
-## Maximum Epoch Gap
+### Maximum Epoch Gap
 We discussed in the [Routing](#routing) section that the gap between the epoch observed by the routing peer and the one attached to the incoming message should not exceed a threshold denoted by  `max_epoch_gap` .
 The value of  `max_epoch_gap`  can be measured based on the following factors.
 - Network transmission delay `Network_Delay`: the maximum time that it takes for a message to be fully disseminated in the GossipSub network.
@@ -235,11 +237,11 @@ The `acceptable_root_window_size` should indicate how many blocks may have been
 This formula represents a lower bound of the number of acceptable roots. 
 
 
-# Copyright
+## Copyright
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
 
-# References
+## References
 
 1. [RLN documentation](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view)
 2. [Public inputs to the RLN circuit](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Public-Inputs)

waku/standards/core/19/lightpush.md

@@ -3,9 +3,10 @@ slug: 19
 title: 19/WAKU2-LIGHTPUSH
 name: Waku v2 Light Push
 status: draft
-editor: Oskar Thorén <oskarth@titanproxy.com>
+editor: Hanno Cornelius <hanno@status.im> 
 contributors: 
   - Daniel Kaiser <danielkaiser@status.im>
+  - Oskar Thorén <oskarth@titanproxy.com>
 ---
 
 **Protocol identifier**: `/vac/waku/lightpush/2.0.0-beta1`
@@ -45,13 +46,13 @@ message PushRPC {
 
 Nodes that respond to `PushRequests` MUST either
 relay the encapsulated message via [11/WAKU2-RELAY](../11/relay.md) protocol on the specified `pubsub_topic`,
-or forward the `PushRequest` via 19/LIGHTPUSH on a [44/WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) stem.
+or forward the `PushRequest` via 19/LIGHTPUSH on a [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) stem.
 If they are unable to do so for some reason, they SHOULD return an error code in `PushResponse`.
 
 ## Security Considerations
 
 Since this can introduce an amplification factor, it is RECOMMENDED for the node relaying to the rest of the network to take extra precautions.
-This can be done by rate limiting via [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17/).
+This can be done by rate limiting via [17/WAKU2-RLN-RELAY](../17/rln-relay.md).
 
 Note that the above is currently not fully implemented.
 
@@ -62,5 +63,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References
 
 * [11/WAKU2-RELAY](../11/relay.md)
-* [44/WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md)
+* [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md)
 * [17/WAKU2-RLN-RELAY](../17/rln-relay.md)

waku/standards/core/33/discv5.md

@@ -52,7 +52,7 @@ This also increases decentralization.
 
 `33/WAKU2-DISCV5` spans a discovery network isolated from the Ethereum Discovery v5 network.
 
-Another simple solution would be taking part in the Ethereum Discovery network, and filtering Waku nodes based on whether they support [31/WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md).
+Another simple solution would be taking part in the Ethereum Discovery network, and filtering Waku nodes based on whether they support [WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md).
 This solution is more resilient towards eclipse attacks.
 However, this discovery method is very inefficient for small percentages of Waku nodes (see [estimation](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121/8)).
 It boils down to random walk discovery and does not offer a O(log(n)) hop bound.
@@ -157,7 +157,7 @@ Properly protecting against eclipse attacks is challenging and raises research q
 
 1. [10/WAKU2](../10/waku2.md)
 1. [11/WAKU2-RELAY](../11/relay.md)
-1. [`31/WAKU2-ENR`](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md)
+1. [`WAKU2-ENR`](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md)
 1. [Node Discovery Protocol v5 (`discv5`)](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) 
 1. [`discv5` semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md).
 1. [`discv5` wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) 

waku/standards/core/66/metadata.md

@@ -0,0 +1,51 @@
+---
+slug: 66
+title: 66/WAKU2-METADATA
+name: Waku Metadata Protocol
+status: draft
+editor: Alvaro Revuelta <alrevuelta@status.im>
+contributors:
+---
+
+## Abstract
+This specification describes the metadata that can be associated with a [10/WAKU2](../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 node that makes the request, includes its metadata so that the receiver is aware of it, 
+without requiring an extra interaction. 
+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.
+
+***Protocol Identifier***
+
+    /vac/waku/metadata/1.0.0
+
+### Request
+
+```proto
+message WakuMetadataRequest {
+  optional uint32 cluster_id = 1;
+  repeated uint32 shards = 2;
+}
+```
+
+### Response
+
+```proto
+message WakuMetadataResponse {
+  optional uint32 cluster_id = 1;
+  repeated uint32 shards = 2;
+}
+```
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+- [10/WAKU2](../10/waku2.md)

waku/standards/legacy/6/waku1.md

@@ -36,7 +36,7 @@ This protocol needs to advertise the `waku/1` [capability](https://ethereum.gitb
 
 ### Gossip based routing
 
-In Whisper, envelopes are gossiped between peers. Whisper is a form of rumor-mongering protocol that works by flooding to its connected peers based on some factors. Envelopes are eligible for retransmission until their TTL expires. A node SHOULD relay envelopes to all connected nodes if an envelope matches their PoW and bloom filter settings. If a node works in light mode, it MAY choose not to forward envelopes. A node MUST NOT send expired envelopes, unless the envelopes are sent as a [8/WAKU-MAIL](../../application/8/mail.md) response. A node SHOULD NOT send an envelope to a peer that it has already sent before.
+In Whisper, envelopes are gossiped between peers. Whisper is a form of rumor-mongering protocol that works by flooding to its connected peers based on some factors. Envelopes are eligible for retransmission until their TTL expires. A node SHOULD relay envelopes to all connected nodes if an envelope matches their PoW and bloom filter settings. If a node works in light mode, it MAY choose not to forward envelopes. A node MUST NOT send expired envelopes, unless the envelopes are sent as a [8/WAKU-MAIL](../8/mail.md) response. A node SHOULD NOT send an envelope to a peer that it has already sent before.
 
 ### Maximum Packet Size
 
@@ -343,7 +343,7 @@ The drawback of sending message confirmations is that it increases the noise in
 
 #### P2P Request
 
-This packet is used for sending Dapp-level peer-to-peer requests, e.g. Waku Mail Client requesting historic (expired) envelopes from the [Waku Mail Server](../../application/8/mail.md).
+This packet is used for sending Dapp-level peer-to-peer requests, e.g. Waku Mail Client requesting historic (expired) envelopes from the [Waku Mail Server](../8/mail.md).
 
 #### P2P Message
 
@@ -353,7 +353,7 @@ This packet is used for sending the peer-to-peer envelopes, which are not suppos
 
 This packet is used to indicate that all envelopes, requested earlier with a P2P Request packet (`0x7E`), have been sent via one or more P2P Message packets (`0x7F`).
 
-The content of the packet is explained in the [Waku Mail Server](../../application/8/mail.md) specification.
+The content of the packet is explained in the [Waku Mail Server](../8/mail.md) specification.
 
 ### Payload Encryption
 
@@ -373,7 +373,7 @@ Packet codes `0x7E` and `0x7F` may be used to implement Waku Mail Server and Cli
 
 Waku supports multiple capabilities. These include light node, rate limiting and bridging of traffic. Here we list these capabilities, how they are identified, what properties they have and what invariants they must maintain.
 
-Additionally there is the capability of a mailserver which is documented in its on [specification](../../application/8/mail.md).
+Additionally there is the capability of a mailserver which is documented in its on [specification](../8/mail.md).
 
 ### Light node
 
@@ -452,7 +452,7 @@ It is desirable to have a strategy for maintaining forward compatibility between
 
 ## Appendix A: Security considerations
 
-There are several security considerations to take into account when running Waku. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used. The security considerations for extra capabilities such as [mailservers](../../application/8/mail.md#security-considerations) can be found in their respective specifications.
+There are several security considerations to take into account when running Waku. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used. The security considerations for extra capabilities such as [mailservers](../8/mail.md#security-considerations) can be found in their respective specifications.
 
 ### Scalability and UX
 

waku/standards/legacy/7/data.md

@@ -9,7 +9,7 @@ contributors:
   - Kim De Mey <kimdemey@status.im>
 ---
 
-This specification describes the encryption, decryption and signing of the content in the [data field used in Waku](../../standards/core/6/waku1.md/#abnf-specification).
+This specification describes the encryption, decryption and signing of the content in the [data field used in Waku](../6/waku1.md/#abnf-specification).
 
 ## Specification
 

waku/standards/legacy/8/mail.md

@@ -100,7 +100,7 @@ A mailserver client fetches archival envelopes from a mailserver through a direc
 In this direct connection, the client discloses its IP/ID as well as the topics/ bloom filter it is interested in to the mailserver.
 The collection of such information allows the mailserver to link clients' IP/IDs to their topic interests and build a profile for each client over time.
 As such, the mailserver client has to trust the mailserver with this level of information.
-A similar concern exists for the light nodes and their direct peers which is discussed in the security considerations of [6/WAKU1](/spec/7).
+A similar concern exists for the light nodes and their direct peers which is discussed in the security considerations of [6/WAKU1](../6/waku1.md).
 
 **Mailserver trusted connection:**
 

waku/standards/legacy/9/rpc.md

@@ -46,7 +46,7 @@ In this section you will find objects used throughout the JSON RPC API.
 
 #### Message
 
-The message object represents a Waku message. Below you will find the description of the attributes contained in the message object. A message is the decrypted payload and padding of an [envelope](/spec/7) along with all of its metadata and other extra information such as the hash.
+The message object represents a Waku message. Below you will find the description of the attributes contained in the message object. A message is the decrypted payload and padding of an [envelope](../7/data.md) along with all of its metadata and other extra information such as the hash.
 
 | Field | Type | Description |
 | ----: | :--: | ----------- |