Fix linting errors

Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>

.github/workflows/markdown-lint.yml

@@ -16,17 +16,8 @@ jobs:
       - 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 }}
+          configFile: .github/workflows/markdownlint.json
+          globs: '**/*.md'

.github/workflows/markdownlint.json

@@ -0,0 +1 @@
+

.github/workflows/website-sync.yml

@@ -1,41 +0,0 @@
-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

codex/README.md

@@ -1,3 +1,4 @@
 # Codex RFCs
 
-Codex specifications related to a decentralised data storage platform.
+Specifications related the Codex decentralised data storage platform.
+Visit [Codex specs](https://github.com/codex-storage/codex-spec) to view the new Codex specifications currently under discussion.

nomos/README.md

@@ -1,3 +1,6 @@
-# Nomos Request For Comments(RFC)
+# Nomos RFCs
 
-Nomos is building secure, flexible, and scalable infrastructure for developers creating applications for the network state.
+Nomos is building a secure, flexible, and 
+scalable infrastructure for developers creating applications for the network state.
+To learn more about Nomos current protocols under discussion,
+head over to [Nomos Specs](https://github.com/logos-co/nomos-specs).

status/55/1to1-chat.md

@@ -6,7 +6,7 @@ status: draft
 category: Standards Track
 tags: waku-application
 description: A chat protocol to send public and private messages to a single recipient by the Status app.
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 - Andrea Piana <andreap@status.im>
 - Pedro Pombeiro <pedro@status.im>
@@ -54,7 +54,7 @@ There are two phases in the initial negotiation of a 1:1 chat:
 A QR code serves two purposes simultaneously - identity verification and initial key material retrieval;
 1. **Asynchronous initial key exchange**
 
-For more information on account generation and trust establishment, see [65/ACCOUNT-ADDRESS](../65/account-address.md)
+For more information on account generation and trust establishment, see [65/STATUS-ACCOUNT-ADDRESS](../65/account-address.md)
 
 ### Post Negotiation
 
@@ -213,7 +213,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md)
 2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
-3. [65/STATUS-ACCOUNT](../65/account-address.md)
+3. [65/STATUS-ACCOUNT-ADDRESS](../65/account-address.md)
 4. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-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)

status/56/communities.md

@@ -6,7 +6,7 @@ status: draft
 category: Standards Track
 tags: waku-application
 description: Status Communities allow multiple users to communicate in a discussion space. This is a key feature of the Status application.
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 - Andrea Piana <andreap@status.im>
 ---

status/63/keycard-usage.md

@@ -5,7 +5,7 @@ name: Status Keycard Usage
 status: draft
 category: Standards Track
 description: Describes how an application can use the Status Keycard to create, store and transact with different account addresses.
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
   - Jimmy Debe <jimmy@status.im>
 ---

status/65/account-address.md

@@ -5,7 +5,7 @@ name: Status Account Address
 status: draft
 category: Standards Track
 description: Details of what a Status account address is and how account addresses are created and used.
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 - Corey Petty <corey@status.im>
 - Oskar Thorén <oskarth@titanproxy.com>

status/raw/status-mvds.md

@@ -0,0 +1,126 @@
+---
+title: STATUS-MVDS-USAGE
+name: MVDS Usage in Status
+status: raw
+category: Best Current Practice
+description: Defines how MVDS protocol used by different message types in Status.
+editor: Kaichao Sun <kaichao@status.im>
+contributors:
+---
+
+## Abstract
+
+This document lists the types of messages that are using [MVDS](/vac/2/mvds.md) in the Status application.
+
+## Background
+
+Status app uses MVDS to ensure messages going through Waku are acknolwedged by the recipient. This is to ensure that the messages are not missed by any interested parties.
+
+
+## Message types
+
+Various Message Types contain distinct information defined by the app to facilitate convenient serialization and deserialization.
+
+E2E reliability is a feature that ensures messages are delivered to the recipient. This is initially achieved by using MVDS in Status.
+
+Chat Type specifies the category of chat that a message belongs to. It can be OneToOne (aka Direct Message), GroupChat, or CommunityChat. These are the three main types of chats in Status.
+
+| Message Type                                                               | Use MVDS                            | Need e2e reliability | Chat Type               |
+|----------------------------------------------------------------------------|-------------------------------------|----------------------|-------------------------|
+| ApplicationMetadataMessage_UNKNOWN                                         | No                                  | No                   | Not Applied             |
+| ApplicationMetadataMessage_CHAT_MESSAGE                                    | Yes for OneToOne & PrivateGroupChat | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_CONTACT_UPDATE                                  | Yes                                 | Yes                  | OneToOne                |
+| ApplicationMetadataMessage_MEMBERSHIP_UPDATE_MESSAGE                       | No                                  | Yes                  | CommunityChat           |
+| ApplicationMetadataMessage_SYNC_PAIR_INSTALLATION                          | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_DEPRECATED_SYNC_INSTALLATION                    | No                                  | No                   | Pair                    |
+| ApplicationMetadataMessage_REQUEST_ADDRESS_FOR_TRANSACTION                 | Yes for OneToOne                    | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_ACCEPT_REQUEST_ADDRESS_FOR_TRANSACTION          | Yes for OneToOne                    | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_DECLINE_REQUEST_ADDRESS_FOR_TRANSACTION         | Yes for OneToOne                    | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_REQUEST_TRANSACTION                             | Yes for OneToOne                    | Yes                  | OneToOne & GroupChat    |
+| ApplicationMetadataMessage_SEND_TRANSACTION                                | Yes for OneToOne                    | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_DECLINE_REQUEST_TRANSACTION                     | Yes for OneToOne                    | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_SYNC_INSTALLATION_CONTACT_V2                    | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_INSTALLATION_ACCOUNT                       | No                                  | No                   | Not Applied             |
+| ApplicationMetadataMessage_CONTACT_CODE_ADVERTISEMENT                      | No                                  | No                   | Not Applied             |
+| ApplicationMetadataMessage_PUSH_NOTIFICATION_REGISTRATION                  | No                                  | No                   | One & Group & Community |
+| ApplicationMetadataMessage_PUSH_NOTIFICATION_REGISTRATION_RESPONSE         | No                                  | No                   | One & Group & Community |
+| ApplicationMetadataMessage_PUSH_NOTIFICATION_QUERY                         | No                                  | No                   | One & Group & Community |
+| ApplicationMetadataMessage_PUSH_NOTIFICATION_QUERY_RESPONSE                | No                                  | No                   | One & Group & Community |
+| ApplicationMetadataMessage_PUSH_NOTIFICATION_REQUEST                       | No                                  | No                   | One & Group & Community |
+| ApplicationMetadataMessage_PUSH_NOTIFICATION_RESPONSE                      | No                                  | No                   | One & Group & Community |
+| ApplicationMetadataMessage_EMOJI_REACTION                                  | No                                  | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_GROUP_CHAT_INVITATION                           | Yes                                 | Yes                  | GroupChat               |
+| ApplicationMetadataMessage_CHAT_IDENTITY                                   | No                                  | No                   | OneToOne                |
+| ApplicationMetadataMessage_COMMUNITY_DESCRIPTION                           | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_INVITATION                            | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_REQUEST_TO_JOIN                       | No                                  | Yes                  | CommunityChat           |
+| ApplicationMetadataMessage_PIN_MESSAGE                                     | Yes for OneToOne & PrivateGroupChat | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_EDIT_MESSAGE                                    | Yes for OneToOne & PrivateGroupChat | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_STATUS_UPDATE                                   | No                                  | No                   | Not Applied             |
+| ApplicationMetadataMessage_DELETE_MESSAGE                                  | Yes for OneToOne & PrivateGroupChat | Yes                  | One & Group & Community |
+| ApplicationMetadataMessage_SYNC_INSTALLATION_COMMUNITY                     | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_ANONYMOUS_METRIC_BATCH                          | No                                  | No                   | Not Applied             |
+| ApplicationMetadataMessage_SYNC_CHAT_REMOVED                               | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_CHAT_MESSAGES_READ                         | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_BACKUP                                          | No                                  | No                   | Not Applied             |
+| ApplicationMetadataMessage_SYNC_ACTIVITY_CENTER_READ                       | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_ACTIVITY_CENTER_ACCEPTED                   | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_ACTIVITY_CENTER_DISMISSED                  | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_BOOKMARK                                   | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_CLEAR_HISTORY                              | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_SETTING                                    | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_COMMUNITY_MESSAGE_ARCHIVE_MAGNETLINK            | No                                  | No                   | CommunityChat           |
+| ApplicationMetadataMessage_SYNC_PROFILE_PICTURES                           | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_ACCOUNT                                    | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_ACCEPT_CONTACT_REQUEST                          | Yes                                 | Yes                  | OneToOne                |
+| ApplicationMetadataMessage_RETRACT_CONTACT_REQUEST                         | Yes                                 | Yes                  | OneToOne                |
+| ApplicationMetadataMessage_COMMUNITY_REQUEST_TO_JOIN_RESPONSE              | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_SYNC_COMMUNITY_SETTINGS                         | Yes                                 | Yes                  | CommunityChat           |
+| ApplicationMetadataMessage_REQUEST_CONTACT_VERIFICATION                    | Yes                                 | Yes                  | OneToOne                |
+| ApplicationMetadataMessage_ACCEPT_CONTACT_VERIFICATION                     | Yes                                 | Yes                  | OneToOne                |
+| ApplicationMetadataMessage_DECLINE_CONTACT_VERIFICATION                    | Yes                                 | Yes                  | OneToOne                |
+| ApplicationMetadataMessage_SYNC_TRUSTED_USER                               | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_VERIFICATION_REQUEST                       | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_CONTACT_REQUEST_DECISION                   | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_COMMUNITY_REQUEST_TO_LEAVE                      | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_SYNC_DELETE_FOR_ME_MESSAGE                      | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_SAVED_ADDRESS                              | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_COMMUNITY_CANCEL_REQUEST_TO_JOIN                | No                                  | Yes                  | CommunityChat           |
+| ApplicationMetadataMessage_CANCEL_CONTACT_VERIFICATION                     | Yes                                 | Yes                  | OneToOne                |
+| ApplicationMetadataMessage_SYNC_KEYPAIR                                    | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_SOCIAL_LINKS                               | No                                  | No                   | Not Applied             |
+| ApplicationMetadataMessage_SYNC_ENS_USERNAME_DETAIL                        | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_COMMUNITY_EVENTS_MESSAGE                        | No                                  | No                   | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_EDIT_SHARED_ADDRESSES                 | No                                  | No                   | CommunityChat           |
+| ApplicationMetadataMessage_SYNC_ACCOUNT_CUSTOMIZATION_COLOR                | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_ACCOUNTS_POSITIONS                         | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_COMMUNITY_PRIVILEGED_USER_SYNC_MESSAGE          | No                                  | No                   | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_SHARD_KEY                             | Yes                                 | Yes                  | CommunityChat           |
+| ApplicationMetadataMessage_SYNC_CHAT                                       | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_ACTIVITY_CENTER_DELETED                    | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_ACTIVITY_CENTER_UNREAD                     | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_ACTIVITY_CENTER_COMMUNITY_REQUEST_DECISION | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_SYNC_TOKEN_PREFERENCES                          | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_COMMUNITY_PUBLIC_SHARD_INFO                     | No                                  | No                   | CommunityChat           |
+| ApplicationMetadataMessage_SYNC_COLLECTIBLE_PREFERENCES                    | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_COMMUNITY_USER_KICKED                           | No                                  | No                   | CommunityChat           |
+| ApplicationMetadataMessage_SYNC_PROFILE_SHOWCASE_PREFERENCES               | Yes                                 | Yes                  | Pair                    |
+| ApplicationMetadataMessage_COMMUNITY_PUBLIC_STORENODES_INFO                | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_REEVALUATE_PERMISSIONS_REQUEST        | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_DELETE_COMMUNITY_MEMBER_MESSAGES                | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_UPDATE_GRANT                          | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_ENCRYPTION_KEYS_REQUEST               | No                                  | Yes                  | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_TOKEN_ACTION                          | No                                  | Weak Yes             | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_SHARED_ADDRESSES_REQUEST              | No                                  | No                   | CommunityChat           |
+| ApplicationMetadataMessage_COMMUNITY_SHARED_ADDRESSES_RESPONSE             | No                                  | No                   | CommunityChat           |
+
+
+
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+- [MVDS](/vac/2/mvds.md)

