Update slot-dispersal.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

@@ -17,10 +17,16 @@ jobs:
         uses: actions/checkout@v2
       
       - name: Get changed files
+        continue-on-error: true
         run: |
-          echo "CHANGED_FILES=$(gh pr diff ${{ github.event.number }} --name-only | grep '\.md$' | xargs -I {} echo "{}")" >> $GITHUB_ENV
+          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}}
+          globs: ${{ env.CHANGED_FILES }}

.github/workflows/website-sync.yml

@@ -32,19 +32,10 @@ jobs:
           for file in ${{ steps.changed_files.outputs.files }}; do
             cp --parents "$file" rfc-website/
           done
-      
-      - name: Add frontmatter
-        run: |
-          for file in ${{ steps.changed_files.outputs.files }}; do
-            frontmatter=$(awk '/^---$/ {c++; next} c==2 {print; exit}' "$file")
-            sed -i "/^---$/ {n; a$frontmatter\n\n}" "$file"
-          done
 
       - name: Push changes to Website Repo
         run: |
           cd rfc-website
           git add .
           git commit -m "Sync website"
-          git push origin master
-        env:
-          GH_TOKEN: ${{ secrets.GH_TOKEN }}
+          git push origin main

codex/slot-dispersal.md

@@ -0,0 +1,85 @@
+---
+title: CODEX-SLOT-DISPERSAL
+name: Codex SLOT Dispersal
+status: raw
+tags: codex
+editor: 
+contributors:
+---
+
+## Abstract
+
+This specification describes a method used by the Codex network for node dispersal for filling slot request.
+To achieve a truely decentralized storage network, data being stored on mutlple nodes should be prioritized.
+
+## Motivation
+Client nodes benefit from resilient data storage when multiple nodes are storing their requested data.
+In a distbuted storage solution, 
+a storage marketplace allows storage providers the ability to announce storage availability and
+storage request to find hosting.
+High performance nodes may have an advantage over a majority of nodes participating in the marketplace as storage requests may always choose the high proformance nodes to store data.
+This creates a centralized scenario as only high performance nodes will participate 
+and be rewarded in the network. 
+
+The Codex network does not implement a first come, first serve method to avoid centralized behaviors.
+Instead, the Codex network encourages storage requests to allow only a select few storage providers to create a storage contracts with the client node requests.
+
+## Specification
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+Storage providers compete with one another to store data from storage request.
+Before a storage providers can download the data, 
+they MUST be selected to obtain a reseversation of a slot.
+
+The Codex network using Kademlia distance function to select eligible  storage providers per slot.
+This starts with a random source address hash contructed as:
+
+    hash(blockHash, requestId, slotIndex, reservationIndex)
+
+`blockHash`: 
+
+`requestId`:
+
+`slotIndex`:
+
+`reservationIndex`:
+
+The source address is used along with the storage provider's blockchain address to calculate the Kademlia distance.
+This is represented by:
+
+$$ XOR(A,A_0) $$
+
+
+The allowed distance over time $t_1$, can be defined as $2^{256} * F(t_1)$.
+When the storage provider's distance is greater than the allowed distance,
+the storage provider SHOULD be eligible to to obtain a slot reservation.
+- Note after eligiblity, the storage provider MUST provide token collateral and storage proofs to make change the state of a slot from a reserved state to a filled state, see [slots](https://github.com/vacp2p/rfc-index/blob/codex-marketplace/codex/marketplace.md#slots).
+
+### Filling Slot
+
+When the value of the allowed distance increases,
+more storage providers SHOULD be elgiblable to participate in reserving a slot.
+The Codex network allows a storage provider is allowed to fill a slot after calculating the storage provider's Kademlia distance is less than the allowed distance.
+The total value storage providers MUST obtain can be defined as:
+
+$$ XOR(A,A_0) < 2^{256} * F(t_1) $$
+
+Eligible storage providers represented below:
+
+                             start point
+                                  |           Kademlia distance
+            t=3    t=2    t=1     v
+      <------(------(------(------·------)------)------)------>
+                      ^                            ^
+                      |                            |
+                 this provider is               this provider is
+                  allowed at t=2                 allowed at t=3
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+1. [slots](https://github.com/vacp2p/rfc-index/blob/codex-marketplace/codex/marketplace.md#slots)
+
+

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

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

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