status/raw/status-waku-usage.md

@@ -4,7 +4,7 @@ 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>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors: 
 - Jimmy Debe <jimmy@status.im>
 

vac/1/coss.md

@@ -4,14 +4,15 @@ title: 1/COSS
 name: Consensus-Oriented Specification System
 status: draft
 category: Best Current Practice
-editor: Oskar Thoren <oskarth@titanproxy.com>
+editor: Daniel Kaiser <danielkaiser@status.im>
 contributors:
+  - Oskar Thoren <oskarth@titanproxy.com>
   - Pieter Hintjens <ph@imatix.com>
   - André Rebentisch <andre@openstandards.de>
   - Alberto Barrionuevo <abarrio@opentia.es>
   - Chris Puttick <chris.puttick@thehumanjourney.net>
   - Yurii Rashkovskii <yrashk@gmail.com>
-  - Daniel Kaiser <danielkaiser@status.im>
+  - Jimmy Debe <jimmy@status.im>
 ---
 
 This document describes a consensus-oriented specification system (COSS) for building interoperable technical specifications.
@@ -22,21 +23,23 @@ It is equivalent except for some areas:
 
 - recommending the use of a permissive licenses, such as CC0 (with the exception of this document);
 - miscellaneous metadata, editor, and format/link updates;
-- more inheritance from the [IETF Standards Process][https://www.rfc-editor.org/rfc/rfc2026.txt],
+- more inheritance from the [IETF Standards Process](https://www.rfc-editor.org/rfc/rfc2026.txt),
   e.g. using RFC categories: Standards Track, Informational, and Best Common Practice;
 - standards track specifications SHOULD follow a specific structure that both streamlines editing,
   and helps implementers to quickly comprehend the specification
 - specifications MUST feature a header providing specific meta information
+- raw specifications will not be assigned numbers
+- section explaining the [IFT](https://free.technology/) Request For Comments specification process managed by the Vac service department
 
 ## License
 
-Copyright (c) 2008-22 the Editor and Contributors.
+Copyright (c) 2008-24 the Editor and Contributors.
 
 This Specification is free software;
 you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation;
 either version 3 of the License, or (at your option) any later version.
 
-This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
+This specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
 without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 See the GNU General Public License for more details.
 
@@ -70,7 +73,6 @@ Principles:
 * The process should allow deprecation of old specifications.
 
 Specifications should take minutes to explain, hours to design, days to write, weeks to prove, months to become mature, and years to replace.
-
 Specifications have no special status except that accorded by the community.
 
 ## Architecture
@@ -78,31 +80,47 @@ Specifications have no special status except that accorded by the community.
 COSS is designed around fast, easy to use communications tools.
 Primarily, COSS uses a wiki model for editing and publishing specifications texts.
 
-* The *domain* is the conservancy for a set of specifications in a certain area.
-* Each domain is implemented as an Internet domain, hosting a wiki and optionally other communications tools.
-* Each specification is a set of wiki pages, together with comments, attached files, and other resources.
-* Important specifications may also exist as subdomains, i.e. child wikis.
+* The *domain* is the conservancy for a set of specifications.
+* The *domain* is implemented as an Internet domain. 
+* Each specification is a document together with references and attached resources.
+* A *sub-domain* is a initiative under a specific domain.
 
-Individuals can become members of the domain by completing the necessary legal clearance.
+Individuals can become members of the *domain* by completing the necessary legal clearance.
 The copyright, patent, and trademark policies of the domain must be clarified in an Intellectual Property policy that applies to the domain.
 
-Specifications exist as multiple pages, one page per version of the specification (see "Branching and Merging", below), which may be assigned URIs that include an incremental number.
-Thus, we refer to a specification by specifying its domain, number, and short name.
-New versions of the same specification will have new numbers.
+Specifications exist as multiple pages, one page per version,
+(discussed below in "Branching and Merging"),
+which should be assigned URIs that MAY include an number identifier.
+
+Thus, we refer to new specifications by specifying its domain, its sub-domain and short name.
+The syntax for a new specification reference is:
+
+    <domain>/<sub-domain>/<shortname>
+
+For example, this specification should be **rfc.vac.dev/vac/COSS**, 
+if the status were **raw**.
+    
+A number will be assigned to the specification when obtaining **draft** status. 
+New versions of the same specification will be assigned a new number.
 The syntax for a specification reference is:
 
-    <domain>/spec/<number>/<shortname>
+    <domain>/<sub-domain>/<number>/<shortname>
 
-For example, this specification is **rfc.vac.dev/spec/1/COSS**.
+For example, this specification is **rfc.vac.dev/vac/1/COSS**.
 The short form **1/COSS** may be used when referring to the specification from other specifications in the same domain.
 
-Every specification (including branches) carries a different number.
+Specifications (excluding raw specifications) carries a different number including branches.
 
 ## COSS Lifecycle
 
 Every specification has an independent lifecycle that documents clearly its current status.
+For a specification to receive a lifecycle status,
+a new specification SHOULD be presented by the team of the sub-domain.
+After discussion amongst the contributors has reached a rough consensus,
+as described in [RFC7282](https://www.rfc-editor.org/rfc/rfc7282.html),
+the specification MAY begin the process to upgrade it's status.
 
-A specification has six possible states that reflect its maturity and contractual weight:
+A specification has five possible states that reflect its maturity and contractual weight:
 
 ![Lifecycle diagram](./images/lifecycle.png)
 
@@ -110,12 +128,13 @@ A specification has six possible states that reflect its maturity and contractua
 
 All new specifications are **raw** specifications.
 Changes to raw specifications can be unilateral and arbitrary.
-Those seeking to implement a raw specification should ask for it to be made a draft specification.
+A sub-domain MAY use the **raw** status for new specifications that live under their domain.
 Raw specifications have no contractual weight.
 
 ### Draft Specifications
 
-When raw specifications can be demonstrated, they become **draft** specifications.
+When raw specifications can be demonstrated, 
+they become **draft** specifications and are assigned numbers.
 Changes to draft specifications should be done in consultation with users.
 Draft specifications are contracts between the editors and implementers.
 
@@ -143,7 +162,7 @@ Retired specifications have no contractual weight.
 Deleted specifications are those that have not reached maturity (stable) and were discarded.
 They should not be used and are only kept for their historical value.
 Only Raw and Draft specifications can be deleted.
-
+ 
 ## Editorial control
 
 A specification MUST have a single responsible editor,
@@ -157,12 +176,17 @@ Unlike the original C4 process however, it is RECOMMENDED to use CC0 as a more p
 We SHOULD NOT use GPL or GPL-like license.
 One exception is this specification, as this was the original license for this specification.
 
-The editor is responsible for accurately maintaining the state of specifications and for handling all comments on the specification.
+The editor is responsible for accurately maintaining the state of specifications, 
+for retiring different versions that may live in other places and 
+for handling all comments on the specification.
 
 ## Branching and Merging
 
 Any member of the domain MAY branch a specification at any point.
 This is done by copying the existing text, and creating a new specification with the same name and content, but a new number.
+Since **raw** specifications are not assigned a number,
+branching by any member of a sub-domain MAY differentiate specifications based on date, contributors, or 
+version number within the document.
 The ability to branch a specification is necessary in these circumstances:
 
 * To change the responsible editor for a specification, with or without the cooperation of the current responsible editor.
@@ -203,9 +227,36 @@ This will enable programmatic access to specification metadata.
 | **editor**       | editor name/email    | string | Oskar Thoren <oskarth@titanproxy.com>                                                                                                                                                                                                      |
 | **contributors** | contributors         | list   | - Pieter Hintjens <ph@imatix.com><br> - André Rebentisch <andre@openstandards.de><br> - Alberto Barrionuevo <abarrio@opentia.es><br> - Chris Puttick <chris.puttick@thehumanjourney.net><br> - Yurii Rashkovskii <yrashk@gmail.com> |
 
-### Specification Template
+### IFT/Vac RFC Process
 
-Standards Track specifications SHOULD be based on the [Vac RFC template](./images/template.md).
+> [!Note]
+This section is introduced to allow contributors to understand the IFT 
+(Institute of Free Technology) Vac RFC specification process.
+Other organizations may make changes to this section according to their needs.
+
+Vac is a department under the IFT organization that provides RFC (Request For Comments) specification services.
+This service works to help facilitate the RFC process, assuring standards are followed.
+Contributors within the service SHOULD assist a *sub-domain* in creating a new specification, 
+editing a specification, and promoting the status of a specification along with other tasks.
+Once a specification reaches some level of maturity by rough consensus,
+the specification SHOULD enter the [Vac RFC](rfc.vac.dev) process.
+Similar to the IETF working group adoption described in [RFC6174](https://www.rfc-editor.org/rfc/rfc6174.html), 
+the Vac RFC process SHOULD facilitate all updates to the specification.
+
+Specifications are introduced by projects, 
+under a specific *domain*, with the intention of becoming technically mature documents.
+The IFT domain currently houses the following projects:
+- [Status](status.app)
+- [Waku](https://waku.org/)
+- [Codex](https://codex.storage/)
+- [Nimbus](https://nimbus.team/)
+- [Nomos](https://nomos.tech/)
+
+When a specification is promoted to *draft* status, 
+the number that is assigned MAY be incremental 
+or by the *sub-domain* and the Vac RFC process.
+Standards track specifications MUST be based on the [Vac RFC template](../template.md) before obtaining a new status.
+All changes, comments, and contributions SHOULD be documented.
 
 ## Conventions
 

vac/2/images/batch.msc

@@ -0,0 +1,14 @@
+# Alice and Bob: batch data sync
+msc {
+  hscale="2", wordwraparcs=on;
+
+  alice [label="Alice"],
+  bob [label="Bob"];
+
+  --- [label="batch data sync"];
+  alice => alice [label="add messages to payload state"];
+  alice >> bob [label="send payload with messages"];
+
+  bob => bob [label="add acks to payload state"];
+  bob >> alice [label="send payload with acks"];
+}

vac/2/images/interactive.msc

@@ -0,0 +1,20 @@
+# Alice and Bob: interactive data sync
+msc {
+  hscale="2", wordwraparcs=on;
+
+  alice [label="Alice"],
+  bob [label="Bob"];
+
+  --- [label="interactive data sync"];
+  alice => alice [label="add offers to payload state"];
+  alice >> bob [label="send payload with offers"];
+    
+  bob => bob [label="add requests to payload state"];
+  bob >> alice [label="send payload with requests"];
+  
+  alice => alice [label="add requested messages to state"];
+  alice >> bob [label="send payload with messages"];
+  
+  bob => bob [label="add acks to payload state"];
+  bob >> alice [label="send payload with acks"];
+}

vac/2/mvds.md

@@ -97,7 +97,7 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
  - All records that require retransmission are added to the payload, given `Send Epoch` has been reached.
 
 <p align="center">
-    <img src="../assets/mvds/interactive.png" />
+    <img src="./images/interactive.png" />
     <br />
     Figure 1: Delivery without retransmissions in interactive mode.
 </p>
@@ -112,7 +112,7 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
 <!-- diagram -->
 
 <p align="center">
-    <img src="../assets/mvds/batch.png" />
+    <img src="./images/batch.png" />
     <br />
     Figure 2: Delivery without retransmissions in batch mode.
 </p>

vac/32/rln-v1.md

@@ -3,7 +3,7 @@ slug: 32
 title: 32/RLN-V1
 name: Rate Limit Nullifier
 status: draft
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 - Barry Whitehat <barrywhitehat@protonmail.com>
 - Sanaz Taheri <sanaz@status.im>

vac/raw/mix.md

@@ -0,0 +1,744 @@
+---
+title: LIBP2P-MIX
+name:  Libp2p Mix Protocol
+status: raw
+category: Standards Track
+tags:
+editor: Akshaya Mani <akshaya@status.im>
+contributors:
+---
+
+## Abstract
+
+This document specifies the Mix protocol, a custom protocol within the
+[libp2p](https://libp2p.io) framework designed to enable anonymous communication
+in peer-to-peer networks. The Mix protocol allows libp2p nodes to send messages
+without revealing the sender's identity to intermediary nodes or the recipient.
+It achieves this by using the [Sphinx packet format](https://www.researchgate.net/publication/220713667_Sphinx_A_Compact_and_Provably_Secure_Mix_Format),
+which encrypts and routes messages through a series of nodes (mix nodes)
+before reaching the recipient.
+
+Key features of the protocol include:
+
+i. Path selection for choosing a random route through the network via multiple
+mix nodes.\
+ii. Sphinx packet construction and processing, providing cryptographic
+guarantees of anonymity and security.\
+iii. Pluggable spam protection mechanism to prevent abuse of the mix network.\
+iv. Delayed message forwarding to thwart timing analysis attacks.
+
+**Protocol identifier:** `"/mix/1.0.0"`
+
+Note: The Mix Protocol is designed to work alongside existing libp2p protocols,
+allowing for seamless integration with current libp2p applications while
+providing enhanced privacy features. For example, it can encapsulate messages
+from protocols like [GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.2.md)
+to ensure sender anonymity.
+
+## Background
+
+libp2p protocols do not inherently protect sender identities.
+
+The Mix protocol enhances anonymity in libp2p by implementing a mix network,
+where messages are anonymized through multiple relay nodes before reaching the
+intended recipient. The Sphinx packet format is a well-researched component which
+this specification leverages to offer strong anonymity properties by concealing
+sender and recipient information at each relay.
+
+Using this approach, even the nodes relaying messages cannot determine the
+sender or final recipient, within a robust adversarial model. This decentralized
+solution distributes trust among participants, eliminating single points of
+failure and enhancing overall network resilience. Additionally, pluggable
+spam protection mechanism and delayed forwarding address common attacks on
+anonymity networks, such as spam and timing analysis.
+
+The Mix protocol is designed with flexibility in mind, allowing for
+pluggable components such as spam protection, peer discovery, and
+incentivization mechanisms. This design choice enables the protocol to evolve
+and adapt to different network requirements and constraints. This also leaves
+room for future enhancements such as cover traffic generation.
+
+By incorporating these features, the Mix protocol aims to provide a robust
+anonymity layer within the libp2p ecosystem, enabling developers to easily
+incorporate privacy features into their applications.
+
+## Specification
+
+### 1. Protocol Identifier
+
+The Mix protocol is identified by the string `"/mix/1.0.0"`.
+
+### 2. Custom Mix Protocol
+
+The Mix protocol is designed as a standalone protocol,
+identified by the protocol identifier `"/mix/1.0.0"`.
+This approach allows the Mix protocol to operate independently,
+decoupled from specific applications,
+providing greater flexibility and reusability across various libp2p protocols.
+By doing so, the Mix protocol can evolve independently,
+focusing on its core functionality without being tied to the development
+and maintenance cycles of other protocols.
+
+#### 2.1 Mix Nodes Roles
+
+All nodes participating in the Mix protocol are considered as mix nodes. They
+have the capability to create/process and forward Sphinx packets. Mix nodes can
+play different roles depending on their position in a particular message path:
+
+- **Sender Node**
+  - A mix node that initiates the anonymous message publishing process.
+  - Responsible for:
+    - Path selection.
+    - Sphinx packet creation.
+    - Initiating the message routing through the mix network.
+  - Must run both the Mix protocol instance and the instance of the libp2p
+    protocol for the message being published (_e.g.,_ GossipSub, Ping, etc.).
+- **Intermediary Mix Node**
+  - A mix node that is neither the sender nor the exit node in a message path.
+  - Responsible for:
+    - Receiving Sphinx packets.
+    - Processing (decrypting and re-encrypting) Sphinx packets.
+    - Forwarding processed packets to the next node in the path.
+  - Only needs to run the Mix protocol instance.
+- **Exit Node**
+  - The final mix node in a message path.
+  - Responsible for:
+    - Receiving and processing the final Sphinx packet.
+    - Extracting the original message.
+    - Disseminating the decrypted message using the appropriate libp2p protocol.
+  - Must run both the Mix protocol instance and the instance of the libp2p
+    protocol for the message being published.
+
+#### 2.2 Roles Flexibility
+
+A single mix node can play different roles in different paths:
+
+- It can be a sender node for messages it initiates.
+- It can be an intermediary node for messages it is forwarding.
+- It can be an exit node for messages it is disseminating.
+
+#### 2.3 Incentives
+
+To publish an anonymous libp2p message (_e.g.,_ GossipSub, Ping, etc.), nodes
+MUST run a mix node instance. This requirement serves as an incentive for nodes
+to participate in the mix network, as it allows them to benefit from the
+anonymity features while also contributing to the network's overall anonymity
+and robustness.
+
+#### 2.4 Node Discovery
+
+All mix nodes participate in the discovery process and maintain a list of
+discovered nodes.
+
+- **Bootstrap Nodes**
+
+  i. The network has a set of well-known bootstrap nodes that new mix nodes
+  can connect to when joining the network.\
+  ii. The bootstrap nodes help new mix nodes discover other active mix nodes in
+  the network.
+
+- **Discovery**
+  
+  i. All mix nodes publish their Ethereum Node Records (ENRs) containing:
+
+  ```json
+  {
+    "id": "v4",
+    "multiaddr": "/ip4/192.0.2.1/udp/9000/quic",
+    "ed25519": "0x5a6fcd3e9d6a5e4d5f71e7e5b4cfa9b7b73d9f5f7e9a8b9c5d7f9e8d5a6f7c9e",
+    "mix": "/mix/1.0.0",
+    "supported_protocols": ["ping", "gossipsub"]
+  }
+  ```
+
+  **Field Explanations**
+
+  - `id`: Indicates the ENR format version (_e.g.,_ `"v4"`).
+  - `multiaddr`: The node's multiaddress, including the transport protocol
+    (_e.g.,_ QUIC) and IP address/port.
+  - `ed25519`: The node's Ed25519 public key, used for Sphinx encryption.
+  - `mix`: Indicates the supported Mix protocol version (_e.g.,_ `"/mix/1.0.0"`).
+  - `supported_protocols`: A list of other libp2p protocols supported by the
+    node (_e.g.,_ Ping, GossipSub, etc.).
+  - Additional fields may be included based on the node's requirements.
+  
+  ii. The mix nodes use a peer discovery protocol like [WAKU](https://waku.org)/[Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md):
+  
+  - Connect to a set of bootstrap nodes when joining the network.
+  - Regularly update their list of known peers.
+  - Obtain a random sample of nodes that is representative of the network.
+
+- **Path Selection (Message Senders Only)**
+
+  To send an anonymous message, a mix node performs the following actions:
+  
+  i. Choose a random exit node that supports the required libp2p protocol for
+  the message.\
+  ii. Select remaining L-1 unique mix nodes randomly without replacement from
+  the list of discovered nodes.
+
+- **Forwarding To Next Hop (Intermediary Nodes Only)**
+
+  When a mix node receives an incoming Sphinx packet, it performs the following
+  actions:
+
+  i. Decrypts the packet to obtain the next hop multiaddress\
+  ii. Checks if the next hop is in the list of discovered nodes.\
+  iii. If not, performs discovery for that specific node.\
+  iv. Forwards the Sphinx packet to the next hop.
+
+#### 2.5 Protocol Registration
+
+The protocol is registered with the libp2p host using the `"/mix/1.0.0"`
+identifier. This identifier is used to establish connections and negotiate the
+protocol between libp2p peers.
+
+#### 2.6 Transport Layer
+
+The Mix protocol uses secure transport protocols to ensure confidentiality and
+integrity of communications. The recommended transport protocols are
+[QUIC](https://datatracker.ietf.org/doc/rfc9000/) or TLS (preferably QUIC
+due to its performance benefits and built-in features
+such as low latency and efficient multiplexing).
+
+#### 2.7 Connection Establishment
+
+- The sender initiates a secure connection (TLS or QUIC) to the first mix node
+  using the libp2p transport.
+- The sender uses the `"/mix/1.0.0"` protocol identifier to convey that the
+  connection is for the Mix protocol.
+- Once the connection is established, the sender can forward Sphinx packets
+  using the Mix protocol.
+- Subsequent mix nodes in the path follow the same process when forwarding
+  messages to other mix nodes.
+
+### 3. Cryptographic Primitives and Security Parameter
+
+- **Security Parameter:** $\kappa = 128$ bits provides a balance between
+  security and efficiency.
+- **Cryptographic Primitives**
+  - **Group G**: Curve25519 elliptic curve offers 128-bit security with small
+    (32-byte) group elements, efficient for both encryption and key exchange.
+  - **Hash function H**: SHA-256.
+  - **KDF:** SHA-256 (truncated to 128 bits).
+  - **AES-CTR:** AES-128 in counter mode.
+    - **Inputs:** Key `k` (16 bytes), Initialization Vector `iv` (16 bytes),
+      Plaintext `p`
+    - **Initialization Vector (IV)**: 16 bytes, chosen randomly for each
+      encryption.
+    - **Plaintext**: Data to be encrypted (_e.g.,_ routing information, message
+      payload).
+    - **Output**: Ciphertext `c` (same size as plaintext `p`).
+    - **Operation**: AES-CTR mode uses key and the counter (`iv`) to produce a
+      keystream, which is XORed with the plaintext to produce the ciphertext.
+  - **HMAC-SHA-256:** 256-bit MAC (truncated to 128 bits).
+    - **Inputs:** Key `k` (16 bytes), Message `m`
+    - **Message**: Data to be authenticated (_e.g.,_ $β$ component).
+    - **Output**: MAC `mac` (truncated to 128 bits).
+    - **Operation**: HMAC-SHA-256 uses the key and the message to produce a
+      hash-based message authentication code.
+
+### 4. Sphinx Packet Format
+
+#### 4.1 Packet Components and Sizes
+
+1. **Alpha ($α$)**: 32 bytes
+
+   - Represents a Curve25519 group element (x-coordinate in GF(2^255 - 19)).
+   - Used by mix nodes to extract shared session key using their private key.
+
+2. **Beta ($β$)**: $((t+1)r + 1)\kappa$ bytes typically, where $r$ is the maximum
+   path length.
+
+   - Contains the encrypted routing information.
+   - We recommend a reasonable maximum path length of $r=5$, considering
+    latency/anonymity trade-offs.
+   - This gives a reasonable size of $336$ bytes, when $t = 3$ (refer
+     Section 5.2.10 for the choice of $t$).
+   - We extend $β$ to accommodate next hop address and delay below.
+
+3. **Gamma ($γ$)**: $\kappa$ bytes (16 bytes)
+
+   - Output of HMAC-SHA-256, truncated to 128 bits.
+   - Ensures the integrity of the header information.
+
+4. **Delta ($δ$)**: The encrypted payload, which can be of variable size.
+   - According to the [MixMatch](https://petsymposium.org/popets/2024/popets-2024-0050.pdf)
+    paper, the Nym network uses Sphinx packets of a fixed
+    size (2413 bytes).
+   - Considering this, the maximum $δ$ size can be chosen as 2413 bytes minus
+    the header length (which will be derived below).
+
+#### 4.2 Address Format and Delay Specification
+
+In the original
+[Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf) paper, the
+authors use node IDs of size $\kappa$ ($16$ bytes) to represent the next hop
+addresses. To accommodate larger addresses, we'll use a combined size of
+$t\kappa$ bytes for the address and delay, where $t$ is small (_e.g.,_ $t = 2$
+or $3$).
+
+- **Delay**: 2 bytes
+  Allows delays up to 65,535 milliseconds ≈ 65 seconds.
+- **Address**: $t\kappa-2$ bytes
+  This flexible format can accommodate various address types, including:
+  - libp2p multiaddress (variable length, typically 32-64 bytes).
+  - Custom format with:
+    - IP address (IPv4 or IPv6, 4 or 16 bytes)
+    - TCP/UDP port number (2 bytes)
+    - QUIC/TLS protocol identifier flag (1 byte)
+    - Peer ID (32 bytes for Ed25519 or Secp256k1).
+
+The entire Sphinx packet header ($α$, $β$, and $γ$) can fit within a fixed size
+of $32 + (r(t+1)+1)\kappa + 16 = 384$ bytes, leaving ample room for a large $δ$ of
+up to $2413 - 384 = 2029$ bytes.
+
+#### 4.3 Message Format
+
+The Mix protocol uses the Sphinx packet format to encapsulate messages and
+routing information.
+
+```proto
+message SphinxPacket {
+  bytes alpha = 1; // 32 bytes
+  bytes beta = 2; // 304 - 384 bytes
+  bytes gamma = 3; // 16 bytes
+  bytes delta = 4; // variable size, max 2029 bytes
+}
+```
+
+### 5. Handler Function
+
+The [handler function](https://docs.libp2p.io/concepts/fundamentals/protocols/#handler-functions)
+is responsible for processing connections and messages for
+the Mix protocol. It operates according to the mix node roles (_i.e.,_ sender,
+intermediary mix node, or exit node) defined in
+[Section 2.1](#21-mix-nodes-roles). This function is crucial for implementing
+the core functionality of the mixnet protocol within the libp2p framework.
+
+When a node receives a new stream for the `"/mix/1.0.0"` protocol, the handler
+function is invoked. It performs different operations based on the node's role
+in the current message path:
+
+- **Role Determination**
+
+  The handler first determines the node's role for the incoming message. This
+  is typically done by examining the packet structure and the node's position
+  in the network.
+
+- **Packet Processing**
+
+  Depending on the role, the handler processes the Sphinx packet differently:
+
+  - For senders, it creates and sends new Sphinx packets.
+  - For intermediary nodes, it processes and forwards existing packets.
+  - For exit nodes, it decrypts the final layer and disseminates the original message.
+
+- **Error Handling**
+
+  It manages any errors that occur during packet processing, such as invalid
+  MACs or decryption failures.
+
+- **Logging and Metrics**
+
+  The handler is also be responsible for logging important events and
+  collecting metrics for network analysis and debugging.
+
+The specific implementation of the handler function for each role (_i.e.,_
+sender, intermediary, and exit node) is detailed in the following subsections.
+
+#### 5.1 Sender
+
+1. **Convert the libp2p Message to Bytes**
+
+   Serialize the libp2p message to bytes and store the result in
+   `libp2p_message`. This can be done using Protocol Buffers or another
+   serialization method.
+
+2. **Apply Spam Protection**
+
+   Apply the chosen spam protection mechanism to the `libp2p_message`.
+   This could be Proof of Work (PoW), Verifiable Delay Function (VDF),
+   Rate Limiting Nullifier (RLN), or other suitable approaches.
+
+   Refer to [Appendix A](#appendix-a-example-spam-protection-using-proof-of-work)
+   for details on the current implementation using PoW.
+
+3. **Prepare the Message**
+
+   Prepare the `message` by combining the `libp2p_message` with any necessary data
+   from the spam protection mechanism. The exact format of `message` will depend
+   on the chosen spam protection method.
+
+   Note: The spam protection mechanism is designed as a pluggable interface,
+   allowing for different methods to be implemented based on network requirements.
+   This flexibility extends to other components such as peer discovery and incentivization,
+   which are not specified in detail to allow for future optimizations and adaptations.
+
+4. **Perform Path Selection** (refer [Section 2.4](#24-node-discovery))
+
+   - Let the Ed25519 public keys of the mix nodes in the path be
+    $y_0,\ y_1,\ \ldots,\ y_{L-1}$.
+
+5. **Wrap Final Message in Sphinx Packet**
+   Perform the following steps to wrap `message` in a Sphinx packet:
+
+   a. **Compute** **Alphas ($α_i$**, **$i=0$** to **$L-1$)**
+
+   - Select a random exponent $x$ from $\mathbb{Z}_q^*$.
+   - Compute initial alpha $α_0$, shared secret $s_0$, and blinding factor $b_0$:
+     - $α_0 = g^x$ using Curve25519 scalar multiplication.
+     - $s_0 = y_0^x$, where $y_0$ is the public key of the first hop.
+     - $b_0 = H(α_0\ |\ s_0)$, where $H$ is the SHA-256 hash function (refer
+      _[Section 3](#3-cryptographic-primitives-and-security-parameter)_ for details).
+   - For each node $i$ (from $1$ to $L-1$):
+     - $α_i = α_{i-1}^{b_{i-1}}$ using Curve25519 scalar multiplication.
+     - $s_i = y_{i}^{x\prod_{\text{j=0}}^{\text{i-1}} b_{j}}$, where $y_{i}$ is
+      the public key of the i-th hop.
+     - $b_i = H(α_i\ |\ s_i)$, where $H$ is the SHA-256 hash function.
+
+   Note that $\alpha_i$ and $s_i$ are group elements, each 32 bytes long.
+
+   b. **Compute** **Filler Strings ($\phi_i$**, **$i=0$** to **$L-1$)**
+
+   - Initialize $\phi_0$ as an empty string.
+   - For each $i$ (from $1$ to $L-1$):
+
+     - Derive the AES key and IV:
+
+       $`\text{φ\_aes\_key}_{i-1} = KDF(\text{"aes\_key"}\ |\ s_{i-1})`$
+
+       $`\text{φ\_iv}_{i-1} = H(\text{"iv"}\ |\ s_{i-1})`$ (truncated to 128 bits)
+
+     - Compute the filler string $\phi_i$ using $\text{AES-CTR}^\prime_i$,
+       which is AES-CTR encryption with the keystream starting from
+       index $((t+1)(r-i)+t+2)\kappa$ :
+
+       $`\phi_i = \text{AES-CTR}^\prime_i(\text{φ\_aes\_key}_{i-1},\ \text{φ\_iv}_{i-1},
+       \ \phi_{i-1}\ |\ 0_{(t+1)\kappa})`$,
+       where $0_{(t+1)\kappa}$ is the string of $0$ bits of length $(t+1)\kappa$.
+
+   Note that the length of $\phi_i$ is $(t+1)i\kappa$.
+
+   c. **Compute** **Betas and Gammas ($\beta_i$**, $\gamma_i$, **$i=0$** to **$L-1$)**
+
+   For each $i$ (from $L-1$ to $0$):
+
+   - Derive the AES key, MAC key, and IV:
+
+     $`\text{β\_aes\_key}_{i} = KDF(\text{"aes\_key"}\ |\ s_{i})`$
+
+     $`\text{mac\_key}_{i} = KDF(\text{"mac\_key"}\ |\ s_{i})`$
+
+     $`\text{β\_iv}_{i} = H(\text{"iv"}\ |\ s_{i})`$ (truncated to 128 bits)
+
+   - Generate random $`\text{delay\_i}`$, a 16-bit unsigned integer (0-65535 milliseconds).
+
+     Note that top-level applications can use other probability distributions,
+     such as an exponential distribution, where shorter delays are more likely
+     than longer delays. This can mimic real-world traffic patterns and provide
+     robust anonymity against traffic analysis. The trade-off lies in balancing
+     the need for flexible delay handling with the risk of exposing
+     application-specific traffic patterns.
+
+   - If $i = L-1$ (_i.e.,_ exit node):
+
+     $`\beta_i = \text{AES-CTR}(\text{β\_aes\_key}_{i},\ \text{β\_iv}_{i},\ 0_{((t+1)
+     (r-L)+t+2)\kappa})\ |\ \phi_{L-1}`$
+
+   - Otherwise (_i.e.,_ intermediary node):
+
+     $`\beta_i = \text{AES-CTR}(\text{β\_aes\_key}_{i},\ \text{β\_iv}_{i},\ \text
+     {addr}_{i+1} \ |\ \text{delay}_{i+1}\ | \ \gamma_{i+1}\ |\ {\beta_{i+1}}_
+     {[0\ldots(r(t+1)-t)\kappa−1]})`$
+
+     Note that the length of $\beta_i$ is $(r(t+1)+1)\kappa$, $0 \leq i \leq L-1$,
+     where $t$ is the combined length of next hop address and delay.
+
+   - $`\gamma_i = \text{HMAC-SHA-256}(\text{mac\_key}_i,\ β_i)`$\
+      Note that the length of $\gamma_i$ is $\kappa$.
+
+   d. **Compute** **Deltas (**$\delta_i$, **$i=0$** to **$L-1$)**
+
+   For each $i$ (from $L-1$ to $0$):
+
+   - Derive the AES key and IV:
+
+     $`\text{δ\_aes\_key}_{i} = KDF(\text{"δ\_aes\_key"}\ |\ s_{i})`$
+
+     $`\text{δ\_iv}_{i} = H(\text{"δ\_iv"}\ |\ s_{i})`$ (truncated to 128 bits)
+
+   - If $i = L-1$ (_i.e.,_ exit node):
+
+     $`\delta_i = \text{AES-CTR}(\text{δ\_aes\_key}_{i},\ \text{δ\_iv}_{i},
+     \ 0_{\kappa}\ |\ m)`$, where $m$ is the `message`.
+
+   - Otherwise (_i.e.,_ intermediary node):
+
+     $`\delta_i = \text{AES-CTR}(\text{δ\_aes\_key}_{i},\ \text{δ\_iv}_{i},\ \delta_{i+1})`$
+
+     Note that the length of $\delta$ is $|m| + \kappa$.
+
+     Given that the derived size of $\delta$ is $2029$ bytes, this allows
+     `message` to be of length $2029-16 = 2013$ bytes. This means smaller
+     messages may need to be padded up to $2013$ bytes (e.g., using PKCS#7
+     padding).
+
+   e. **Construct Final Sphinx Packet**
+
+   - Initialize header
+
+     ```pseudocode
+     alpha = alpha_0 // 32 bytes
+     beta = beta_0 // $(r(t+1)+1)\kappa$ bytes
+     gamma = gamma_0 // 16 bytes
+     ```
+
+     As discussed earlier, for a maximum path length of $r = 5$, and combined
+     length of address and delay $t = 3\kappa = 48$ bytes, the header size is
+     just $384$ bytes.
+   - Initialize payload
+
+     `delta = delta_0 // variable size, max 2029 bytes`
+
+     For a fixed Sphinx packet size of $2413$ bytes and given the header length
+     of $384$ bytes, `delta` size is $2029$ bytes.
+
+6. **Serialize the Sphinx Packet** using Protocol Buffers.
+
+7. **Send the Serialized Packet** to the first mix node using the
+   `"/mix/1.0.0"` protocol.
+
+#### 5.2 Intermediary Mix Node
+
+Let $`x_i \in \mathbb{Z}_q^*`$ be the intermediary node’s private key
+corresponding to the public key $y_i \in G^*$. It performs the following steps
+to relay a message:
+
+1. **Receive and Deserialize** the Sphinx packet using Protocol Buffers.
+2. **Compute Shared Secret $s = \alpha^{x_{i}}$**.
+
+3. **Check If Previously Seen**
+
+   a. Compute tag $H(s)$, where $H$ is the SHA-256 hash function.
+
+   b. If tag is in the previously seen list of tags, discard the message.
+
+   c. This list can be reset whenever the node rotates its private key
+
+4. **Compute MAC**
+
+   a. Derive MAC key
+
+   $`\text{mac\_key} = KDF(\text{"mac\_key"}\ |\ s)`$
+
+   b. Check if $`\gamma = \text{HMAC-SHA-256}(\text{mac\_key},\ β)`$ . If not,
+   discard the message.
+
+   c. Otherwise, store tag $H(s)$ in the list of seen message tags.
+
+5. **Decrypt One Layer**
+
+   a. Derive the AES key, MAC key, and IV:
+
+   $`\text{β\_aes\_key} = KDF(\text{"aes\_key"}\ |\ s)`$
+
+   $`\text{β\_iv} = H(\text{"iv"}\ |\ s)`$ (truncated to 128 bits)
+
+   b. Compute
+   $`B = \text{AES-CTR}(\text{β\_aes\_key},\ \text{β\_iv},\ \beta\ |\ 0_{(t+1)k})`$.
+
+   c. Uniquely parse prefix of $B$
+
+   If $B$ has a prefix of **$0_{((t+1)(r-L)+t+2)\kappa}$,** the current node is the
+   exit node (refer exit node operations below).
+
+   Otherwise, it is an intermediary node and it performs the followings steps
+   to relay the message.
+
+   d. **Extract Routing Information**
+
+   $`\text{next\_hop} = B_{[0\ldots(t\kappa-17)]}`$ (first $t\kappa-2$ bytes).
+
+   e. **Extract Delay**
+
+   $`\text{delay} = B_{[(t\kappa-16)\ldots(t\kappa-1)]}`$ (following $2$ bytes).
+
+   f. **Extract Gamma**
+
+   $`{\gamma}' = B_{[t\kappa\ldots(t\kappa+\kappa-1)]}`$ (following $\kappa$ bytes).
+
+   g. **Extract Beta**
+
+   $`\beta' = B_{[(t\kappa+\kappa)\ldots(r(t+1)+t+2)\kappa-1]}`$ (following
+   $((t+1)r + 1)\kappa$ bytes).
+
+   h. **Compute Alpha**
+
+   - Compute blinding factor $b = H(α\ |\ s)$, where $H$ is the SHA-256 hash
+    function.
+   - Compute $α^′ = α^b$.
+
+   i. **Compute Delta**
+
+   - Derive the AES key and IV:
+     $`\text{δ\_aes\_key} = KDF(\text{"δ\_aes\_key"}\ |\ s)`$
+     $`\text{δ\_iv} = H(\text{"δ\_iv"}\ |\ s)$` (truncated to 128 bits)
+   - Compute $`\delta' = \text{AES-CTR}(\text{δ\_aes\_key},\ \text{δ\_iv},\ \delta)`$
+
+6. **Construct Final Sphinx Packet**
+
+   a. Initialize header
+
+   ```pseudocode
+    alpha = alpha' // 32 bytes
+    beta = beta' // $((t+1)r + 1)\kappa$ bytes
+    gamma = gamma' // 16 bytes
+   ```
+
+   b. Initialize payload
+
+   `delta = delta' // variable size, max 2029 bytes`
+
+7. **Serialize the Sphinx Packet** using Protocol Buffers.
+8. **Introduce A Delay** of $`\text{delay}`$ milliseconds.
+9. **Send the Serialized Packet** to $`\text{next\_hop}`$ using the
+    `"/mix/1.0.0"` protocol.
+
+#### 5.3 Exit Node
+
+1. **Perform _Steps i. to v. b._ Above**, similar to an intermediary node. If
+   $B$ has a prefix of $0_{((t+1)(r-L)+t+2)\kappa}$ (in _step 5. c._ above), the
+   current node is the exit node. It performs the following steps to
+   disseminate the message via the respective libp2p protocol.
+
+2. **Compute Delta**
+
+   - Derive the AES key and IV:
+
+     $`\text{δ\_aes\_key} = KDF(\text{"δ\_aes\_key"}\ |\ s)`$
+
+     $`\text{δ\_iv} = H(\text{"δ\_iv"}\ |\ s)`$ (truncated to 128 bits)
+
+   - Compute $`\delta' = \text{AES-CTR}(\text{δ\_aes\_key},\ \text{δ\_iv},\ \delta)`$.
+
+3. **Extract Message**
+
+   $m = \delta'_{[\kappa\ldots]}$ (remove first $\kappa$ bytes).
+
+4. **Remove Any Padding** from $m$ to obtain the `message` including any
+   necessary spam protection data.
+
+5. **Verify Spam Protection**
+
+   Verify the spam protection mechanism applied to the `message`.
+   If the verification fails, discard the `message`.
+   Refer to [Appendix A](#appendix-a-example-spam-protection-using-proof-of-work)
+   for details on the current implementation using PoW.
+
+6. **Deserialize the extracted message** using the respective libp2p protocol's
+   definition.
+
+7. **Disseminate the message** via the respective libp2p protocol (_e.g.,_
+   GossipSub).
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+### Normative
+
+[Handler function](https://docs.libp2p.io/concepts/fundamentals/protocols/#handler-functions)
+[libp2p](https://libp2p.io)\
+[Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf)
+
+### Informative
+
+[PoW](https://bitcoin.org/bitcoin.pdf)\
+[Sphinx packet size](https://petsymposium.org/popets/2024/popets-2024-0050.pdf)
+
+## Appendix A. Example Spam Protection using Proof of Work
+
+The current implementation uses a Proof of Work mechanism for spam protection.
+This section details the specific steps for attaching and verifying the PoW.
+
+### Structure
+
+The sender appends the PoW to the serialized libp2p message, `libp2p_message`,
+in a structured format, making it easy to parse and verify by the exit node.
+The sender includes the PoW as follows:
+
+ `message = <libp2p_message_bytes | timestamp | nonce>`
+
+where:
+
+ `<libp2p_message_bytes>`: Serialized libp2p message (variable length).
+
+`<timestamp>`: The current Unix timestamp in seconds (4 bytes).
+
+`<nonce>`: The nonce that satisfies the PoW difficulty criterion (4 bytes).
+
+**Nonce Size:** The nonce size should be large enough to ensure a sufficiently large
+search space. It should be chosen so that the range of possible nonce values
+allows for the difficulty target to be met. However, larger nonce sizes can increase
+the time and computational effort required to find a valid nonce. We use
+a 4-byte nonce to ensure sufficiently large search space with reasonable
+computational effort.
+
+**Difficulty Level:** The difficulty level is usually expressed as the number of
+leading zeros required in the hash output. It is chosen such that the
+computational effort required is significant but not prohibitive.
+We recommend a reasonable difficulty level that requires around
+16-18 leading zeros in the SHA-256 hash. This would roughly take
+0.65 to 2.62 seconds to compute in a low-grade CPU,
+capable of computing 100,000 hashes per second.
+
+### Calculate Proof of Work (PoW)
+
+The sender performs the following steps to compute the PoW challenge and response:
+
+i. **Create Challenge**
+
+Retrieves the current Unix timestamp, `timestamp`, in seconds (4 bytes).
+
+ii. **Find A Valid Nonce**
+
+- Initializes the `nonce` to a 4-byte value (initially zero).
+  
+- Increments the `nonce` until the SHA-256 hash of
+  `<libp2p_message_bytes | timestamp | nonce>` has at least
+  18 leading zeros.
+
+- The final value of the `nonce` is considered valid.
+
+### Attach the PoW to the libp2p Message
+
+  Append the 4-byte `timestamp` and the valid `nonce` to
+  the `libp2p_message_bytes` to form the `message`.
+
+  `message = <libp2p_message_bytes | timestamp | nonce>`
+
+### Verify PoW
+  
+i. **Extract Timestamp and Nonce**
+
+  Split `message` into 4-byte `nonce` (last 4 bytes), 4-byte `timestamp`
+  (the 4 bytes before the nonce), and the serialized libp2p message
+  to be published, `libp2p_message_bytes` (the remaining bytes).
+
+ii. **Verify Timestamp**
+  
+- Check the `timestamp` is within the last 5 minutes.
+  
+- If the timestamp is outside the acceptable window, the exit node
+  discards the message.
+
+iii. **Verifiy Response**
+
+- Compute the SHA-256 hash of the `message` and check if the hash
+  meets the difficulty requirement, _i.e._, has at least 18 leading zeros.
+  
+- If the hash is not valid, the exit node discards the message. Otherwise,
+  it follows the steps to publish the message.

vac/raw/rln-interep-spec.md

@@ -4,7 +4,7 @@ name: Interep as group management for RLN
 status: raw
 category:  
 tags: rln
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 ---
 

vac/raw/rln-stealth-commitments.md

@@ -2,7 +2,7 @@
 title: RLN-STEALTH-COMMITMENTS
 name: RLN Stealth Commitment Usage
 category: Standards Track
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 - Jimmy Debe <jimmy@status.im>
 ---

waku/standards/application/53/x3dh.md

@@ -5,7 +5,7 @@ name: X3DH usage for Waku payload encryption
 status: draft
 category: Standards Track
 tags: waku-application
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 - Andrea Piana <andreap@status.im>
 - Pedro Pombeiro <pedro@status.im>

waku/standards/application/54/x3dh-sessions.md

@@ -5,7 +5,7 @@ name: Session management for Waku X3DH
 status: draft
 category: Standards Track
 tags: waku-application
-editor: Aaryamann Challani <aaryamann@status.im>
+editor: Aaryamann Challani <p1ge0nh8er@proton.me>
 contributors:
 - Andrea Piana <andreap@status.im>
 - Pedro Pombeiro <pedro@status.im>

waku/standards/core/13/store.md

@@ -8,7 +8,7 @@ editor: Simon-Pierre Vivier <simvivier@status.im>
 contributors:
   - Dean Eigenmann <dean@status.im>
   - Oskar Thorén <oskarth@titanproxy.com>
-  - Aaryamann Challani <aaryamann@status.im>
+  - Aaryamann Challani <p1ge0nh8er@proton.me>
   - Sanaz Taheri <sanaz@status.im>
   - Hanno Cornelius <hanno@status.im>
 ---

waku/standards/core/14/message.md

@@ -8,7 +8,7 @@ tags: waku/core-protocol
 editor: Hanno Cornelius <hanno@status.im>
 contributors:
   - Sanaz Taheri <sanaz@status.im>
-  - Aaryamann Challani <aaryamann@status.im>
+  - Aaryamann Challani <p1ge0nh8er@proton.me>
   - Lorenzo Delgado <lorenzo@status.im>
   - Abhimanyu Rawat <abhi@status.im>
   - Oskar Thorén <oskarth@titanproxy.com>

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

@@ -7,7 +7,7 @@ tags: waku-core
 editor: Alvaro Revuelta <alvaro@status.im>
 contributors:
   - Oskar Thorén <oskarth@titanproxy.com>
-  - Aaryamann Challani <aaryamann@status.im>
+  - Aaryamann Challani <p1ge0nh8er@proton.me>
   - Sanaz Taheri <sanaz@status.im>
   - Hanno Cornelius <hanno@status.im>
 ---

waku/standards/core/64/network.md

@@ -18,6 +18,7 @@ accessible even to resource-restricted devices.
 We'll refer to this opinionated deployment simply as
 _the public Waku Network_, _the Waku Network_ or, if the context is clear, _the network_
 in the rest of this document.
+All The Waku Network configuration parameters are listed [here](https://github.com/waku-org/nwaku/blob/8bfad3ab453f96ac545c7cb0af06d0c0f34d1356/waku/factory/networks_config.nim#L31).
 
 ## Theory / Semantics
 
@@ -141,8 +142,8 @@ See the section on [autosharding](#autosharding) for more.
 
 ## RLN rate-limiting
 
-The [17/WAKU2-RLN-RELAY](../17/rln-relay.md) protocol uses [32/RLN-V1](../../../../vac/32/rln-v1.md) proofs
-to ensure that a pre-agreed rate limit is not exceeded by any publisher.
+The [17/WAKU2-RLN-RELAY](../17/rln-relay.md) protocol uses [RLN-V2](https://github.com/vacp2p/rfc-index/blob/a5b24ac0a27da361312260f9da372a0e6e812212/vac/raw/rln-v2.md) proofs
+to ensure that a pre-agreed rate limit of `x` messages every `y` seconds is not exceeded by any publisher.
 While the network is under capacity,
 individual relayers MAY choose to freely route messages without RLN proofs
 up to a discretionary bandwidth limit,
@@ -153,32 +154,25 @@ and at times of high network utilization these messages may not be relayed at al
 
 ### RLN Parameters
 
-For the Waku Network,
-the `epoch` is set to `1` second
-and the maximum number of messages published per `epoch` is limited to `1` per publisher.
-The `max_epoch_gap` is set to `20` seconds,
-meaning that validators (relay nodes),
-MUST _reject_ messages with an `epoch` more than 20 seconds into the past or 
-future compared to the validator's own clock.
-All nodes, validators and publishers,
-SHOULD use Network Time Protocol (NTP) to synchronize their own clocks,
+The Waku Network uses the following RLN parameters:
+
+* `rlnRelayUserMessageLimit=100`: Amount of messages that a membership is allowed to publish per epoch. Configurable between `0` and `MAX_MESSAGE_LIMIT`.
+* `rlnEpochSizeSec=600`: Size of the epoch in seconds.
+* `rlnRelayChainId=11155111`: Network in which the RLN contract is deployed, aka Sepolia.
+* `rlnRelayEthContractAddress=0xCB33Aa5B38d79E3D9Fa8B10afF38AA201399a7e3`: Network address where RLN memberships are stored.
+* `staked_fund=0`: In other words, the Waku Network does not use RLN staking. Registering a membership just requires to pay gas.
+* `MAX_MESSAGE_LIMIT=100`: Maximum amount of messages allowed per epoch for any membership. Enforced in the contract.
+* `max_epoch_gap=20`: Maximum allowed gap in seconds into the past or future compared to the validator's clock.
+
+Nodes MUST _reject_ messages not respecting any of these parameters.
+Nodes SHOULD use Network Time Protocol (NTP) to synchronize their own clocks,
 thereby ensuring valid timestamps for proof generation and validation.
-
-
-### Memberships
-
-Each publisher to the Waku Network SHOULD register an RLN membership
-with one of the RLN storage contracts
-moderated in the Sepolia registry contract with address [0xF1935b338321013f11068abCafC548A7B0db732C](https://sepolia.etherscan.io/address/0xF1935b338321013f11068abCafC548A7B0db732C#code).
-Initial memberships are registered in the Sepolia RLN storage contract with address [0x58322513A35a8f747AF5A385bA14C2AbE602AA59](https://sepolia.etherscan.io/address/0x58322513A35a8f747AF5A385bA14C2AbE602AA59#code).
-RLN membership setup and registration MUST follow [17/WAKU2-RLN-RELAY](../17/rln-relay.md/#setup-and-registration),
-with the `staked_fund` set to `0`.
-In other words, the Waku Network does not use RLN staking. 
+Publishers to the Waku Network SHOULD register an RLN membership.
 
 ### RLN Proofs
 
 Each RLN member MUST generate and attach an RLN proof to every published message
-as described in [17/WAKU2-RLN-RELAY](../17/rln-relay.md/#publishing).
+as described in [17/WAKU2-RLN-RELAY](../17/rln-relay.md/#publishing) and [RLN-V2](https://github.com/vacp2p/rfc-index/blob/a5b24ac0a27da361312260f9da372a0e6e812212/vac/raw/rln-v2.md).
 Slashing is not implemented for the Waku Network.
 Instead, validators will penalise peers forwarding messages exceeding the rate limit
 as specified for [the rate-limiting validation mechanism](#rate-limit-exceeded).
@@ -263,16 +257,16 @@ the relay node MUST _reject_ the message.
 
 If a message contains an RLN proof
 and the zero-knowledge proof is invalid
-according to the verification process described in [32/RLN-V1](../../../../vac/32/rln-v1.md),
+according to the verification process described in [RLN-V2](https://github.com/vacp2p/rfc-index/blob/a5b24ac0a27da361312260f9da372a0e6e812212/vac/raw/rln-v2.md),
 the relay node MUST _ignore_ the message.
 
 #### Rate limit exceeded
 
 If a message contains an RLN proof
 and the relay node detects double signaling
-according to the verification process described in [32/RLN-V1](../../../../vac/32/rln-v1.md),
+according to the verification process described in [RLN-V2](https://github.com/vacp2p/rfc-index/blob/a5b24ac0a27da361312260f9da372a0e6e812212/vac/raw/rln-v2.md),
 the relay node MUST _reject_ the message
-for violating the agreed rate limit of `1` message every `1` second.
+for violating the agreed rate limit of `rlnRelayUserMessageLimit` messages every `rlnEpochSizeSec` second.
 This SHOULD trigger a penalty against the transmitting peer.
 
 ## Autosharding
@@ -314,7 +308,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [19/WAKU2-LIGHTPUSH](../19/lightpush.md)
 * [34/WAKU2-PEER-EXCHANGE](../../core/peer-exchange.md)
 * [32/RLN-V1](../../../../vac/32/rln-v1.md)
+* [RLN-V2](https://github.com/vacp2p/rfc-index/blob/a5b24ac0a27da361312260f9da372a0e6e812212/vac/raw/rln-v2.md)
 * [14/WAKU2-MESSAGE](../14/message.md)
 * [gossipsub v1.1 validation](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators)
 * [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md/)
-* 
+* [The Waku Network Config](https://github.com/waku-org/nwaku/blob/master/waku/factory/networks_config.nim#L31)