Chore/mdbook updates (#237)

2026-01-07 23:04:09 -05:00 · 2025-12-22 15:00:09 +02:00
parent d03e699084
commit b1a578393e
115 changed files with 3392 additions and 1864 deletions
--- a/.github/workflows/.markdownlint.json
+++ b/.github/workflows/.markdownlint.json
@@ -1,5 +1,6 @@
 {
        "MD013": false,
        "MD024": false,
-        "MD025": false
+        "MD025": false,
+        "MD033": false
 }
--- a/.github/workflows/markdown-lint.yml
+++ b/.github/workflows/markdown-lint.yml
@@ -2,9 +2,6 @@ name: markdown-linting

 on:

-  push:
-    branches: 
-      - '**'
  pull_request:
    branches: 
      - '**'
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+book
--- a/4
+++ b/4
@@ -28,7 +28,7 @@ pipeline {
  stages {
    stage('Build') {
      steps { script {
-        nix.develop('mdbook build')
+        nix.develop('python scripts/gen_rfc_index.py && python scripts/gen_history.py && mdbook build')
        jenkins.genBuildMetaJSON('book/build.json')
      } }
    }
@@ -56,4 +56,4 @@ pipeline {

 def isMainBranch() { GIT_BRANCH ==~ /.*main/ }
 def deployBranch() { isMainBranch() ? 'deploy-master' : 'deploy-develop' }
-def deployDomain() { isMainBranch() ? 'rfc.vac.dev' : 'dev-rfc.vac.dev' }
+def deployDomain() { isMainBranch() ? 'rfc.vac.dev' : 'dev-rfc.vac.dev' }
--- a/book.toml
+++ b/book.toml
@@ -2,11 +2,10 @@
 title = "Vac RFC"
 authors = ["Jakub Sokołowski"]
 language = "en"
-multilingual = false
 src = "docs"

 [output.html]
 default-theme = "ayu"
 additional-css = ["custom.css"]
+additional-js = ["scripts/rfc-index.js"]
 git-repository-url = "https://github.com/vacp2p/rfc-index"
-git-branch = "main"
--- a/custom.css
+++ b/custom.css
@@ -1,3 +1,313 @@
 :root {
-    --content-max-width: 60em;
+    --content-max-width: 68em;
+}
+
+body {
+    background: var(--bg);
+    color: var(--fg);
+    font-family: "Source Serif Pro", "Iowan Old Style", "Palatino Linotype", "Book Antiqua", Georgia, serif;
+    line-height: 1.6;
+    letter-spacing: 0.01em;
+}
+
+code, pre, .hljs {
+    font-family: "SFMono-Regular", Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace;
+    font-size: 0.95em;
+}
+
+a {
+    color: var(--links);
+}
+
+a:hover {
+    color: var(--links);
+    opacity: 0.85;
+}
+
+.page {
+    background: var(--bg);
+    box-shadow: none;
+    border: 1px solid var(--table-border-color);
+}
+
+.menu-bar {
+    background: var(--bg);
+    box-shadow: none;
+    border-bottom: 1px solid var(--table-border-color);
+    min-height: 52px;
+}
+
+.menu-title {
+    font-weight: 600;
+    color: var(--fg);
+}
+
+.icon-button {
+    box-shadow: none;
+    border: 1px solid transparent;
+}
+
+#sidebar {
+    background: var(--sidebar-bg);
+    border-right: 1px solid var(--sidebar-spacer);
+    box-shadow: none;
+}
+
+#sidebar a {
+    color: var(--sidebar-fg);
+}
+
+#sidebar .chapter-item > a strong {
+    color: var(--sidebar-active);
+}
+
+#sidebar .part-title {
+    color: var(--sidebar-non-existant);
+    font-weight: 600;
+    letter-spacing: 0.02em;
+}
+
+main h1, main h2, main h3, main h4 {
+    font-family: "Source Serif Pro", "Iowan Old Style", "Palatino Linotype", "Book Antiqua", Georgia, serif;
+    color: var(--fg);
+    font-weight: 600;
+    margin-top: 1.2em;
+    margin-bottom: 0.6em;
+}
+
+.rfc-meta {
+    margin: 1rem 0 1.5rem 0;
+    padding: 0.75rem 1rem;
+    border: 1px solid var(--table-border-color);
+    background: var(--bg);
+}
+
+.rfc-meta table {
+    margin: 0;
+    border: none;
+}
+
+.rfc-meta th,
+.rfc-meta td {
+    border: none;
+    padding: 0.2rem 0.4rem 0.2rem 0;
+    text-align: left;
+    vertical-align: top;
+}
+
+.rfc-meta th {
+    width: 10rem;
+    color: var(--sidebar-fg);
+    font-weight: 600;
+}
+
+main p, main li {
+    color: var(--fg);
+}
+
+main blockquote {
+    border-left: 3px solid var(--quote-border);
+    color: var(--fg);
+    background: var(--quote-bg);
+}
+
+table {
+    border: 1px solid var(--table-border-color);
+    border-collapse: collapse;
+    width: 100%;
+}
+
+th, td {
+    border: 1px solid var(--table-border-color);
+    padding: 0.5em 0.75em;
+}
+
+thead {
+    background: var(--table-header-bg);
+}
+
+.content {
+    padding: 1.5rem 2rem 3rem 2rem;
+}
+
+.nav-chapters, .nav-wrapper {
+    box-shadow: none;
+}
+
+/* Landing layout */
+.landing-hero {
+    margin-bottom: 1.5rem;
+    padding: 1.25rem 1.5rem;
+    background: var(--bg);
+    border: 1px solid var(--table-border-color);
+}
+
+.landing-hero p {
+    margin: 0.3rem 0 0;
+    color: var(--sidebar-fg);
+}
+
+.filter-row {
+    display: flex;
+    flex-wrap: wrap;
+    gap: 0.5rem;
+    align-items: center;
+    margin-bottom: 0.75rem;
+}
+
+.filter-row input[type="search"] {
+    padding: 0.5rem 0.65rem;
+    border: 1px solid var(--searchbar-border-color);
+    border-radius: 4px;
+    min-width: 240px;
+    background: var(--searchbar-bg);
+    color: var(--searchbar-fg);
+}
+
+.chips {
+    display: flex;
+    gap: 0.5rem;
+    flex-wrap: wrap;
+}
+
+.chip {
+    display: inline-flex;
+    align-items: center;
+    gap: 0.4rem;
+    padding: 0.35rem 0.6rem;
+    border: 1px solid var(--table-border-color);
+    border-radius: 999px;
+    background: var(--theme-hover);
+    color: var(--fg);
+    cursor: pointer;
+    font-size: 0.95em;
+}
+
+.chip.active {
+    background: var(--theme-hover);
+    border-color: var(--sidebar-active);
+    color: var(--sidebar-active);
+    font-weight: 600;
+}
+
+.quick-links {
+    display: flex;
+    gap: 0.5rem;
+    flex-wrap: wrap;
+    margin: 0.5rem 0 1rem 0;
+}
+
+.quick-links a {
+    border: 1px solid var(--table-border-color);
+    padding: 0.35rem 0.65rem;
+    border-radius: 4px;
+    background: var(--bg);
+    text-decoration: none;
+    color: var(--fg);
+}
+
+.quick-links a:hover {
+    border-color: var(--sidebar-active);
+    color: var(--links);
+}
+
+.rfc-table {
+    width: 100%;
+    border-collapse: collapse;
+    margin-top: 0.75rem;
+}
+
+.rfc-table th, .rfc-table td {
+    border: 1px solid var(--table-border-color);
+    padding: 0.45rem 0.6rem;
+}
+
+.rfc-table thead {
+    background: var(--table-header-bg);
+}
+
+.rfc-table tbody tr:hover {
+    background: var(--theme-hover);
+}
+
+.badge {
+    display: inline-block;
+    padding: 0.15rem 0.45rem;
+    border-radius: 4px;
+    font-size: 0.85em;
+    border: 1px solid var(--table-border-color);
+    background: var(--table-alternate-bg);
+    color: var(--fg);
+}
+
+
+/* Landing polish */
+main h1 {
+    text-align: left;
+}
+
+.results-row {
+    display: flex;
+    justify-content: space-between;
+    align-items: baseline;
+    gap: 1rem;
+    margin: 0.5rem 0 0.75rem 0;
+    color: var(--sidebar-fg);
+    font-size: 0.95em;
+}
+
+.results-count {
+    color: var(--fg);
+    font-weight: 600;
+}
+
+.results-hint {
+    color: var(--sidebar-fg);
+    font-size: 0.9em;
+}
+
+.table-wrap {
+    overflow-x: auto;
+    border: 1px solid var(--table-border-color);
+    border-radius: 6px;
+    background: var(--bg);
+}
+
+.table-wrap .rfc-table {
+    margin: 0;
+    border: none;
+}
+
+.rfc-table tbody tr:nth-child(even) {
+    background: var(--table-alternate-bg);
+}
+
+.rfc-table th[data-sort] {
+    cursor: pointer;
+    user-select: none;
+}
+
+.rfc-table th.sorted {
+    color: var(--links);
+}
+
+.rfc-table td:first-child a {
+    word-break: break-word;
+}
+
+.noscript-note {
+    margin-top: 0.75rem;
+    color: var(--sidebar-fg);
+}
+
+@media (max-width: 900px) {
+    .results-row {
+        flex-direction: column;
+        align-items: flex-start;
+    }
+
+    .filter-row input[type="search"] {
+        width: 100%;
+        min-width: 0;
+    }
 }
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,47 +1,46 @@
-# Vac Request For Comments(RFC)
+# Vac RFC Index

-*NOTE*: This repo is WIP. We are currently restructuring the RFC process.
+An IETF-style index of Vac-managed RFCs across Waku, Nomos, Codex, and Status. Use the filters below to jump straight to a specification.

-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,
-[Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments),
-process within this repository.
+<div class="landing-hero">
+  <div class="filter-row">
+    <input id="rfc-search" type="search" placeholder="Search by number, title, status, project..." aria-label="Search RFCs">
+    <div class="chips" id="status-chips">
+      <span class="chip active" data-status="all" data-label="All">All</span>
+      <span class="chip" data-status="stable" data-label="Stable">Stable</span>
+      <span class="chip" data-status="draft" data-label="Draft">Draft</span>
+      <span class="chip" data-status="raw" data-label="Raw">Raw</span>
+      <span class="chip" data-status="deprecated" data-label="Deprecated">Deprecated</span>
+      <span class="chip" data-status="deleted" data-label="Deleted">Deleted</span>
+    </div>
+  </div>
+  <div class="filter-row">
+    <div class="chips" id="project-chips">
+      <span class="chip active" data-project="all" data-label="All projects">All projects</span>
+      <span class="chip" data-project="vac" data-label="Vac">Vac</span>
+      <span class="chip" data-project="waku" data-label="Waku">Waku</span>
+      <span class="chip" data-project="status" data-label="Status">Status</span>
+      <span class="chip" data-project="nomos" data-label="Nomos">Nomos</span>
+      <span class="chip" data-project="codex" data-label="Codex">Codex</span>
+    </div>
+  </div>
+  <div class="quick-links">
+    <a href="./vac/1/coss.html">1/COSS (Process)</a>
+    <a href="./vac/README.html">Vac index</a>
+    <a href="./waku/README.html">Waku index</a>
+    <a href="./status/README.html">Status index</a>
+    <a href="./nomos/README.html">Nomos index</a>
+    <a href="./codex/README.html">Codex index</a>
+  </div>
+</div>

-## New RFC Process
+<div class="results-row">
+  <div id="results-count" class="results-count">Loading RFC index...</div>
+  <div class="results-hint">Click a column to sort</div>
+</div>

-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.
+<div id="rfc-table-container" class="table-wrap"></div>

-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](./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](none)
- [Nomos Raw Specifications](https://github.com/logos-co/nomos-specs)
+<noscript>
+  <p class="noscript-note">JavaScript is required to load the RFC index table.</p>
+</noscript>
--- a/docs/SUMMARY.md
+++ b/docs/SUMMARY.md
@@ -2,126 +2,115 @@

 [Introduction](README.md)

---
+- [Vac](vac/README.md)
+  - [1/COSS](vac/1/coss.md)
+  - [2/MVDS](vac/2/mvds.md)
+  - [3/Remote Log](vac/3/remote-log.md)
+  - [4/MVDS Meta](vac/4/mvds-meta.md)
+  - [25/Libp2p DNS Discovery](vac/25/libp2p-dns-discovery.md)
+  - [32/RLN-V1](vac/32/rln-v1.md)
+  - [Raw](vac/raw/README.md)
+    - [Consensus Hashgraphlike](vac/raw/consensus-hashgraphlike.md)
+    - [Decentralized Messaging Ethereum](vac/raw/decentralized-messaging-ethereum.md)
+    - [ETH MLS Offchain](vac/raw/eth-mls-offchain.md)
+    - [ETH MLS Onchain](vac/raw/eth-mls-onchain.md)
+    - [ETH SecPM](vac/raw/deleted/eth-secpm.md)
+    - [Gossipsub Tor Push](vac/raw/gossipsub-tor-push.md)
+    - [Logos Capability Discovery](vac/raw/logos-capability-discovery.md)
+    - [Mix](vac/raw/mix.md)
+    - [Noise X3DH Double Ratchet](vac/raw/noise-x3dh-double-ratchet.md)
+    - [RLN Interep Spec](vac/raw/rln-interep-spec.md)
+    - [RLN Stealth Commitments](vac/raw/rln-stealth-commitments.md)
+    - [RLN-V2](vac/raw/rln-v2.md)
+    - [SDS](vac/raw/sds.md)
+  - [Template](vac/template.md)

-# Vac
+- [Waku](waku/README.md)
+  - [Standards - Core](waku/standards/core/README.md)
+    - [10/Waku2](waku/standards/core/10/waku2.md)
+    - [11/Relay](waku/standards/core/11/relay.md)
+    - [12/Filter](waku/standards/core/12/filter.md)
+    - [13/Store](waku/standards/core/13/store.md)
+    - [14/Message](waku/standards/core/14/message.md)
+    - [15/Bridge](waku/standards/core/15/bridge.md)
+    - [17/RLN Relay](waku/standards/core/17/rln-relay.md)
+    - [19/Lightpush](waku/standards/core/19/lightpush.md)
+    - [31/ENR](waku/standards/core/31/enr.md)
+    - [33/Discv5](waku/standards/core/33/discv5.md)
+    - [34/Peer Exchange](waku/standards/core/34/peer-exchange.md)
+    - [36/Bindings API](waku/standards/core/36/bindings-api.md)
+    - [64/Network](waku/standards/core/64/network.md)
+    - [66/Metadata](waku/standards/core/66/metadata.md)
+  - [Standards - Application](waku/standards/application/README.md)
+    - [20/Toy ETH PM](waku/standards/application/20/toy-eth-pm.md)
+    - [26/Payload](waku/standards/application/26/payload.md)
+    - [53/X3DH](waku/standards/application/53/x3dh.md)
+    - [54/X3DH Sessions](waku/standards/application/54/x3dh-sessions.md)
+  - [Standards - Legacy](waku/standards/legacy/README.md)
+    - [6/Waku1](waku/standards/legacy/6/waku1.md)
+    - [7/Data](waku/standards/legacy/7/data.md)
+    - [8/Mail](waku/standards/legacy/8/mail.md)
+    - [9/RPC](waku/standards/legacy/9/rpc.md)
+  - [Informational](waku/informational/README.md)
+    - [22/Toy Chat](waku/informational/22/toy-chat.md)
+    - [23/Topics](waku/informational/23/topics.md)
+    - [27/Peers](waku/informational/27/peers.md)
+    - [29/Config](waku/informational/29/config.md)
+    - [30/Adaptive Nodes](waku/informational/30/adaptive-nodes.md)
+  - [Deprecated](waku/deprecated/README.md)
+    - [5/Waku0](waku/deprecated/5/waku0.md)
+    - [16/RPC](waku/deprecated/16/rpc.md)
+    - [18/Swap](waku/deprecated/18/swap.md)
+    - [Fault Tolerant Store](waku/deprecated/fault-tolerant-store.md)

- [1/COSS](vac/1/coss.md)
- [2/MVDS](vac/2/mvds.md)
- [3/Remote Log](vac/3/remote-log.md)
- [4/MVDS Meta](vac/4/mvds-meta.md)
- [25/Libp2p DNS Discovery](vac/25/libp2p-dns-discovery.md)
- [32/RLN-V1](vac/32/rln-v1.md)
- [Raw](vac/raw/README.md)
-  - [Consensus Hashgraphlike](vac/raw/consensus-hashgraphlike.md)
-  - [Decentralized Messaging Ethereum](vac/raw/decentralized-messaging-ethereum.md)
-  - [ETH MLS Offchain](vac/raw/eth-mls-offchain.md)
-  - [ETH MLS Onchain](vac/raw/eth-mls-onchain.md)
-  - [ETH SecPM](vac/raw/deleted/eth-secpm.md)
-  - [Gossipsub Tor Push](vac/raw/gossipsub-tor-push.md)
-  - [Logos Capability Discovery](vac/raw/logos-capability-discovery.md)
-  - [Mix](vac/raw/mix.md)
-  - [Noise X3DH Double Ratchet](vac/raw/noise-x3dh-double-ratchet.md)
-  - [RLN Interep Spec](vac/raw/rln-interep-spec.md)
-  - [RLN Stealth Commitments](vac/raw/rln-stealth-commitments.md)
-  - [RLN-V2](vac/raw/rln-v2.md)
-  - [SDS](vac/raw/sds.md)
- [Template](vac/template.md)
+- [Nomos](nomos/README.md)
+  - [Raw](nomos/raw/README.md)
+    - [NomosDA Encoding](nomos/raw/nomosda-encoding.md)
+    - [NomosDA Network](nomos/raw/nomosda-network.md)
+    - [P2P Hardware Requirements](nomos/raw/p2p-hardware-requirements.md)
+    - [P2P NAT Solution](nomos/raw/p2p-nat-solution.md)
+    - [P2P Network Bootstrapping](nomos/raw/p2p-network-bootstrapping.md)
+    - [P2P Network](nomos/raw/p2p-network.md)
+    - [SDP](nomos/raw/sdp.md)
+  - [Deprecated](nomos/deprecated/README.md)
+    - [Claro](nomos/deprecated/claro.md)

-# Waku
+- [Codex](codex/README.md)
+  - [Raw](codex/raw/README.md)
+    - [Block Exchange](codex/raw/codex-block-exchange.md)
+    - [Marketplace](codex/raw/codex-marketplace.md)

- [Overview](waku/README.md)
- [Standards - Core](waku/standards/core/10/waku2.md)
-  - [10/Waku2](waku/standards/core/10/waku2.md)
-  - [11/Relay](waku/standards/core/11/relay.md)
-  - [12/Filter](waku/standards/core/12/filter.md)
-  - [13/Store](waku/standards/core/13/store.md)
-  - [14/Message](waku/standards/core/14/message.md)
-  - [15/Bridge](waku/standards/core/15/bridge.md)
-  - [17/RLN Relay](waku/standards/core/17/rln-relay.md)
-  - [19/Lightpush](waku/standards/core/19/lightpush.md)
-  - [31/ENR](waku/standards/core/31/enr.md)
-  - [33/Discv5](waku/standards/core/33/discv5.md)
-  - [34/Peer Exchange](waku/standards/core/34/peer-exchange.md)
-  - [36/Bindings API](waku/standards/core/36/bindings-api.md)
-  - [64/Network](waku/standards/core/64/network.md)
-  - [66/Metadata](waku/standards/core/66/metadata.md)
- [Standards - Application](waku/standards/application/20/toy-eth-pm.md)
-  - [20/Toy ETH PM](waku/standards/application/20/toy-eth-pm.md)
-  - [26/Payload](waku/standards/application/26/payload.md)
-  - [53/X3DH](waku/standards/application/53/x3dh.md)
-  - [54/X3DH Sessions](waku/standards/application/54/x3dh-sessions.md)
- [Standards - Legacy](waku/standards/legacy/6/waku1.md)
-  - [6/Waku1](waku/standards/legacy/6/waku1.md)
-  - [7/Data](waku/standards/legacy/7/data.md)
-  - [8/Mail](waku/standards/legacy/8/mail.md)
-  - [9/RPC](waku/standards/legacy/9/rpc.md)
- [Informational](waku/informational/22/toy-chat.md)
-  - [22/Toy Chat](waku/informational/22/toy-chat.md)
-  - [23/Topics](waku/informational/23/topics.md)
-  - [27/Peers](waku/informational/27/peers.md)
-  - [29/Config](waku/informational/29/config.md)
-  - [30/Adaptive Nodes](waku/informational/30/adaptive-nodes.md)
- [Deprecated](waku/deprecated/README.md)
-  - [5/Waku0](waku/deprecated/5/waku0.md)
-  - [16/RPC](waku/deprecated/16/rpc.md)
-  - [18/Swap](waku/deprecated/18/swap.md)
-  - [Fault Tolerant Store](waku/deprecated/fault-tolerant-store.md)
-
-# Nomos
-
- [Overview](nomos/README.md)
- [Raw](nomos/raw/nomosda-encoding.md)
-  - [NomosDA Encoding](nomos/raw/nomosda-encoding.md)
-  - [NomosDA Network](nomos/raw/nomosda-network.md)
-  - [P2P Hardware Requirements](nomos/raw/p2p-hardware-requirements.md)
-  - [P2P NAT Solution](nomos/raw/p2p-nat-solution.md)
-  - [P2P Network Bootstrapping](nomos/raw/p2p-network-bootstrapping.md)
-  - [P2P Network](nomos/raw/p2p-network.md)
-  - [SDP](nomos/raw/sdp.md)
- [Deprecated](nomos/deprecated/claro.md)
-  - [Claro](nomos/deprecated/claro.md)
-
-# Codex
-
- [Overview](codex/README.md)
- [Raw](codex/raw/codex-block-exchange.md)
-  - [Block Exchange](codex/raw/codex-block-exchange.md)
-  - [Marketplace](codex/raw/codex-marketplace.md)
-
-# Status
-
- [Overview](status/README.md)
- [24/Curation](status/24/curation.md)
- [28/Featuring](status/28/featuring.md)
- [55/1-to-1 Chat](status/55/1to1-chat.md)
- [56/Communities](status/56/communities.md)
- [61/Community History Service](status/61/community-history-service.md)
- [62/Payloads](status/62/payloads.md)
- [63/Keycard Usage](status/63/keycard-usage.md)
- [65/Account Address](status/65/account-address.md)
- [71/Push Notification Server](status/71/push-notification-server.md)
- [Raw](status/raw/simple-scaling.md)
-  - [Simple Scaling](status/raw/simple-scaling.md)
-  - [Status App Protocols](status/raw/status-app-protocols.md)
-  - [Status MVDS](status/raw/status-mvds.md)
-  - [URL Data](status/raw/url-data.md)
-  - [URL Scheme](status/raw/url-scheme.md)
- [Deprecated](status/deprecated/3rd-party.md)
-  - [3rd Party](status/deprecated/3rd-party.md)
-  - [Account](status/deprecated/account.md)
-  - [Client](status/deprecated/client.md)
-  - [Dapp Browser API Usage](status/deprecated/dapp-browser-API-usage.md)
-  - [EIPs](status/deprecated/eips.md)
-  - [Ethereum Usage](status/deprecated/ethereum-usage.md)
-  - [Group Chat](status/deprecated/group-chat.md)
-  - [IPFS Gateway for Sticker Pack](status/deprecated/IPFS-gateway-for-sticker-Pack.md)
-  - [Keycard Usage for Wallet and Chat Keys](status/deprecated/keycard-usage-for-wallet-and-chat-keys.md)
-  - [Notifications](status/deprecated/notifications.md)
-  - [Payloads](status/deprecated/payloads.md)
-  - [Push Notification Server](status/deprecated/push-notification-server.md)
-  - [Secure Transport](status/deprecated/secure-transport.md)
-  - [Waku Mailserver](status/deprecated/waku-mailserver.md)
-  - [Waku Usage](status/deprecated/waku-usage.md)
-  - [Whisper Mailserver](status/deprecated/whisper-mailserver.md)
-  - [Whisper Usage](status/deprecated/whisper-usage.md)
+- [Status](status/README.md)
+  - [24/Curation](status/24/curation.md)
+  - [28/Featuring](status/28/featuring.md)
+  - [55/1-to-1 Chat](status/55/1to1-chat.md)
+  - [56/Communities](status/56/communities.md)
+  - [61/Community History Service](status/61/community-history-service.md)
+  - [62/Payloads](status/62/payloads.md)
+  - [63/Keycard Usage](status/63/keycard-usage.md)
+  - [65/Account Address](status/65/account-address.md)
+  - [71/Push Notification Server](status/71/push-notification-server.md)
+  - [Raw](status/raw/README.md)
+    - [Simple Scaling](status/raw/simple-scaling.md)
+    - [Status App Protocols](status/raw/status-app-protocols.md)
+    - [Status MVDS](status/raw/status-mvds.md)
+    - [URL Data](status/raw/url-data.md)
+    - [URL Scheme](status/raw/url-scheme.md)
+  - [Deprecated](status/deprecated/README.md)
+    - [3rd Party](status/deprecated/3rd-party.md)
+    - [Account](status/deprecated/account.md)
+    - [Client](status/deprecated/client.md)
+    - [Dapp Browser API Usage](status/deprecated/dapp-browser-API-usage.md)
+    - [EIPs](status/deprecated/eips.md)
+    - [Ethereum Usage](status/deprecated/ethereum-usage.md)
+    - [Group Chat](status/deprecated/group-chat.md)
+    - [IPFS Gateway for Sticker Pack](status/deprecated/IPFS-gateway-for-sticker-Pack.md)
+    - [Keycard Usage for Wallet and Chat Keys](status/deprecated/keycard-usage-for-wallet-and-chat-keys.md)
+    - [Notifications](status/deprecated/notifications.md)
+    - [Payloads](status/deprecated/payloads.md)
+    - [Push Notification Server](status/deprecated/push-notification-server.md)
+    - [Secure Transport](status/deprecated/secure-transport.md)
+    - [Waku Mailserver](status/deprecated/waku-mailserver.md)
+    - [Waku Usage](status/deprecated/waku-usage.md)
+    - [Whisper Mailserver](status/deprecated/whisper-mailserver.md)
+    - [Whisper Usage](status/deprecated/whisper-usage.md)
--- a/docs/codex/raw/README.md
+++ b/docs/codex/raw/README.md
@@ -0,0 +1,3 @@
+# Codex Raw Specifications
+
+Early-stage Codex specifications collected before reaching draft status.
--- a/docs/codex/raw/codex-block-exchange.md
+++ b/docs/codex/raw/codex-block-exchange.md
@@ -1,14 +1,14 @@
---
-title: CODEX-BLOCK-EXCHANGE
-name: Codex Block Exchange Protocol
-status: raw
-category: Standards Track
-tags: codex, block-exchange, p2p, data-distribution
-editor: Codex Team
-contributors:
-  - Filip Dimitrijevic <filip@status.im>
---
+# CODEX-BLOCK-EXCHANGE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Codex Block Exchange Protocol</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Codex Team</td></tr>
+<tr><th>Contributors</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Specification Status

 This specification contains a mix of:
--- a/docs/codex/raw/codex-marketplace.md
+++ b/docs/codex/raw/codex-marketplace.md
@@ -1,19 +1,15 @@
---
-slug: codex-marketplace
-title: CODEX-MARKETPLACE
-name: Codex Storage Marketplace
-status: raw
-category: Standards Track
-tags: codex, storage, marketplace, smart-contract
-editor: Codex Team and Dmitriy Ryajov <dryajov@status.im>
-contributors:
-  - Mark Spanbroek <mark@codex.storage>
-  - Adam Uhlíř <adam@codex.storage>
-  - Eric Mastro <eric@codex.storage>
-  - Jimmy Debe <jimmy@status.im>
-  - Filip Dimitrijevic <filip@status.im>
---
+# CODEX-MARKETPLACE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Codex Storage Marketplace</td></tr>
+<tr><th>Slug</th><td>codex-marketplace</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Codex Team and Dmitriy Ryajov &lt;dryajov@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Mark Spanbroek &lt;mark@codex.storage&gt;<br>Adam Uhlíř &lt;adam@codex.storage&gt;<br>Eric Mastro &lt;eric@codex.storage&gt;<br>Jimmy Debe &lt;jimmy@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 Codex Marketplace and its interactions are defined by a smart contract deployed on an EVM-compatible blockchain. This specification describes these interactions for the various roles within the network.
--- a/docs/nomos/deprecated/README.md
+++ b/docs/nomos/deprecated/README.md
@@ -0,0 +1,3 @@
+# Nomos Deprecated Specifications
+
+Deprecated Nomos specifications kept for archival and reference purposes.
--- a/docs/nomos/deprecated/claro.md
+++ b/docs/nomos/deprecated/claro.md
@@ -1,19 +1,14 @@
---
-title: CONSENSUS-CLARO
-name: Claro Consensus Protocol
-status: deprecated
-category: Standards Track
-tags:
-  - logos/consensus
-editor: Corey Petty <corey@status.im>
-created: 01-JUL-2022
-revised: <2022-08-26 Fri 13:11Z>
-uri: <https://rdf.logos.co/protocol/Claro/1/0/0#<2022-08-26%20Fri$2013:11Z>
-contributors:
-  - Álvaro Castro-Castilla
-  - Mark Evenson
---
+# CONSENSUS-CLARO

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Claro Consensus Protocol</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Corey Petty &lt;corey@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Álvaro Castro-Castilla<br>Mark Evenson</td></tr>
+</table>
+</div>
 ## Abstract

 This document specifies Claro: a Byzantine, fault-tolerant, binary decision
--- a/docs/nomos/raw/README.md
+++ b/docs/nomos/raw/README.md
@@ -0,0 +1,3 @@
+# Nomos Raw Specifications
+
+Early-stage Nomos specifications that have not yet progressed beyond raw status.
--- a/docs/nomos/raw/nomosda-encoding.md
+++ b/docs/nomos/raw/nomosda-encoding.md
@@ -1,18 +1,13 @@
--- 
-title: NOMOSDA-ENCODING
-name: NomosDA Encoding Protocol 
-status: raw
-category: 
-tags: data-availability
-editor: Daniel Sanchez-Quiros <danielsq@status.im>
-contributors:
- Daniel Kashepava <danielkashepava@status.im>
- Álvaro Castro-Castilla <alvaro@status.im>
- Filip Dimitrijevic <filip@status.im>
- Thomas Lavaur <thomaslavaur@status.im>
- Mehmet Gonen <mehmet@status.im>
---
+# NOMOSDA-ENCODING

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>NomosDA Encoding Protocol</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Editor</th><td>Daniel Sanchez-Quiros &lt;danielsq@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Daniel Kashepava &lt;danielkashepava@status.im&gt;<br>Álvaro Castro-Castilla &lt;alvaro@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;<br>Thomas Lavaur &lt;thomaslavaur@status.im&gt;<br>Mehmet Gonen &lt;mehmet@status.im&gt;</td></tr>
+</table>
+</div>
 ## Introduction

 This document describes the encoding and verification processes of NomosDA, which is the data availability (DA) solution used by the Nomos blockchain. NomosDA provides an assurance that all data from Nomos blobs are accessible and verifiable by every network participant.
--- a/docs/nomos/raw/nomosda-network.md
+++ b/docs/nomos/raw/nomosda-network.md
@@ -1,17 +1,13 @@
---
-title: NOMOS-DA-NETWORK
-name: NomosDA Network
-status: raw
-category:
-tags: network, data-availability, da-nodes, executors, sampling
-editor: Daniel Sanchez Quiros <danielsq@status.im>
-contributors:
- Álvaro Castro-Castilla <alvaro@status.im>
- Daniel Kashepava <danielkashepava@status.im>
- Gusto Bacvinka <augustinas@status.im>
- Filip Dimitrijevic <filip@status.im>
---
+# NOMOS-DA-NETWORK

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>NomosDA Network</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Editor</th><td>Daniel Sanchez Quiros &lt;danielsq@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Álvaro Castro-Castilla &lt;alvaro@status.im&gt;<br>Daniel Kashepava &lt;danielkashepava@status.im&gt;<br>Gusto Bacvinka &lt;augustinas@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Introduction

 NomosDA is the scalability solution protocol for data availability within the Nomos network.
--- a/docs/nomos/raw/p2p-hardware-requirements.md
+++ b/docs/nomos/raw/p2p-hardware-requirements.md
@@ -1,14 +1,14 @@
---
-title: P2P-HARDWARE-REQUIREMENTS
-name: Nomos p2p Network Hardware Requirements Specification
-status: raw
-category: infrastructure
-tags: [hardware, requirements, nodes, validators, services]
-editor: Daniel Sanchez-Quiros <danielsq@status.im>
-contributors:
- Filip Dimitrijevic <filip@status.im>
---
+# P2P-HARDWARE-REQUIREMENTS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Nomos p2p Network Hardware Requirements Specification</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>infrastructure</td></tr>
+<tr><th>Editor</th><td>Daniel Sanchez-Quiros &lt;danielsq@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification defines the hardware requirements for running various types of Nomos blockchain nodes. Hardware needs vary significantly based on the node's role, from lightweight verification nodes to high-performance Zone Executors. The requirements are designed to support diverse participation levels while ensuring network security and performance.
--- a/docs/nomos/raw/p2p-nat-solution.md
+++ b/docs/nomos/raw/p2p-nat-solution.md
@@ -1,19 +1,14 @@
---
-title: P2P-NAT-SOLUTION
-name: Nomos P2P Network NAT Solution Specification
-status: raw
-category: networking
-tags: [nat, traversal, autonat, upnp, pcp, nat-pmp]
-editor: Antonio Antonino <antonio@status.im>
-contributors:
- Álvaro Castro-Castilla <alvaro@status.im>
- Daniel Sanchez-Quiros <danielsq@status.im>
- Petar Radovic <petar@status.im>
- Gusto Bacvinka <augustinas@status.im>
- Youngjoon Lee <youngjoon@status.im>
- Filip Dimitrijevic <filip@status.im>
---
+# P2P-NAT-SOLUTION

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Nomos P2P Network NAT Solution Specification</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>networking</td></tr>
+<tr><th>Editor</th><td>Antonio Antonino &lt;antonio@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Álvaro Castro-Castilla &lt;alvaro@status.im&gt;<br>Daniel Sanchez-Quiros &lt;danielsq@status.im&gt;<br>Petar Radovic &lt;petar@status.im&gt;<br>Gusto Bacvinka &lt;augustinas@status.im&gt;<br>Youngjoon Lee &lt;youngjoon@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification defines a comprehensive NAT (Network Address Translation) traversal solution for the Nomos P2P network. The solution enables nodes to automatically determine their NAT status and establish both outbound and inbound connections regardless of network configuration. The strategy combines [AutoNAT](https://github.com/libp2p/specs/blob/master/autonat/autonat-v2.md), dynamic port mapping protocols, and continuous verification to maximize public reachability while maintaining decentralized operation.
--- a/docs/nomos/raw/p2p-network-bootstrapping.md
+++ b/docs/nomos/raw/p2p-network-bootstrapping.md
@@ -1,19 +1,14 @@
---
-title: P2P-NETWORK-BOOTSTRAPPING
-name: Nomos P2P Network Bootstrapping Specification
-status: raw
-category: networking
-tags: [p2p, networking, bootstrapping, peer-discovery, libp2p]
-editor: Daniel Sanchez-Quiros <danielsq@status.im>
-contributors:
- Álvaro Castro-Castilla <alvaro@status.im>
- Petar Radovic <petar@status.im>
- Gusto Bacvinka <augustinas@status.im>
- Antonio Antonino <antonio@status.im>
- Youngjoon Lee <youngjoon@status.im>
- Filip Dimitrijevic <filip@status.im>
---
+# P2P-NETWORK-BOOTSTRAPPING

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Nomos P2P Network Bootstrapping Specification</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>networking</td></tr>
+<tr><th>Editor</th><td>Daniel Sanchez-Quiros &lt;danielsq@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Álvaro Castro-Castilla &lt;alvaro@status.im&gt;<br>Petar Radovic &lt;petar@status.im&gt;<br>Gusto Bacvinka &lt;augustinas@status.im&gt;<br>Antonio Antonino &lt;antonio@status.im&gt;<br>Youngjoon Lee &lt;youngjoon@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Introduction

 Nomos network bootstrapping is the process by which a new node discovers peers and synchronizes with the existing decentralized network. It ensures that a node can:
--- a/docs/nomos/raw/p2p-network.md
+++ b/docs/nomos/raw/p2p-network.md
@@ -1,14 +1,14 @@
---
-title: NOMOS-P2P-NETWORK
-name: Nomos P2P Network Specification
-status: draft
-category: networking
-tags: [p2p, networking, libp2p, kademlia, gossipsub, quic]
-editor: Daniel Sanchez-Quiros <danielsq@status.im>
-contributors:
- Filip Dimitrijevic <filip@status.im>
---
+# NOMOS-P2P-NETWORK

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Nomos P2P Network Specification</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>networking</td></tr>
+<tr><th>Editor</th><td>Daniel Sanchez-Quiros &lt;danielsq@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification defines the peer-to-peer (P2P) network layer for Nomos blockchain nodes. The network serves as the comprehensive communication infrastructure enabling transaction dissemination through mempool and block propagation. The specification leverages established libp2p protocols to ensure robust, scalable performance with low bandwidth requirements and minimal latency while maintaining accessibility for diverse hardware configurations and network environments.
--- a/docs/nomos/raw/sdp.md
+++ b/docs/nomos/raw/sdp.md
@@ -1,20 +1,13 @@
---
-title: NOMOS-SDP
-name: Nomos Service Declaration Protocol Specification
-status: raw
-category: 
-tags: participation, validators, declarations
-editor: Marcin Pawlowski <marcin@status.im>
-contributors:
- Mehmet <mehmet@status.im>
- Daniel Sanchez Quiros <danielsq@status.im>
- Álvaro Castro-Castilla <alvaro@status.im>
- Thomas Lavaur <thomaslavaur@status.im>
- Filip Dimitrijevic <filip@status.im>
- Gusto Bacvinka <augustinas@status.im>
- David Rusu <davidrusu@status.im>
---
+# NOMOS-SDP

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Nomos Service Declaration Protocol Specification</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Editor</th><td>Marcin Pawlowski &lt;marcin@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Mehmet &lt;mehmet@status.im&gt;<br>Daniel Sanchez Quiros &lt;danielsq@status.im&gt;<br>Álvaro Castro-Castilla &lt;alvaro@status.im&gt;<br>Thomas Lavaur &lt;thomaslavaur@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;<br>Gusto Bacvinka &lt;augustinas@status.im&gt;<br>David Rusu &lt;davidrusu@status.im&gt;</td></tr>
+</table>
+</div>
 ## Introduction

 This document defines a mechanism enabling validators to declare their participation in specific protocols that require a known and agreed-upon list of participants. Some examples of this are Data Availability and the Blend Network. We create a single repository of identifiers which is used to establish secure communication between validators and provide services. Before being admitted to the repository, the validator proves that it locked at least a minimum stake.
--- a/docs/rfc-index.json
+++ b/docs/rfc-index.json
@@ -0,0 +1,730 @@
+[
+  {
+    "project": "codex",
+    "slug": "Codex Block Exchange Protocol",
+    "title": "Codex Block Exchange Protocol",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "codex/raw/codex-block-exchange.html"
+  },
+  {
+    "project": "codex",
+    "slug": "codex-marketplace",
+    "title": "Codex Storage Marketplace",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "codex/raw/codex-marketplace.html"
+  },
+  {
+    "project": "nomos",
+    "slug": "Claro Consensus Protocol",
+    "title": "Claro Consensus Protocol",
+    "status": "deprecated",
+    "category": "Standards Track",
+    "path": "nomos/deprecated/claro.html"
+  },
+  {
+    "project": "nomos",
+    "slug": "Nomos P2P Network Bootstrapping Specification",
+    "title": "Nomos P2P Network Bootstrapping Specification",
+    "status": "raw",
+    "category": "networking",
+    "path": "nomos/raw/p2p-network-bootstrapping.html"
+  },
+  {
+    "project": "nomos",
+    "slug": "Nomos P2P Network NAT Solution Specification",
+    "title": "Nomos P2P Network NAT Solution Specification",
+    "status": "raw",
+    "category": "networking",
+    "path": "nomos/raw/p2p-nat-solution.html"
+  },
+  {
+    "project": "nomos",
+    "slug": "Nomos P2P Network Specification",
+    "title": "Nomos P2P Network Specification",
+    "status": "draft",
+    "category": "networking",
+    "path": "nomos/raw/p2p-network.html"
+  },
+  {
+    "project": "nomos",
+    "slug": "Nomos Service Declaration Protocol Specification",
+    "title": "Nomos Service Declaration Protocol Specification",
+    "status": "raw",
+    "category": "unspecified",
+    "path": "nomos/raw/sdp.html"
+  },
+  {
+    "project": "nomos",
+    "slug": "Nomos p2p Network Hardware Requirements Specification",
+    "title": "Nomos p2p Network Hardware Requirements Specification",
+    "status": "raw",
+    "category": "infrastructure",
+    "path": "nomos/raw/p2p-hardware-requirements.html"
+  },
+  {
+    "project": "nomos",
+    "slug": "NomosDA Encoding Protocol",
+    "title": "NomosDA Encoding Protocol",
+    "status": "raw",
+    "category": "unspecified",
+    "path": "nomos/raw/nomosda-encoding.html"
+  },
+  {
+    "project": "nomos",
+    "slug": "NomosDA Network",
+    "title": "NomosDA Network",
+    "status": "raw",
+    "category": "unspecified",
+    "path": "nomos/raw/nomosda-network.html"
+  },
+  {
+    "project": "status",
+    "slug": "24",
+    "title": "Status Community Directory Curation Voting using Waku v2",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "status/24/curation.html"
+  },
+  {
+    "project": "status",
+    "slug": "28",
+    "title": "Status community featuring using waku v2",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "status/28/featuring.html"
+  },
+  {
+    "project": "status",
+    "slug": "3rd party",
+    "title": "3rd party",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/3rd-party.html"
+  },
+  {
+    "project": "status",
+    "slug": "55",
+    "title": "Status 1-to-1 Chat",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "status/55/1to1-chat.html"
+  },
+  {
+    "project": "status",
+    "slug": "56",
+    "title": "Status Communities that run over Waku v2",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "status/56/communities.html"
+  },
+  {
+    "project": "status",
+    "slug": "61",
+    "title": "Status Community History Service",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "status/61/community-history-service.html"
+  },
+  {
+    "project": "status",
+    "slug": "62",
+    "title": "Status Message Payloads",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "status/62/payloads.html"
+  },
+  {
+    "project": "status",
+    "slug": "63",
+    "title": "Status Keycard Usage",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "status/63/keycard-usage.html"
+  },
+  {
+    "project": "status",
+    "slug": "65",
+    "title": "Status Account Address",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "status/65/account-address.html"
+  },
+  {
+    "project": "status",
+    "slug": "71",
+    "title": "Push Notification Server",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "status/71/push-notification-server.html"
+  },
+  {
+    "project": "status",
+    "slug": "Account",
+    "title": "Account",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/account.html"
+  },
+  {
+    "project": "status",
+    "slug": "Client",
+    "title": "Client",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/client.html"
+  },
+  {
+    "project": "status",
+    "slug": "Dapp browser API usage",
+    "title": "Dapp browser API usage",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/dapp-browser-API-usage.html"
+  },
+  {
+    "project": "status",
+    "slug": "EIPS",
+    "title": "EIPS",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/eips.html"
+  },
+  {
+    "project": "status",
+    "slug": "Group Chat",
+    "title": "Group Chat",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/group-chat.html"
+  },
+  {
+    "project": "status",
+    "slug": "IPFS gateway for Sticker Pack",
+    "title": "IPFS gateway for Sticker Pack",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/IPFS-gateway-for-sticker-Pack.html"
+  },
+  {
+    "project": "status",
+    "slug": "Keycard Usage for Wallet and Chat Keys",
+    "title": "Keycard Usage for Wallet and Chat Keys",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/keycard-usage-for-wallet-and-chat-keys.html"
+  },
+  {
+    "project": "status",
+    "slug": "MVDS Usage in Status",
+    "title": "MVDS Usage in Status",
+    "status": "raw",
+    "category": "Best Current Practice",
+    "path": "status/raw/status-mvds.html"
+  },
+  {
+    "project": "status",
+    "slug": "Notifications",
+    "title": "Notifications",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/notifications.html"
+  },
+  {
+    "project": "status",
+    "slug": "Payloads",
+    "title": "Payloads",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/payloads.html"
+  },
+  {
+    "project": "status",
+    "slug": "Push notification server",
+    "title": "Push notification server",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/push-notification-server.html"
+  },
+  {
+    "project": "status",
+    "slug": "Secure Transport",
+    "title": "Secure Transport",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/secure-transport.html"
+  },
+  {
+    "project": "status",
+    "slug": "Status Protocol Stack",
+    "title": "Status Protocol Stack",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "status/raw/status-app-protocols.html"
+  },
+  {
+    "project": "status",
+    "slug": "Status Simple Scaling",
+    "title": "Status Simple Scaling",
+    "status": "raw",
+    "category": "Informational",
+    "path": "status/raw/simple-scaling.html"
+  },
+  {
+    "project": "status",
+    "slug": "Status URL Data",
+    "title": "Status URL Data",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "status/raw/url-data.html"
+  },
+  {
+    "project": "status",
+    "slug": "Status URL Scheme",
+    "title": "Status URL Scheme",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "status/raw/url-scheme.html"
+  },
+  {
+    "project": "status",
+    "slug": "Status interactions with the Ethereum blockchain",
+    "title": "Status interactions with the Ethereum blockchain",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/ethereum-usage.html"
+  },
+  {
+    "project": "status",
+    "slug": "Waku Mailserver",
+    "title": "Waku Mailserver",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/waku-mailserver.html"
+  },
+  {
+    "project": "status",
+    "slug": "Waku Usage",
+    "title": "Waku Usage",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/waku-usage.html"
+  },
+  {
+    "project": "status",
+    "slug": "Whisper Usage",
+    "title": "Whisper Usage",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/whisper-usage.html"
+  },
+  {
+    "project": "status",
+    "slug": "Whisper mailserver",
+    "title": "Whisper mailserver",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "status/deprecated/whisper-mailserver.html"
+  },
+  {
+    "project": "vac",
+    "slug": "1",
+    "title": "Consensus-Oriented Specification System",
+    "status": "draft",
+    "category": "Best Current Practice",
+    "path": "vac/1/coss.html"
+  },
+  {
+    "project": "vac",
+    "slug": "2",
+    "title": "Minimum Viable Data Synchronization",
+    "status": "stable",
+    "category": "unspecified",
+    "path": "vac/2/mvds.html"
+  },
+  {
+    "project": "vac",
+    "slug": "25",
+    "title": "Libp2p Peer Discovery via DNS",
+    "status": "deleted",
+    "category": "unspecified",
+    "path": "vac/25/libp2p-dns-discovery.html"
+  },
+  {
+    "project": "vac",
+    "slug": "3",
+    "title": "Remote log specification",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "vac/3/remote-log.html"
+  },
+  {
+    "project": "vac",
+    "slug": "32",
+    "title": "Rate Limit Nullifier",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "vac/32/rln-v1.html"
+  },
+  {
+    "project": "vac",
+    "slug": "4",
+    "title": "MVDS Metadata Field",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "vac/4/mvds-meta.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Decentralized Key and Session Setup for Secure Messaging over Ethereum",
+    "title": "Decentralized Key and Session Setup for Secure Messaging over Ethereum",
+    "status": "raw",
+    "category": "informational",
+    "path": "vac/raw/decentralized-messaging-ethereum.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Gossipsub Tor Push",
+    "title": "Gossipsub Tor Push",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "vac/raw/gossipsub-tor-push.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Hashgraphlike Consensus Protocol",
+    "title": "Hashgraphlike Consensus Protocol",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "vac/raw/consensus-hashgraphlike.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Interep as group management for RLN",
+    "title": "Interep as group management for RLN",
+    "status": "raw",
+    "category": "unspecified",
+    "path": "vac/raw/rln-interep-spec.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Libp2p Mix Protocol",
+    "title": "Libp2p Mix Protocol",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "vac/raw/mix.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Logos Capability Discovery Protocol",
+    "title": "Logos Capability Discovery Protocol",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "vac/raw/logos-capability-discovery.html"
+  },
+  {
+    "project": "vac",
+    "slug": "RLN Stealth Commitment Usage",
+    "title": "RLN Stealth Commitment Usage",
+    "status": "unknown",
+    "category": "Standards Track",
+    "path": "vac/raw/rln-stealth-commitments.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Rate Limit Nullifier V2",
+    "title": "Rate Limit Nullifier V2",
+    "status": "raw",
+    "category": "unspecified",
+    "path": "vac/raw/rln-v2.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Scalable Data Sync protocol for distributed logs",
+    "title": "Scalable Data Sync protocol for distributed logs",
+    "status": "raw",
+    "category": "unspecified",
+    "path": "vac/raw/sds.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Secure 1-to-1 channel setup using X3DH and the double ratchet",
+    "title": "Secure 1-to-1 channel setup using X3DH and the double ratchet",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "vac/raw/noise-x3dh-double-ratchet.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Secure channel setup using Ethereum accounts",
+    "title": "Secure channel setup using Ethereum accounts",
+    "status": "deleted",
+    "category": "Standards Track",
+    "path": "vac/raw/deleted/eth-secpm.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Secure channel setup using decentralized MLS and Ethereum accounts",
+    "title": "Secure channel setup using decentralized MLS and Ethereum accounts",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "vac/raw/eth-mls-onchain.html"
+  },
+  {
+    "project": "vac",
+    "slug": "Secure channel setup using decentralized MLS and Ethereum accounts",
+    "title": "Secure channel setup using decentralized MLS and Ethereum accounts",
+    "status": "raw",
+    "category": "Standards Track",
+    "path": "vac/raw/eth-mls-offchain.html"
+  },
+  {
+    "project": "waku",
+    "slug": "10",
+    "title": "Waku v2",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/10/waku2.html"
+  },
+  {
+    "project": "waku",
+    "slug": "11",
+    "title": "Waku v2 Relay",
+    "status": "stable",
+    "category": "unspecified",
+    "path": "waku/standards/core/11/relay.html"
+  },
+  {
+    "project": "waku",
+    "slug": "12",
+    "title": "Waku v2 Filter",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/12/filter.html"
+  },
+  {
+    "project": "waku",
+    "slug": "13",
+    "title": "Waku Store Query",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/13/store.html"
+  },
+  {
+    "project": "waku",
+    "slug": "14",
+    "title": "Waku v2 Message",
+    "status": "stable",
+    "category": "Standards Track",
+    "path": "waku/standards/core/14/message.html"
+  },
+  {
+    "project": "waku",
+    "slug": "15",
+    "title": "Waku Bridge",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/15/bridge.html"
+  },
+  {
+    "project": "waku",
+    "slug": "16",
+    "title": "Waku v2 RPC API",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "waku/deprecated/16/rpc.html"
+  },
+  {
+    "project": "waku",
+    "slug": "17",
+    "title": "Waku v2 RLN Relay",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/17/rln-relay.html"
+  },
+  {
+    "project": "waku",
+    "slug": "18",
+    "title": "Waku SWAP Accounting",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "waku/deprecated/18/swap.html"
+  },
+  {
+    "project": "waku",
+    "slug": "19",
+    "title": "Waku v2 Light Push",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/19/lightpush.html"
+  },
+  {
+    "project": "waku",
+    "slug": "20",
+    "title": "Toy Ethereum Private Message",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/application/20/toy-eth-pm.html"
+  },
+  {
+    "project": "waku",
+    "slug": "21",
+    "title": "Waku v2 Fault-Tolerant Store",
+    "status": "deleted",
+    "category": "unspecified",
+    "path": "waku/deprecated/fault-tolerant-store.html"
+  },
+  {
+    "project": "waku",
+    "slug": "22",
+    "title": "Waku v2 Toy Chat",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/informational/22/toy-chat.html"
+  },
+  {
+    "project": "waku",
+    "slug": "23",
+    "title": "Waku v2 Topic Usage Recommendations",
+    "status": "draft",
+    "category": "Informational",
+    "path": "waku/informational/23/topics.html"
+  },
+  {
+    "project": "waku",
+    "slug": "26",
+    "title": "Waku Message Payload Encryption",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/application/26/payload.html"
+  },
+  {
+    "project": "waku",
+    "slug": "27",
+    "title": "Waku v2 Client Peer Management Recommendations",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/informational/27/peers.html"
+  },
+  {
+    "project": "waku",
+    "slug": "29",
+    "title": "Waku v2 Client Parameter Configuration Recommendations",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/informational/29/config.html"
+  },
+  {
+    "project": "waku",
+    "slug": "30",
+    "title": "Adaptive nodes",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/informational/30/adaptive-nodes.html"
+  },
+  {
+    "project": "waku",
+    "slug": "31",
+    "title": "Waku v2 usage of ENR",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/31/enr.html"
+  },
+  {
+    "project": "waku",
+    "slug": "33",
+    "title": "Waku v2 Discv5 Ambient Peer Discovery",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/33/discv5.html"
+  },
+  {
+    "project": "waku",
+    "slug": "34",
+    "title": "Waku2 Peer Exchange",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "waku/standards/core/34/peer-exchange.html"
+  },
+  {
+    "project": "waku",
+    "slug": "36",
+    "title": "Waku v2 C Bindings API",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/36/bindings-api.html"
+  },
+  {
+    "project": "waku",
+    "slug": "5",
+    "title": "Waku v0",
+    "status": "deprecated",
+    "category": "unspecified",
+    "path": "waku/deprecated/5/waku0.html"
+  },
+  {
+    "project": "waku",
+    "slug": "53",
+    "title": "X3DH usage for Waku payload encryption",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "waku/standards/application/53/x3dh.html"
+  },
+  {
+    "project": "waku",
+    "slug": "54",
+    "title": "Session management for Waku X3DH",
+    "status": "draft",
+    "category": "Standards Track",
+    "path": "waku/standards/application/54/x3dh-sessions.html"
+  },
+  {
+    "project": "waku",
+    "slug": "6",
+    "title": "Waku v1",
+    "status": "stable",
+    "category": "unspecified",
+    "path": "waku/standards/legacy/6/waku1.html"
+  },
+  {
+    "project": "waku",
+    "slug": "64",
+    "title": "Waku v2 Network",
+    "status": "draft",
+    "category": "Best Current Practice",
+    "path": "waku/standards/core/64/network.html"
+  },
+  {
+    "project": "waku",
+    "slug": "66",
+    "title": "Waku Metadata Protocol",
+    "status": "draft",
+    "category": "unspecified",
+    "path": "waku/standards/core/66/metadata.html"
+  },
+  {
+    "project": "waku",
+    "slug": "7",
+    "title": "Waku Envelope data field",
+    "status": "stable",
+    "category": "unspecified",
+    "path": "waku/standards/legacy/7/data.html"
+  },
+  {
+    "project": "waku",
+    "slug": "8",
+    "title": "Waku Mailserver",
+    "status": "stable",
+    "category": "unspecified",
+    "path": "waku/standards/legacy/8/mail.html"
+  },
+  {
+    "project": "waku",
+    "slug": "9",
+    "title": "Waku RPC API",
+    "status": "stable",
+    "category": "unspecified",
+    "path": "waku/standards/legacy/9/rpc.html"
+  }
+]
--- a/docs/status/24/curation.md
+++ b/docs/status/24/curation.md
@@ -1,13 +1,13 @@
---
-slug: 24
-title: 24/STATUS-CURATION
-name: Status Community Directory Curation Voting using Waku v2
-status: draft
-tags: waku-application
-description: A voting protocol for SNT holders to submit votes to a smart contract. Voting is immutable, which helps avoid sabotage from malicious peers.
-editor: Szymon Szlachtowicz <szymon.s@ethworks.io>
---
+# 24/STATUS-CURATION

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status Community Directory Curation Voting using Waku v2</td></tr>
+<tr><th>Slug</th><td>24</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Szymon Szlachtowicz &lt;szymon.s@ethworks.io&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification is a voting protocol for peers to submit votes to a smart contract.
--- a/docs/status/28/featuring.md
+++ b/docs/status/28/featuring.md
@@ -1,13 +1,13 @@
---
-slug: 28
-title: 28/STATUS-FEATURING
-name: Status community featuring using waku v2
-status: draft
-tags: waku-application
-description: To gain new members, current SNT holders can vote to feature an active Status community to the larger Status audience.
-editor: Szymon Szlachtowicz <szymon.s@ethworks.io>
---
+# 28/STATUS-FEATURING

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status community featuring using waku v2</td></tr>
+<tr><th>Slug</th><td>28</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Szymon Szlachtowicz &lt;szymon.s@ethworks.io&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes a voting method to feature different active Status Communities.
--- a/docs/status/55/1to1-chat.md
+++ b/docs/status/55/1to1-chat.md
@@ -1,20 +1,15 @@
---
-slug: 55
-title: 55/STATUS-1TO1-CHAT
-name: Status 1-to-1 Chat
-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 <p1ge0nh8er@proton.me>
-contributors:
- Andrea Piana <andreap@status.im>
- Pedro Pombeiro <pedro@status.im>
- Corey Petty <corey@status.im>
- Oskar Thorén <oskarth@titanproxy.com>
- Dean Eigenmann <dean@status.im>
---
+# 55/STATUS-1TO1-CHAT

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status 1-to-1 Chat</td></tr>
+<tr><th>Slug</th><td>55</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Piana &lt;andreap@status.im&gt;<br>Pedro Pombeiro &lt;pedro@status.im&gt;<br>Corey Petty &lt;corey@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Dean Eigenmann &lt;dean@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes how the Status 1-to-1 chat protocol is implemented
--- a/docs/status/56/communities.md
+++ b/docs/status/56/communities.md
@@ -1,17 +1,15 @@
---
-slug: 56
-title: 56/STATUS-COMMUNITIES
-name: Status Communities that run over Waku v2
-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 <p1ge0nh8er@proton.me>
-contributors:
- Andrea Piana <andreap@status.im>
- Prem Chaitanya Prathi <prem@waku.org>
---
+# 56/STATUS-COMMUNITIES

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status Communities that run over Waku v2</td></tr>
+<tr><th>Slug</th><td>56</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Piana &lt;andreap@status.im&gt;<br>Prem Chaitanya Prathi &lt;prem@waku.org&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document describes the design of Status Communities over Waku v2,
--- a/docs/status/61/community-history-service.md
+++ b/docs/status/61/community-history-service.md
@@ -1,16 +1,15 @@
---
-slug: 61
-title: 61/STATUS-Community-History-Service
-name: Status Community History Service
-status: draft
-category: Standards Track
-description: Explains how new members of a Status community can request historical messages from archive nodes.
-editor: r4bbit <r4bbit@status.im>
-contributors:
-  - Sanaz Taheri <sanaz@status.im>
-  - John Lea <john@status.im>
---
+# 61/STATUS-Community-History-Service

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status Community History Service</td></tr>
+<tr><th>Slug</th><td>61</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>r4bbit &lt;r4bbit@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Sanaz Taheri &lt;sanaz@status.im&gt;<br>John Lea &lt;john@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 Messages are stored permanently by store nodes
--- a/docs/status/62/payloads.md
+++ b/docs/status/62/payloads.md
@@ -1,17 +1,14 @@
---
-slug: 62
-title: 62/STATUS-PAYLOADS
-name: Status Message Payloads
-status: draft
-description: Describes the payload of each message in Status.
-editor: r4bbit <r4bbit@status.im>
-contributors: 
- Adam Babik <adam@status.im>
- Andrea Maria Piana <andreap@status.im>
- Oskar Thoren <oskarth@titanproxy.com>
- Samuel Hawksby-Robinson <samuel@status.im>
---
+# 62/STATUS-PAYLOADS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status Message Payloads</td></tr>
+<tr><th>Slug</th><td>62</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>r4bbit &lt;r4bbit@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Adam Babik &lt;adam@status.im&gt;<br>Andrea Maria Piana &lt;andreap@status.im&gt;<br>Oskar Thoren &lt;oskarth@titanproxy.com&gt;<br>Samuel Hawksby-Robinson &lt;samuel@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes how the payload of each message in Status looks
--- a/docs/status/63/keycard-usage.md
+++ b/docs/status/63/keycard-usage.md
@@ -1,15 +1,15 @@
---
-slug: 63
-title: 63/STATUS-Keycard-Usage
-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 <p1ge0nh8er@proton.me>
-contributors:
-  - Jimmy Debe <jimmy@status.im>
---
+# 63/STATUS-Keycard-Usage

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status Keycard Usage</td></tr>
+<tr><th>Slug</th><td>63</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>Jimmy Debe &lt;jimmy@status.im&gt;</td></tr>
+</table>
+</div>
 ## Terminology

 - **Account**: A valid
--- a/docs/status/65/account-address.md
+++ b/docs/status/65/account-address.md
@@ -1,17 +1,15 @@
---
-slug: 65
-title: 65/STATUS-ACCOUNT-ADDRESS
-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 <p1ge0nh8er@proton.me>
-contributors:
- Corey Petty <corey@status.im>
- Oskar Thorén <oskarth@titanproxy.com>
- Samuel Hawksby-Robinson <samuel@status.im>
---
+# 65/STATUS-ACCOUNT-ADDRESS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status Account Address</td></tr>
+<tr><th>Slug</th><td>65</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>Corey Petty &lt;corey@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Samuel Hawksby-Robinson &lt;samuel@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification details what a Status account address is and
--- a/docs/status/71/push-notification-server.md
+++ b/docs/status/71/push-notification-server.md
@@ -1,15 +1,15 @@
---
-slug: 71
-title: 71/STATUS-PUSH-NOTIFICATION-SERVER
-name: Push Notification Server
-status: draft
-category: Standards Track
-description: A set of methods to allow Status clients to use push notification services in mobile environments.
-editor: Jimmy Debe <jimmy@status.im>
-contributors: 
-  - Andrea Maria Piana <andreap@status.im>
---
+# 71/STATUS-PUSH-NOTIFICATION-SERVER

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Push Notification Server</td></tr>
+<tr><th>Slug</th><td>71</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Jimmy Debe &lt;jimmy@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Maria Piana &lt;andreap@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 A push notification server implementation for IOS devices and Android devices.
--- a/docs/status/deprecated/3rd-party.md
+++ b/docs/status/deprecated/3rd-party.md
@@ -1,13 +1,13 @@
---
-title: 3RD-PARTY
-name: 3rd party
-status: deprecated
-description: This specification discusses 3rd party APIs that Status relies on.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Volodymyr Kozieiev <volodymyr@status.im>
---
+# 3RD-PARTY

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>3rd party</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Volodymyr Kozieiev &lt;volodymyr@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification discusses 3rd party APIs that Status relies on.  
--- a/docs/status/deprecated/IPFS-gateway-for-sticker-Pack.md
+++ b/docs/status/deprecated/IPFS-gateway-for-sticker-Pack.md
@@ -1,13 +1,13 @@
---
-title: IPFS-gateway-for-Sticker-Pack
-name: IPFS gateway for Sticker Pack
-status: deprecated
-description: This specification describes how Status uses the IPFS gateway to store stickers. 
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Gheorghe Pinzaru <gheorghe@status.im>
---
+# IPFS-gateway-for-Sticker-Pack

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>IPFS gateway for Sticker Pack</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Gheorghe Pinzaru &lt;gheorghe@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes how Status uses the IPFS gateway  
--- a/docs/status/deprecated/README.md
+++ b/docs/status/deprecated/README.md
@@ -0,0 +1,3 @@
+# Status Deprecated Specifications
+
+Deprecated Status specifications maintained for archival purposes.
--- a/docs/status/deprecated/account.md
+++ b/docs/status/deprecated/account.md
@@ -1,15 +1,13 @@
---
-title: ACCOUNT
-name: Account
-status: deprecated
-description: This specification explains what a Status account is, and how a node establishes trust.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Corey Petty <corey@status.im>
-  - Oskar Thorén <oskar@status.im>
-  - Samuel Hawksby-Robinson <samuel@status.im>
---
+# ACCOUNT

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Account</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Corey Petty &lt;corey@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;<br>Samuel Hawksby-Robinson &lt;samuel@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification explains what a Status account is,  
--- a/docs/status/deprecated/client.md
+++ b/docs/status/deprecated/client.md
@@ -1,18 +1,13 @@
---
-title: CLIENT
-name: Client
-status: deprecated
-description: This specification describes how to write a Status client for communicating with other Status clients.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Adam Babik <adam@status.im>
-  - Andrea Maria Piana <andreap@status.im>
-  - Dean Eigenmann <dean@status.im>
-  - Corey Petty <corey@status.im>
-  - Oskar Thorén <oskar@status.im>
-  - Samuel Hawksby-Robinson <samuel@status.im>
---
+# CLIENT

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Client</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Adam Babik &lt;adam@status.im&gt;<br>Andrea Maria Piana &lt;andreap@status.im&gt;<br>Dean Eigenmann &lt;dean@status.im&gt;<br>Corey Petty &lt;corey@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;<br>Samuel Hawksby-Robinson &lt;samuel@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes how to write a Status client for communicating  
--- a/docs/status/deprecated/dapp-browser-API-usage.md
+++ b/docs/status/deprecated/dapp-browser-API-usage.md
@@ -1,12 +1,12 @@
---
-title: Dapp browser API usage
-name: Dapp browser API usage
-status: deprecated
-description: This document describes requirements that an application must fulfill in order to provide a proper environment for Dapps running inside a browser.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
---
+# Dapp browser API usage

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Dapp browser API usage</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document describes requirements that an application must fulfill in order to provide a proper environment for Dapps running inside a browser.
--- a/docs/status/deprecated/eips.md
+++ b/docs/status/deprecated/eips.md
@@ -1,13 +1,13 @@
---
-title: EIPS
-name: EIPS
-status: deprecated
-description: Status relation with the EIPs
-editor: Ricardo Guilherme Schmidt <ricardo3@status.im>
-contributors:
- 
---
+# EIPS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>EIPS</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Ricardo Guilherme Schmidt &lt;ricardo3@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>None</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes how Status relates with EIPs.
--- a/docs/status/deprecated/ethereum-usage.md
+++ b/docs/status/deprecated/ethereum-usage.md
@@ -1,13 +1,13 @@
---
-title: ETHEREUM-USAGE
-name: Status interactions with the Ethereum blockchain
-status: deprecated
-description: All interactions that the Status client has with the Ethereum blockchain.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-    - Andrea Maria Piana <andreap@status.im>
---
+# ETHEREUM-USAGE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status interactions with the Ethereum blockchain</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Maria Piana &lt;andreap@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification documents all the interactions that the Status client has
--- a/docs/status/deprecated/group-chat.md
+++ b/docs/status/deprecated/group-chat.md
@@ -1,13 +1,13 @@
---
-title: GROUP-CHAT
-name: Group Chat
-status: deprecated
-description: This document describes the group chat protocol used by the Status application.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Andrea Piana <andreap@status.im>
---
+# GROUP-CHAT

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Group Chat</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Piana &lt;andreap@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document describes the group chat protocol used by the Status application.
--- a/docs/status/deprecated/keycard-usage-for-wallet-and-chat-keys.md
+++ b/docs/status/deprecated/keycard-usage-for-wallet-and-chat-keys.md
@@ -1,13 +1,13 @@
---
-title: Keycard Usage for Wallet and Chat Keys
-name: Keycard Usage for Wallet and Chat Keys
-status: deprecated
-description: In this specification, we describe how Status communicates with Keycard to create, store and use multiaccount.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-   - Roman Volosovskyi <roman@status.im>
---
+# Keycard Usage for Wallet and Chat Keys

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Keycard Usage for Wallet and Chat Keys</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Roman Volosovskyi &lt;roman@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 In this specification, we describe how Status communicates with Keycard to create, store and use multiaccount.
--- a/docs/status/deprecated/notifications.md
+++ b/docs/status/deprecated/notifications.md
@@ -1,12 +1,13 @@
---
-title: NOTIFICATIONS
-name: Notifications
-status: deprecated
-description: A client should implement local notifications to offer notifications for any event in the app without the privacy cost and dependency on third party services.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Eric Dvorsak <eric@status.im>
---
+# NOTIFICATIONS
+
+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Notifications</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Eric Dvorsak &lt;eric@status.im&gt;</td></tr>
+</table>
+</div>

 ## Local Notifications

--- a/docs/status/deprecated/payloads.md
+++ b/docs/status/deprecated/payloads.md
@@ -1,15 +1,13 @@
---
-title: PAYLOADS
-name: Payloads
-status: deprecated
-description: Payload of messages in Status, regarding chat and chat-related use cases.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
- Adam Babik <adam@status.im>
- Andrea Maria Piana <andreap@status.im>
- Oskar Thorén <oskar@status.im>
---
+# PAYLOADS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Payloads</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Adam Babik &lt;adam@status.im&gt;<br>Andrea Maria Piana &lt;andreap@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes how the payload of each message in Status looks like.
--- a/docs/status/deprecated/push-notification-server.md
+++ b/docs/status/deprecated/push-notification-server.md
@@ -1,13 +1,13 @@
---
-title: PUSH-NOTIFICATION-SERVER
-name: Push notification server
-status: deprecated
-description: Status provides a set of Push notification services that can be used to achieve this functionality.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Andrea Maria Piana <andreap@status.im>
---
+# PUSH-NOTIFICATION-SERVER

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Push notification server</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Maria Piana &lt;andreap@status.im&gt;</td></tr>
+</table>
+</div>
 ## Reason

 Push notifications for iOS devices and some Android devices can only be implemented by relying on [APN service](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1) for iOS or [Firebase](https://firebase.google.com/).
--- a/docs/status/deprecated/secure-transport.md
+++ b/docs/status/deprecated/secure-transport.md
@@ -1,17 +1,13 @@
---
-title: SECURE-TRANSPORT
-name: Secure Transport
-status: deprecated
-description: This document describes how Status provides a secure channel between two peers, providing confidentiality, integrity, authenticity, and forward secrecy.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Andrea Maria Piana <andreap@status.im>
-  - Corey Petty <corey@status.im>
-  - Dean Eigenmann <dean@status.im>
-  - Oskar Thorén <oskar@status.im>
-  - Pedro Pombeiro <pedro@status.im>
---
+# SECURE-TRANSPORT

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Secure Transport</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Maria Piana &lt;andreap@status.im&gt;<br>Corey Petty &lt;corey@status.im&gt;<br>Dean Eigenmann &lt;dean@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;<br>Pedro Pombeiro &lt;pedro@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document describes how Status provides a secure channel between two peers,
--- a/docs/status/deprecated/waku-mailserver.md
+++ b/docs/status/deprecated/waku-mailserver.md
@@ -1,15 +1,13 @@
---
-title: WAKU-MAILSERVER
-name: Waku Mailserver
-status: deprecated
-description: Waku Mailserver is a specification that allows messages to be stored permanently and to allow the stored messages to be delivered to requesting client nodes, regardless if the messages are not available in the network due to the message TTL expiring.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Adam Babik <adam@status.im>
-  - Oskar Thorén <oskar@status.im>
-  - Samuel Hawksby-Robinson <samuel@status.im>
---
+# WAKU-MAILSERVER

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku Mailserver</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Adam Babik &lt;adam@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;<br>Samuel Hawksby-Robinson &lt;samuel@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 Being mostly offline is an intrinsic property of mobile clients.
--- a/docs/status/deprecated/waku-usage.md
+++ b/docs/status/deprecated/waku-usage.md
@@ -1,16 +1,13 @@
---
-title: WAKU-USAGE
-name: Waku Usage
-status: deprecated
-description: Status uses Waku to provide privacy-preserving routing and messaging on top of devP2P.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Adam Babik <adam@status.im>
-  - Corey Petty <corey@status.im>
-  - Oskar Thorén <oskar@status.im>
-  - Samuel Hawksby-Robinson <samuel@status.im>
---
+# WAKU-USAGE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku Usage</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Adam Babik &lt;adam@status.im&gt;<br>Corey Petty &lt;corey@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;<br>Samuel Hawksby-Robinson &lt;samuel@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 Status uses [Waku](/waku/standards/legacy/6/waku1.md) to provide privacy-preserving routing
--- a/docs/status/deprecated/whisper-mailserver.md
+++ b/docs/status/deprecated/whisper-mailserver.md
@@ -1,14 +1,13 @@
---
-title: WHISPER-MAILSERVER
-name: Whisper mailserver
-status: deprecated
-description: Whisper Mailserver is a Whisper extension that allows to store messages permanently and deliver them to the clients even though they are already not available in the network and expired.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Adam Babik <adam@status.im>
-  - Oskar Thorén <oskar@status.im>
---
+# WHISPER-MAILSERVER

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Whisper mailserver</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Adam Babik &lt;adam@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 Being mostly offline is an intrinsic property of mobile clients.
--- a/docs/status/deprecated/whisper-usage.md
+++ b/docs/status/deprecated/whisper-usage.md
@@ -1,16 +1,13 @@
---
-title: WHISPER-USAGE
-name: Whisper Usage
-status: deprecated
-description: Status uses Whisper to provide privacy-preserving routing and messaging on top of devP2P.
-editor: Filip Dimitrijevic <filip@status.im>
-contributors:
-  - Adam Babik <adam@status.im>
-  - Andrea Piana <andreap@status.im>
-  - Corey Petty <corey@status.im>
-  - Oskar Thorén <oskar@status.im>
---
+# WHISPER-USAGE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Whisper Usage</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Adam Babik &lt;adam@status.im&gt;<br>Andrea Piana &lt;andreap@status.im&gt;<br>Corey Petty &lt;corey@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 Status uses [Whisper](https://eips.ethereum.org/EIPS/eip-627) to provide
--- a/docs/status/raw/README.md
+++ b/docs/status/raw/README.md
@@ -0,0 +1,3 @@
+# Status Raw Specifications
+
+Early-stage Status specifications that precede draft or stable status.
--- a/docs/status/raw/simple-scaling.md
+++ b/docs/status/raw/simple-scaling.md
@@ -1,15 +1,14 @@
---
-title: STATUS-SIMPLE-SCALING
-name: Status Simple Scaling
-status: raw
-category: Informational
-tags: waku/application
-description: Describes how to scale Status Communities and Status 1-to-1 chats using Waku v2 protocol and components.
-editor: Daniel Kaiser <danielkaiser@status.im>
-contributors:
- Alvaro Revuelta <alrevuelta@status.im>
---
+# STATUS-SIMPLE-SCALING

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status Simple Scaling</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Informational</td></tr>
+<tr><th>Editor</th><td>Daniel Kaiser &lt;danielkaiser@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Alvaro Revuelta &lt;alrevuelta@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document describes how to scale
--- a/docs/status/raw/status-app-protocols.md
+++ b/docs/status/raw/status-app-protocols.md
@@ -1,16 +1,14 @@
---
-title: STATUS-PROTOCOLS
-name: Status Protocol Stack
-status: raw
-category: Standards Track
-description: Specifies the Status application protocol stack.
-editor: Hanno Cornelius <hanno@status.im>
-contributors: 
- Jimmy Debe <jimmy@status.im>
- Aaryamann Challani <p1ge0nh8er@proton.me>
-
---
+# STATUS-PROTOCOLS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status Protocol Stack</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Jimmy Debe &lt;jimmy@status.im&gt;<br>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes the Status Application protocol stack.
--- a/docs/status/raw/status-mvds.md
+++ b/docs/status/raw/status-mvds.md
@@ -1,13 +1,13 @@
---
-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:
---
+# STATUS-MVDS-USAGE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>MVDS Usage in Status</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Best Current Practice</td></tr>
+<tr><th>Editor</th><td>Kaichao Sun &lt;kaichao@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document lists the types of messages that are using [MVDS](/vac/2/mvds.md)
--- a/docs/status/raw/url-data.md
+++ b/docs/status/raw/url-data.md
@@ -1,14 +1,14 @@
---
-title: STATUS-URL-DATA
-name: Status URL Data
-status: raw
-category: Standards Track
-tags:
-editor: Felicio Mununga <felicio@status.im>
-contributors:
-  - Aaryamann Challani <aaryamann@status.im>
---
+# STATUS-URL-DATA

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status URL Data</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Felicio Mununga &lt;felicio@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Aaryamann Challani &lt;aaryamann@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document specifies serialization, compression, and
--- a/docs/status/raw/url-scheme.md
+++ b/docs/status/raw/url-scheme.md
@@ -1,13 +1,13 @@
---
-title: STATUS-URL-SCHEME
-name: Status URL Scheme
-status: raw
-category: Standards Track
-tags:
-editor: Felicio Mununga <felicio@status.im>
-contributors:
---
+# STATUS-URL-SCHEME

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Status URL Scheme</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Felicio Mununga &lt;felicio@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document describes URL scheme for previewing and
--- a/docs/vac/1/coss.md
+++ b/docs/vac/1/coss.md
@@ -1,20 +1,15 @@
---
-slug: 1
-title: 1/COSS
-name: Consensus-Oriented Specification System
-status: draft
-category: Best Current Practice
-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>
-  - Jimmy Debe <jimmy@status.im>
---
+# 1/COSS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Consensus-Oriented Specification System</td></tr>
+<tr><th>Slug</th><td>1</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Best Current Practice</td></tr>
+<tr><th>Editor</th><td>Daniel Kaiser &lt;danielkaiser@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Oskar Thoren &lt;oskarth@titanproxy.com&gt;<br>Pieter Hintjens &lt;ph@imatix.com&gt;<br>André Rebentisch &lt;andre@openstandards.de&gt;<br>Alberto Barrionuevo &lt;abarrio@opentia.es&gt;<br>Chris Puttick &lt;chris.puttick@thehumanjourney.net&gt;<br>Yurii Rashkovskii &lt;yrashk@gmail.com&gt;<br>Jimmy Debe &lt;jimmy@status.im&gt;</td></tr>
+</table>
+</div>
 This document describes a consensus-oriented specification system (COSS)
 for building interoperable technical specifications.
 COSS is based on a lightweight editorial process that
--- a/docs/vac/2/mvds.md
+++ b/docs/vac/2/mvds.md
@@ -1,16 +1,16 @@
---
-slug: 2
-title: 2/MVDS
-name: Minimum Viable Data Synchronization
-status: stable
-editor: Sanaz Taheri <sanaz@status.im>
-contributors:
-  - Dean Eigenmann <dean@status.im>
-  - Oskar Thorén <oskarth@titanproxy.com>
---
+# 2/MVDS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Minimum Viable Data Synchronization</td></tr>
+<tr><th>Slug</th><td>2</td></tr>
+<tr><th>Status</th><td>stable</td></tr>
+<tr><th>Editor</th><td>Sanaz Taheri &lt;sanaz@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Dean Eigenmann &lt;dean@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+</table>
+</div>
 In this specification, we describe a minimum viable protocol for
-data synchronization inspired by the Bramble Synchronization Protocol[^1].
+data synchronization inspired by the Bramble Synchronization Protocol ([BSP](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md)).
 This protocol is designed to ensure reliable messaging
 between peers across an unreliable peer-to-peer (P2P) network where
 they may be unreachable or unresponsive.
@@ -187,5 +187,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ## Footnotes

-[^1]: akwizgran et al. [BSP](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md). Briar.
 [^2]: <https://github.com/vacp2p/mvds>
--- a/docs/vac/25/libp2p-dns-discovery.md
+++ b/docs/vac/25/libp2p-dns-discovery.md
@@ -1,12 +1,13 @@
---
-slug: 25
-title: 25/LIBP2P-DNS-DISCOVERY
-name: Libp2p Peer Discovery via DNS
-status: deleted
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
---
+# 25/LIBP2P-DNS-DISCOVERY

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Libp2p Peer Discovery via DNS</td></tr>
+<tr><th>Slug</th><td>25</td></tr>
+<tr><th>Status</th><td>deleted</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+</table>
+</div>
 `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,
--- a/docs/vac/3/remote-log.md
+++ b/docs/vac/3/remote-log.md
@@ -1,13 +1,14 @@
---
-slug: 3
-title: 3/REMOTE-LOG
-name: Remote log specification
-status: draft
-editor: Oskar Thorén <oskarth@titanproxy.com>
-contributors:
-  - Dean Eigenmann <dean@status.im>
---
+# 3/REMOTE-LOG

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Remote log specification</td></tr>
+<tr><th>Slug</th><td>3</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+<tr><th>Contributors</th><td>Dean Eigenmann &lt;dean@status.im&gt;</td></tr>
+</table>
+</div>
 A remote log is a replication of a local log.
 This means a node can read data that originally came from a node that is offline.

--- a/docs/vac/32/rln-v1.md
+++ b/docs/vac/32/rln-v1.md
@@ -1,18 +1,14 @@
---
-slug: 32
-title: 32/RLN-V1
-name: Rate Limit Nullifier
-status: draft
-editor: Aaryamann Challani <p1ge0nh8er@proton.me>
-contributors:
- Barry Whitehat <barrywhitehat@protonmail.com>
- Sanaz Taheri <sanaz@status.im>
- Oskar Thorén <oskarth@titanproxy.com>
- Onur Kilic <onurkilic1004@gmail.com>
- Blagoj Dimovski <blagoj.dimovski@yandex.com>
- Rasul Ibragimov <curryrasul@gmail.com>
---
+# 32/RLN-V1

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Rate Limit Nullifier</td></tr>
+<tr><th>Slug</th><td>32</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>Barry Whitehat &lt;barrywhitehat@protonmail.com&gt;<br>Sanaz Taheri &lt;sanaz@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Onur Kilic &lt;onurkilic1004@gmail.com&gt;<br>Blagoj Dimovski &lt;blagoj.dimovski@yandex.com&gt;<br>Rasul Ibragimov &lt;curryrasul@gmail.com&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 The following specification covers the RLN construct
--- a/docs/vac/4/mvds-meta.md
+++ b/docs/vac/4/mvds-meta.md
@@ -1,15 +1,14 @@
---
-slug: 4
-title: 4/MVDS-META
-name: MVDS Metadata Field
-status: draft
-editor: Sanaz Taheri <sanaz@status.im>
-contributors:
-  - Dean Eigenmann <dean@status.im>
-  - Andrea Maria Piana <andreap@status.im>
-  - Oskar Thorén <oskarth@titanproxy.com>
---
+# 4/MVDS-META

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>MVDS Metadata Field</td></tr>
+<tr><th>Slug</th><td>4</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Sanaz Taheri &lt;sanaz@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Dean Eigenmann &lt;dean@status.im&gt;<br>Andrea Maria Piana &lt;andreap@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+</table>
+</div>
 In this specification, we describe a method to construct message history that
 will aid the consistency guarantees of [2/MVDS](../2/mvds.md).
 Additionally,
--- a/docs/vac/raw/consensus-hashgraphlike.md
+++ b/docs/vac/raw/consensus-hashgraphlike.md
@@ -1,252 +1,254 @@
---
-title: HASHGRAPHLIKE CONSENSUS
-name: Hashgraphlike Consensus Protocol
-status: raw
-category: Standards Track
-tags: 
-editor: Ugur Sen [ugur@status.im](mailto:ugur@status.im)
-contributors: seemenkina [ekaterina@status.im](mailto:ekaterina@status.im)
---
-## Abstract
-
-This document specifies a scalable, decentralized, and Byzantine Fault Tolerant (BFT)
-consensus mechanism inspired by Hashgraph, designed for binary decision-making in P2P networks.
-
-## Motivation
-
-Consensus is one of the essential components of decentralization.
-In particular, in the decentralized group messaging application is used for
-binary decision-making to govern the group.
-Therefore, each user contributes to the decision-making process.
-Besides achieving decentralization, the consensus mechanism MUST be strong:
-
- Under the assumption of at least `2/3` honest users in the network.
-
- Each user MUST conclude the same decision and scalability:
-message propagation in the network MUST occur within `O(log n)` rounds,
-where `n` is the total number of peers,
-in order to preserve the scalability of the messaging application.
-
-## Format 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).
-
-## Flow
-
-Any user in the group initializes the consensus by creating a proposal.
-Next, the user broadcasts the proposal to the whole network.
-Upon each user receives the proposal, validates the proposal,
-adds its vote as yes or no and with its signature and timestamp.
-The user then sends the proposal and vote to a random peer in a P2P setup,
-or to a subscribed gossipsub channel if gossip-based messaging is used.
-Therefore, each user first validates the signature and then adds its new vote.
-Each sending message counts as a round.
-After `log(n)` rounds all users in the network have the others vote
-if at least `2/3` number of users are honest where honesty follows the protocol.
-
-In general, the voting-based consensus consists of the following phases:
-
-1. Initialization of voting
-2. Exchanging votes across the rounds
-3. Counting the votes
-
-### Assumptions
-
- The users in the P2P network can discover the nodes or they are subscribing same channel in a gossipsub.
- We MAY have non-reliable (silent) nodes.
- Proposal owners MUST know the number of voters.
-
-## 1. Initialization of voting
-
-A user initializes the voting with the proposal payload which is
-implemented using [protocol buffers v3](https://protobuf.dev/) as follows:
-
-```bash
-syntax = "proto3";
-
-package vac.voting;
-
-message Proposal {
-  string name = 10;                  // Proposal name
-  string payload = 11;               // Proposal description
-  uint32 proposal_id = 12;           // Unique identifier of the proposal
-  bytes proposal_owner = 13;         // Public key of the creator 
-  repeated Votes = 14;               // Vote list in the proposal
-  uint32 expected_voters_count = 15; // Maximum number of distinct voters
-  uint32 round = 16;                 // Number of Votes 
-  uint64 timestamp = 17;             // Creation time of proposal
-  uint64 expiration_time = 18;       // The time interval that the proposal is active.  
-  bool liveness_criteria_yes = 19;   // Shows how managing the silent peers vote
-}
-
-message Vote {
-  uint32 vote_id = 20;            // Unique identifier of the vote
-  bytes vote_owner = 21;          // Voter's public key
-  uint32 proposal_id = 22;        // Linking votes and proposals
-  int64 timestamp = 23;           // Time when the vote was cast
-  bool vote = 24;                 // Vote bool value (true/false)
-  bytes parent_hash = 25;         // Hash of previous owner's Vote
-  bytes received_hash = 26;       // Hash of previous received Vote
-  bytes vote_hash = 27;           // Hash of all previously defined fields in Vote
-  bytes signature = 28;           // Signature of vote_hash
-}
-
-```
-
-To initiate a consensus for a proposal,
-a user MUST complete all the fields in the proposal, including attaching its `vote`
-and the `payload` that shows the purpose of the proposal.
-Notably, `parent_hash` and `received_hash` are empty strings because there is no previous or received hash.
-Then the initialization section ends when the user who creates the proposal sends it
-to the random peer from the network or sends it to the proposal to the specific channel.
-
-## 2. Exchanging votes across the peers
-
-Once the peer receives the proposal message `P_1` from a 1-1 or a gossipsub channel does the following checks:
-
-1. Check the signatures of the each votes in proposal, in particular for proposal `P_1`,
-verify the signature of `V_1` where `V_1 = P_1.votes[0]` with `V_1.signature` and `V_1.vote_owner`
-2. Do `parent_hash` check: If there are repeated votes from the same sender,
-check that the hash of the former vote is equal to the `parent_hash` of the later vote.
-3. Do `received_hash` check: If there are multiple votes in a proposal, check that the hash of a vote is equal to the `received_hash` of the next one.
-4. After successful verification of the signature and hashes, the receiving peer proceeds to generate `P_2` containing a new vote `V_2` as following:
-
-   4.1. Add its public key as `P_2.vote_owner`.
-
-   4.2. Set `timestamp`.
-
-   4.3. Set boolean `vote`.
-
-   4.4. Define `V_2.parent_hash = 0` if there is no previous peer's vote, otherwise hash of previous owner's vote.
-
-   4.5. Set `V_2.received_hash = hash(P_1.votes[0])`.
-  
-   4.6. Set `proposal_id` for the `vote`.
-  
-   4.7. Calculate `vote_hash` by hash of all previously defined fields in Vote:
-  `V_2.vote_hash = hash(vote_id, owner, proposal_id, timestamp, vote, parent_hash, received_hash)`
-
-   4.8. Sign `vote_hash` with its private key corresponding the public key as `vote_owner` component then adds `V_2.vote_hash`.
-
-5. Create `P_2` with by adding `V_2` as follows:
-  
-   5.1. Assign `P_2.name`, `P_2.proposal_id`, and `P_2.proposal_owner` to be identical to those in `P_1`.
-  
-   5.2. Add the `V_2` to the `P_2.Votes` list.
-  
-   5.3. Increase the round by one, namely `P_2.round = P_1.round + 1`.
-  
-   5.4. Verify that the proposal has not expired by checking that: `P_2.timestamp - current_time < P_1.expiration_time`.
-    If this does not hold, other peers ignore the message.
-
-After the peer creates the proposal `P_2` with its vote `V_2`,
-sends it to the random peer from the network or
-sends it to the proposal to the specific channel.
-
-## 3. Determining the result
-
-Because consensus depends on meeting a quorum threshold,
-each peer MUST verify the accumulated votes to determine whether the necessary conditions have been satisfied.
-The voting result is set YES if the majority of the `2n/3` from the distinct peers vote YES.
-
-To verify, the `findDistinctVoter` method processes the proposal by traversing its `Votes` list to determine the number of unique voters.
-
-If this method returns true, the peer proceeds with strong validation,
-which ensures that if any honest peer reaches a decision,
-no other honest peer can arrive at a conflicting result.
-
-1. Check each `signature` in the vote as shown in the [Section 2](#2-exchanging-votes-across-the-peers).
-
-2. Check the `parent_hash` chain if there are multiple votes from the same owner namely `vote_i` and `vote_i+1` respectively,
-the parent hash of `vote_i+1` should be the hash of `vote_i`
-
-3. Check the `previous_hash` chain, each received hash of `vote_i+1` should be equal to the hash of `vote_i`.
-
-4. Check the `timestamp` against the replay attack.
-In particular, the `timestamp` cannot be the old in the determined threshold.
-
-5. Check that the liveness criteria defined in the Liveness section are satisfied.
-
-If a proposal is verified by all the checks,
-the `countVote` method counts each YES vote from the list of Votes.
-
-## 4. Properties
-
-The consensus mechanism satisfies liveness and security properties as follows:
-
-### Liveness
-
-Liveness refers to the ability of the protocol to eventually reach a decision when sufficient honest participation is present.
-In this protocol, if `n > 2` and more than `n/2` of the votes among at least `2n/3` distinct peers are YES,
-then the consensus result is defined as YES; otherwise, when `n ≤ 2`, unanimous agreement (100% YES votes) is required.
-
-The peer calculates the result locally as shown in the [Section 3](#3-determining-the-result).
-From the [hashgraph property](https://hedera.com/learning/hedera-hashgraph/what-is-hashgraph-consensus),
-if a node could calculate the result of a proposal,
-it implies that no peer can calculate the opposite of the result.
-Still, reliability issues can cause some situations where peers cannot receive enough messages,
-so they cannot calculate the consensus result.
-
-Rounds are incremented when a peer adds and sends the new proposal.
-Calculating the required number of rounds, `2n/3` from the distinct peers' votes is achieved in two ways:
-
-1. `2n/3` rounds in pure P2P networks
-2. `2` rounds in gossipsub
-
-Since the message complexity is `O(1)` in the gossipsub channel,
-in case the network has reliability issues,
-the second round is used for the peers cannot receive all the messages from the first round.
-
-If an honest and online peer has received at least one vote but not enough to reach consensus,
-it MAY continue to propagate its own vote — and any votes it has received — to support message dissemination.
-This process can continue beyond the expected round count,
-as long as it remains within the expiration time defined in the proposal.
-The expiration time acts as a soft upper bound to ensure that consensus is either reached or aborted within a bounded timeframe.
-
-#### Equality of votes
-
-An equality of votes occurs when verifying at least `2n/3` distinct voters and
-applying `liveness_criteria_yes` the number of YES and NO votes is equal.
-
-Handling ties is an application-level decision. The application MUST define a deterministic tie policy:
-
-RETRY: re-run the vote with a new proposal_id, optionally adjusting parameters.
-
-REJECT: abort the proposal and return voting result as NO.
-
-The chosen policy SHOULD be consistent for all peers via proposal's `payload` to ensure convergence on the same outcome.
-
-### Silent Node Management
-
-Silent nodes are the nodes that not participate the voting as YES or NO.
-There are two possible counting votes for the silent peers.
-
-1. **Silent peers means YES:**
-Silent peers counted as YES vote, if the application prefer the strong rejection for NO votes.
-2. **Silent peers means NO:**
-Silent peers counted as NO vote, if the application prefer the strong acception for NO votes.
-
-The proposal is set to default true, which means silent peers' votes are counted as YES namely `liveness_criteria_yes` is set true by default.
-
-### Security
-
-This RFC uses cryptographic primitives to prevent the
-malicious behaviours as follows:
-
- Vote forgery attempt: creating unsigned invalid votes
- Inconsistent voting: a malicious peer submits conflicting votes (e.g., YES to some peers and NO to others)
-in different stages of the protocol, violating vote consistency and attempting to undermine consensus.
- Integrity breaking attempt: tampering history by changing previous votes.
- Replay attack: storing the old votes to maliciously use in fresh voting.
-
-## 5. Copyright
-
-Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)
-
-## 6. References
-
- [Hedera Hashgraph](https://hedera.com/learning/hedera-hashgraph/what-is-hashgraph-consensus)
- [Gossip about gossip](https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms/gossip-about-gossip)
- [Simple implementation of hashgraph consensus](https://github.com/conanwu777/hashgraph)
+# HASHGRAPHLIKE CONSENSUS
+
+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Hashgraphlike Consensus Protocol</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Ugur Sen [ugur@status.im](mailto:ugur@status.im)</td></tr>
+<tr><th>Contributors</th><td>s<br>e<br>e<br>m<br>e<br>n<br>k<br>i<br>n<br>a<br> <br>[<br>e<br>k<br>a<br>t<br>e<br>r<br>i<br>n<br>a<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>]<br>(<br>m<br>a<br>i<br>l<br>t<br>o<br>:<br>e<br>k<br>a<br>t<br>e<br>r<br>i<br>n<br>a<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>)</td></tr>
+</table>
+</div>
+## Abstract
+
+This document specifies a scalable, decentralized, and Byzantine Fault Tolerant (BFT)
+consensus mechanism inspired by Hashgraph, designed for binary decision-making in P2P networks.
+
+## Motivation
+
+Consensus is one of the essential components of decentralization.
+In particular, in the decentralized group messaging application is used for
+binary decision-making to govern the group.
+Therefore, each user contributes to the decision-making process.
+Besides achieving decentralization, the consensus mechanism MUST be strong:
+
+- Under the assumption of at least `2/3` honest users in the network.
+
+- Each user MUST conclude the same decision and scalability:
+message propagation in the network MUST occur within `O(log n)` rounds,
+where `n` is the total number of peers,
+in order to preserve the scalability of the messaging application.
+
+## Format 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).
+
+## Flow
+
+Any user in the group initializes the consensus by creating a proposal.
+Next, the user broadcasts the proposal to the whole network.
+Upon each user receives the proposal, validates the proposal,
+adds its vote as yes or no and with its signature and timestamp.
+The user then sends the proposal and vote to a random peer in a P2P setup,
+or to a subscribed gossipsub channel if gossip-based messaging is used.
+Therefore, each user first validates the signature and then adds its new vote.
+Each sending message counts as a round.
+After `log(n)` rounds all users in the network have the others vote
+if at least `2/3` number of users are honest where honesty follows the protocol.
+
+In general, the voting-based consensus consists of the following phases:
+
+1. Initialization of voting
+2. Exchanging votes across the rounds
+3. Counting the votes
+
+### Assumptions
+
+- The users in the P2P network can discover the nodes or they are subscribing same channel in a gossipsub.
+- We MAY have non-reliable (silent) nodes.
+- Proposal owners MUST know the number of voters.
+
+## 1. Initialization of voting
+
+A user initializes the voting with the proposal payload which is
+implemented using [protocol buffers v3](https://protobuf.dev/) as follows:
+
+```bash
+syntax = "proto3";
+
+package vac.voting;
+
+message Proposal {
+  string name = 10;                  // Proposal name
+  string payload = 11;               // Proposal description
+  uint32 proposal_id = 12;           // Unique identifier of the proposal
+  bytes proposal_owner = 13;         // Public key of the creator 
+  repeated Votes = 14;               // Vote list in the proposal
+  uint32 expected_voters_count = 15; // Maximum number of distinct voters
+  uint32 round = 16;                 // Number of Votes 
+  uint64 timestamp = 17;             // Creation time of proposal
+  uint64 expiration_time = 18;       // The time interval that the proposal is active.  
+  bool liveness_criteria_yes = 19;   // Shows how managing the silent peers vote
+}
+
+message Vote {
+  uint32 vote_id = 20;            // Unique identifier of the vote
+  bytes vote_owner = 21;          // Voter's public key
+  uint32 proposal_id = 22;        // Linking votes and proposals
+  int64 timestamp = 23;           // Time when the vote was cast
+  bool vote = 24;                 // Vote bool value (true/false)
+  bytes parent_hash = 25;         // Hash of previous owner's Vote
+  bytes received_hash = 26;       // Hash of previous received Vote
+  bytes vote_hash = 27;           // Hash of all previously defined fields in Vote
+  bytes signature = 28;           // Signature of vote_hash
+}
+
+```
+
+To initiate a consensus for a proposal,
+a user MUST complete all the fields in the proposal, including attaching its `vote`
+and the `payload` that shows the purpose of the proposal.
+Notably, `parent_hash` and `received_hash` are empty strings because there is no previous or received hash.
+Then the initialization section ends when the user who creates the proposal sends it
+to the random peer from the network or sends it to the proposal to the specific channel.
+
+## 2. Exchanging votes across the peers
+
+Once the peer receives the proposal message `P_1` from a 1-1 or a gossipsub channel does the following checks:
+
+1. Check the signatures of the each votes in proposal, in particular for proposal `P_1`,
+verify the signature of `V_1` where `V_1 = P_1.votes[0]` with `V_1.signature` and `V_1.vote_owner`
+2. Do `parent_hash` check: If there are repeated votes from the same sender,
+check that the hash of the former vote is equal to the `parent_hash` of the later vote.
+3. Do `received_hash` check: If there are multiple votes in a proposal, check that the hash of a vote is equal to the `received_hash` of the next one.
+4. After successful verification of the signature and hashes, the receiving peer proceeds to generate `P_2` containing a new vote `V_2` as following:
+
+   4.1. Add its public key as `P_2.vote_owner`.
+
+   4.2. Set `timestamp`.
+
+   4.3. Set boolean `vote`.
+
+   4.4. Define `V_2.parent_hash = 0` if there is no previous peer's vote, otherwise hash of previous owner's vote.
+
+   4.5. Set `V_2.received_hash = hash(P_1.votes[0])`.
+  
+   4.6. Set `proposal_id` for the `vote`.
+  
+   4.7. Calculate `vote_hash` by hash of all previously defined fields in Vote:
+  `V_2.vote_hash = hash(vote_id, owner, proposal_id, timestamp, vote, parent_hash, received_hash)`
+
+   4.8. Sign `vote_hash` with its private key corresponding the public key as `vote_owner` component then adds `V_2.vote_hash`.
+
+5. Create `P_2` with by adding `V_2` as follows:
+  
+   5.1. Assign `P_2.name`, `P_2.proposal_id`, and `P_2.proposal_owner` to be identical to those in `P_1`.
+  
+   5.2. Add the `V_2` to the `P_2.Votes` list.
+  
+   5.3. Increase the round by one, namely `P_2.round = P_1.round + 1`.
+  
+   5.4. Verify that the proposal has not expired by checking that: `P_2.timestamp - current_time < P_1.expiration_time`.
+    If this does not hold, other peers ignore the message.
+
+After the peer creates the proposal `P_2` with its vote `V_2`,
+sends it to the random peer from the network or
+sends it to the proposal to the specific channel.
+
+## 3. Determining the result
+
+Because consensus depends on meeting a quorum threshold,
+each peer MUST verify the accumulated votes to determine whether the necessary conditions have been satisfied.
+The voting result is set YES if the majority of the `2n/3` from the distinct peers vote YES.
+
+To verify, the `findDistinctVoter` method processes the proposal by traversing its `Votes` list to determine the number of unique voters.
+
+If this method returns true, the peer proceeds with strong validation,
+which ensures that if any honest peer reaches a decision,
+no other honest peer can arrive at a conflicting result.
+
+1. Check each `signature` in the vote as shown in the [Section 2](#2-exchanging-votes-across-the-peers).
+
+2. Check the `parent_hash` chain if there are multiple votes from the same owner namely `vote_i` and `vote_i+1` respectively,
+the parent hash of `vote_i+1` should be the hash of `vote_i`
+
+3. Check the `previous_hash` chain, each received hash of `vote_i+1` should be equal to the hash of `vote_i`.
+
+4. Check the `timestamp` against the replay attack.
+In particular, the `timestamp` cannot be the old in the determined threshold.
+
+5. Check that the liveness criteria defined in the Liveness section are satisfied.
+
+If a proposal is verified by all the checks,
+the `countVote` method counts each YES vote from the list of Votes.
+
+## 4. Properties
+
+The consensus mechanism satisfies liveness and security properties as follows:
+
+### Liveness
+
+Liveness refers to the ability of the protocol to eventually reach a decision when sufficient honest participation is present.
+In this protocol, if `n > 2` and more than `n/2` of the votes among at least `2n/3` distinct peers are YES,
+then the consensus result is defined as YES; otherwise, when `n ≤ 2`, unanimous agreement (100% YES votes) is required.
+
+The peer calculates the result locally as shown in the [Section 3](#3-determining-the-result).
+From the [hashgraph property](https://hedera.com/learning/hedera-hashgraph/what-is-hashgraph-consensus),
+if a node could calculate the result of a proposal,
+it implies that no peer can calculate the opposite of the result.
+Still, reliability issues can cause some situations where peers cannot receive enough messages,
+so they cannot calculate the consensus result.
+
+Rounds are incremented when a peer adds and sends the new proposal.
+Calculating the required number of rounds, `2n/3` from the distinct peers' votes is achieved in two ways:
+
+1. `2n/3` rounds in pure P2P networks
+2. `2` rounds in gossipsub
+
+Since the message complexity is `O(1)` in the gossipsub channel,
+in case the network has reliability issues,
+the second round is used for the peers cannot receive all the messages from the first round.
+
+If an honest and online peer has received at least one vote but not enough to reach consensus,
+it MAY continue to propagate its own vote — and any votes it has received — to support message dissemination.
+This process can continue beyond the expected round count,
+as long as it remains within the expiration time defined in the proposal.
+The expiration time acts as a soft upper bound to ensure that consensus is either reached or aborted within a bounded timeframe.
+
+#### Equality of votes
+
+An equality of votes occurs when verifying at least `2n/3` distinct voters and
+applying `liveness_criteria_yes` the number of YES and NO votes is equal.
+
+Handling ties is an application-level decision. The application MUST define a deterministic tie policy:
+
+RETRY: re-run the vote with a new proposal_id, optionally adjusting parameters.
+
+REJECT: abort the proposal and return voting result as NO.
+
+The chosen policy SHOULD be consistent for all peers via proposal's `payload` to ensure convergence on the same outcome.
+
+### Silent Node Management
+
+Silent nodes are the nodes that not participate the voting as YES or NO.
+There are two possible counting votes for the silent peers.
+
+1. **Silent peers means YES:**
+Silent peers counted as YES vote, if the application prefer the strong rejection for NO votes.
+2. **Silent peers means NO:**
+Silent peers counted as NO vote, if the application prefer the strong acception for NO votes.
+
+The proposal is set to default true, which means silent peers' votes are counted as YES namely `liveness_criteria_yes` is set true by default.
+
+### Security
+
+This RFC uses cryptographic primitives to prevent the
+malicious behaviours as follows:
+
+- Vote forgery attempt: creating unsigned invalid votes
+- Inconsistent voting: a malicious peer submits conflicting votes (e.g., YES to some peers and NO to others)
+in different stages of the protocol, violating vote consistency and attempting to undermine consensus.
+- Integrity breaking attempt: tampering history by changing previous votes.
+- Replay attack: storing the old votes to maliciously use in fresh voting.
+
+## 5. Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)
+
+## 6. References
+
+- [Hedera Hashgraph](https://hedera.com/learning/hedera-hashgraph/what-is-hashgraph-consensus)
+- [Gossip about gossip](https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms/gossip-about-gossip)
+- [Simple implementation of hashgraph consensus](https://github.com/conanwu777/hashgraph)
--- a/docs/vac/raw/decentralized-messaging-ethereum.md
+++ b/docs/vac/raw/decentralized-messaging-ethereum.md
@@ -1,12 +1,13 @@
---
-title: ETH-DCGKA
-name: Decentralized Key and Session Setup for Secure Messaging over Ethereum
-status: raw
-category: informational
-editor: Ramses Fernandez-Valencia <ramses@status.im>
-contributors:
---
+# ETH-DCGKA

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Decentralized Key and Session Setup for Secure Messaging over Ethereum</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>informational</td></tr>
+<tr><th>Editor</th><td>Ramses Fernandez-Valencia &lt;ramses@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document introduces a decentralized group messaging protocol
--- a/docs/vac/raw/deleted/eth-secpm.md
+++ b/docs/vac/raw/deleted/eth-secpm.md
@@ -1,13 +1,13 @@
---
-title: ETH-SECPM
-name: Secure channel setup using Ethereum accounts
-status: deleted
-category: Standards Track
-tags:
-editor: Ramses Fernandez <ramses@status.im>
-contributors:
---
+# ETH-SECPM

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Secure channel setup using Ethereum accounts</td></tr>
+<tr><th>Status</th><td>deleted</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Ramses Fernandez &lt;ramses@status.im&gt;</td></tr>
+</table>
+</div>
 ## NOTE

 The content of this specification has been split between
--- a/docs/vac/raw/eth-mls-offchain.md
+++ b/docs/vac/raw/eth-mls-offchain.md
@@ -1,436 +1,436 @@
---
-title: ETH-MLS-OFFCHAIN
-name: Secure channel setup using decentralized MLS and Ethereum accounts
-status: raw
-category: Standards Track
-tags:
-editor: Ugur Sen [ugur@status.im](mailto:ugur@status.im)
-contributors: seemenkina [ekaterina@status.im](mailto:ekaterina@status.im)
-
---
-
-## Abstract
-
-The following document specifies Ethereum authenticated scalable
-and decentralized secure group messaging application by
-integrating Message Layer Security (MLS) backend.
-Decentralization refers each user is a node in P2P network and
-each user has voice for any changes in group.
-This is achieved by integrating a consensus mechanism.
-Lastly, this RFC can also be referred to as de-MLS,
-decentralized MLS, to emphasize its deviation
-from the centralized trust assumptions of traditional MLS deployments.
-
-## Motivation
-
-Group messaging is a fundamental part of digital communication,
-yet most existing systems depend on centralized servers,
-which introduce risks around privacy, censorship, and unilateral control.
-In restrictive settings, servers can be blocked or surveilled;
-in more open environments, users still face opaque moderation policies,
-data collection, and exclusion from decision-making processes.
-To address this, we propose a decentralized, scalable peer-to-peer
-group messaging system where each participant runs a node, contributes
-to message propagation, and takes part in governance autonomously.
-Group membership changes are decided collectively through a lightweight
-partially synchronous, fault-tolerant consensus protocol without a centralized identity.
-This design enables truly democratic group communication and is well-suited
-for use cases like activist collectives, research collaborations, DAOs, support groups,
-and decentralized social platforms.
-
-## Format 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).
-
-### Assumptions
-
- The nodes in the P2P network can discover other nodes or will connect to other nodes when subscribing to same topic in a gossipsub.
- We MAY have non-reliable (silent) nodes.
- We MUST have a consensus that is lightweight, scalable and finalized in a specific time.
-
-## Roles
-
-The three roles used in de-MLS is as follows:
-
- `node`: Nodes are participants in the network that are not currently members
-of any secure group messaging session but remain available as potential candidates for group membership.
- `member`: Members are special nodes in the secure group messaging who
-obtains current group key of secure group messaging.
-Each node is assigned a unique identity represented as a 20-byte value named `member id`.
- `steward`: Stewards are special and transparent members in the secure group
-messaging who organize the changes by releasing commit messages upon the voted proposals.
-There are two special subsets of steward as epoch and backup steward,
-which are defined in the section de-MLS Objects.
-
-## MLS Background
-
-The de-MLS consists of MLS backend, so the MLS services and other MLS components
-are taken from the original [MLS specification](https://datatracker.ietf.org/doc/rfc9420/), with or without modifications.
-
-### MLS Services
-
-MLS is operated in two services authentication service (AS) and delivery service (DS).
-Authentication service enables group members to authenticate the credentials presented by other group members.
-The delivery service routes MLS messages among the nodes or
-members in the protocol in the correct order and
-manage the `keyPackage` of the users where the `keyPackage` is the objects
- that provide some public information about a user.
-
-### MLS Objects
-
-Following section presents the MLS objects and components that used in this RFC:
-
-`Epoch`: Time intervals that changes the state that is defined by members,
-section 3.4 in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/).
-
-`MLS proposal message:` Members MUST receive the proposal message prior to the
-corresponding commit message that initiates a new epoch with key changes,
-in order to ensure the intended security properties, section 12.1 in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/).
-Here, the add and remove proposals are used.
-
-`Application message`: This message type used in arbitrary encrypted communication between group members.
-This is restricted by [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) as if there is pending proposal,
-the application message should be cut.
-Note that: Since the MLS is based on servers, this delay between proposal and commit messages are very small.
-
-`Commit message:` After members receive the proposals regarding group changes,
-the committer, who may be any member of the group, as specified in  [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/),
-generates the necessary key material for the next epoch, including the appropriate welcome messages
-for new joiners and new entropy for removed members. In this RFC, the committers only MUST be stewards.
-
-### de-MLS Objects
-
-This section presents the de-MLS objects:
-
-`Voting proposal`: Similar to MLS proposals, but processed only if approved through a voting process.
-They function as application messages in the MLS group,
-allowing the steward to collect them without halting the protocol.
-There are three types of `voting proposal` according to the type of consensus as in shown Consensus Types section,
-these are, `commit proposal`, `steward election proposal` and `emergency criteria proposal`.
-
-`Epoch steward`: The steward assigned to commit in `epoch E` according to the steward list.
-Holds the primary responsibility for creating commit in that epoch.
-
-`Backup steward`: The steward next in line after the `epoch steward` on the `steward list` in `epoch E`.
-Only becomes active if the `epoch steward` is malicious or fails,
-in which case it completes the commitment phase.
-If unused in `epoch E`, it automatically becomes the `epoch steward` in `epoch E+1`.
-
-`Steward list`: It is an ordered list that contains the `member id`s of authorized stewards.
-Each steward in the list becomes main responsible for creating the commit message when its turn arrives,
-according to this order for each epoch.
-For example, suppose there are two stewards in the list `steward A` first and `steward B` last in the list.
-`steward A` is responsible for creating the commit message for first epoch.
-Similarly, `steward B` is for the last epoch.
-Since the `epoch steward` is the primary committer for an epoch,
-it holds the main responsibility for producing the commit.
-However, other stewards MAY also generate a commit within the same epoch to preserve liveness
-in case the epoch steward is inactive or slow.
-Duplicate commits are not re-applied and only the single valid commit for the epoch is accepted by the group,
-as in described in section filtering proposals against the multiple comitting.
-
-Therefore, if a malicious steward occurred, the `backup steward` will be charged with committing.
-Lastly, the size of the list named as `sn`, which also shows the epoch interval for steward list determination.
-
-## Flow
-
-General flow is as follows:
-
- A steward initializes a group just once, and then sends out Group Announcements (GA) periodically.
- Meanwhile, each `node` creates and sends their `credential` includes `keyPackage`.
- Each `member` creates `voting proposals` sends them to from MLS group during `epoch E`.
- Meanwhile, the `steward` collects finalized `voting proposals` from MLS group and converts them into
-`MLS proposals` then sends them with corresponding `commit messages`
- Evantually, with the commit messages, all members starts the next `epoch E+1`.
-
-## Creating Voting Proposal
-
-A `member` MAY initializes the voting with the proposal payload
-which is implemented using [protocol buffers v3](https://protobuf.dev/) as follows:
-
-```protobuf
-
-syntax = "proto3";
-
-message Proposal {
-string name = 10;                 // Proposal name
-string payload = 11;              // Describes the what is voting fore 
-int32 proposal_id = 12;           // Unique identifier of the proposal
-bytes proposal_owner = 13;        // Public key of the creator
-repeated Vote votes = 14;         // Vote list in the proposal
-int32 expected_voters_count = 15; // Maximum number of distinct voters
-int32 round = 16;                 // Number of Votes
-int64 timestamp = 17;             // Creation time of proposal
-int64 expiration_time = 18;       // Time interval that the proposal is active
-bool liveness_criteria_yes = 19;  // Shows how managing the silent peers vote
-}
-```
-
-```bash
-message Vote {
-int32 vote_id = 20;             // Unique identifier of the vote
-bytes vote_owner = 21;          // Voter's public key
-int64 timestamp = 22;           // Time when the vote was cast
-bool vote = 23;                 // Vote bool value (true/false)
-bytes parent_hash = 24;         // Hash of previous owner's Vote
-bytes received_hash = 25;       // Hash of previous received Vote
-bytes vote_hash = 26;           // Hash of all previously defined fields in Vote
-bytes signature = 27;           // Signature of vote_hash
-}
-```
-
-The voting proposal MAY include adding a `node` or removing a `member`.
-After the `member` creates the voting proposal,
-it is emitted to the network via the MLS `Application message` with a lightweight,
-epoch based voting such as [hashgraphlike consensus.](https://github.com/vacp2p/rfc-index/blob/consensus-hashgraph-like/vac/raw/consensus-hashgraphlike.md)
-This consensus result MUST be finalized within the epoch as YES or NO.
-
-If the voting result is YES, this points out the voting proposal will be converted into
-the MLS proposal by the `steward` and following commit message that starts the new epoch.
-
-## Creating welcome message
-
-When a MLS `MLS proposal message` is created by the `steward`,
-a `commit message` SHOULD follow,
-as in section 12.04 [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) to the members.
-In order for the new `member` joining the group to synchronize with the current members
-who received the `commit message`,
-the `steward` sends a welcome message to the node as the new `member`,
-as in section 12.4.3.1. [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/).
-
-## Single steward
-
-To naive way to create a decentralized secure group messaging is having a single transparent `steward`
-who only applies the changes regarding the result of the voting.
-
-This is mostly similar with the general flow and specified in voting proposal and welcome message creation sections.
-
-1. Each time a single `steward` initializes a group with group parameters with parameters
-as in section 8.1. Group Context in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/).
-2. `steward` creates a group anouncement (GA) according to the previous step and
-broadcast it to the all network periodically. GA message is visible in network to all `nodes`.
-3. The each `node` who wants to be a `member` needs to obtain this anouncement and create `credential`
-includes `keyPackage` that is specified in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) section 10.
-4. The `node` send the `KeyPackages` in plaintext with its signature with current `steward` public key which
-anounced in welcome topic. This step is crucial for security, ensuring that malicious nodes/stewards
-cannot use others' `KeyPackages`.
-It also provides flexibility for liveness in multi-steward settings,
-allowing more than one steward to obtain `KeyPackages` to commit.
-5. The `steward` aggregates all `KeyPackages` utilizes them to provision group additions for new members,
-based on the outcome of the voting process.
-6. Any `member` start to create `voting proposals` for adding or removing users,
-and present them to the voting in the MLS group as an application message.
-
-However, unlimited use of `voting proposals` within the group may be misused by
-malicious or overly active members.
-Therefore, an application-level constraint can be introduced to limit the number
-or frequency of proposals initiated by each member to prevent spam or abuse.
-7. Meanwhile, the `steward` collects finalized `voting proposals` with in epoch `E`,
-that have received affirmative votes from members via application messages.
-Otherwise, the `steward` discards proposals that did not receive a majority of "YES" votes.
-Since voting proposals are transmitted as application messages, omitting them does not affect
-the protocol’s correctness or consistency.
-8. The `steward` converts all approved `voting proposals` into
-corresponding `MLS proposals` and `commit message`, and
-transmits both in a single operation as in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) section 12.4,
-including welcome messages for the new members.
-Therefore, the `commit message` ends the previous epoch and create new ones.
-9. The `members` applied the incoming `commit message` by checking the signatures and `voting proposals`
-and synchronized with the upcoming epoch.
-
-## Multi stewards
-
-Decentralization has already been achieved in the previous section.
-However, to improve availability and ensure censorship resistance,
-the single steward protocol is extended to a multi steward architecture.
-In this design, each epoch is coordinated by a designated steward,
-operating under the same protocol as the single steward model.
-Thus, the multi steward approach primarily defines how steward roles
-rotate across epochs while preserving the underlying structure and logic of the original protocol.
-Two variants of the multi steward design are introduced to address different system requirements.
-
-### Consensus Types
-
-Consensus is agnostic with its payload; therefore, it can be used for various purposes.
-Note that each message for the consensus of proposals is an `application message` in the MLS object section.
-It is used in three ways as follows:
-
-1. `Commit proposal`:  It is the proposal instance that is specified in Creating Voting Proposal section
-with `Proposal.payload` MUST show the commit request from `members`.
-Any member MAY create this proposal in any epoch and `epoch steward` MUST collect and commit YES voted proposals.
-This is the only proposal type common to both single steward and multi steward designs.
-2. `Steward election proposal`: This is the process that finalizes the `steward list`,
-which sets and orders stewards responsible for creating commits over a predefined number of range in (`sn_min`,`sn_max`).
-The validity of the choosen `steward list` ends when the last steward in the list (the one at the final index) completes its commit.
-At that point, a new `steward election proposal` MUST be initiated again by any member during the corresponding epoch.
-The `Proposal.payload` field MUST represent the ordered identities of the proposed stewards.
-Each steward election proposal MUST be verified and finalized through the consensus process
-so that members can identify which steward will be responsible in each epoch
-and detect any unauthorized steward commits.
-3. `Emergency criteria proposal`: If there is a malicious member or steward,
-this event MUST be voted on to finalize it.
-If this returns YES, the next epoch MUST include the removal of the member or steward.
-In a specific case where a steward is removed from the group, causing the total number of stewards to fall below `sn_min`,  
-it is required to repeat the `steward election proposal`.
-`Proposal.payload` MUST consist of the evidence of the dishonesty as described in the Steward violation list,
-and the identifier of the malicious member or steward.
-This proposal can be created by any member in any epoch.
-
-The order of consensus proposal messages is important to achieving a consistent result.
-Therefore, messages MUST be prioritized by type in the following order, from highest to lowest priority:
-
- `Emergency criteria proposal`
-
- `Steward election proposal`
-
- `Commit proposal`
-
-This means that if a higher-priority consensus proposal is present in the network,
-lower-priority messages MUST be withheld from transmission until the higher-priority proposals have been finalized.
-
-### Steward list creation
-
-The `steward list` consists of steward nominees who will become actual stewards if the `steward election proposal` is finalized with YES,
-is arbitrarily chosen from `member` and OPTIONALLY adjusted depending on the needs of the implementation.
-The `steward list` size, defined by the minimum `sn_min` and maximum `sn_max` bounds,
-is determined at the time of group creation.
-The `sn_min` requirement is applied only when the total number of members exceeds `sn_min`;
-if the number of available members falls below this threshold,
-the list size automatically adjusts to include all existing members.
-
-The actual size of the list MAY vary within this range as `sn`, with the minimum value being at least 1.
-
-The index of the slots shows epoch info and value of index shows `member id`s.
-The next in line steward for the `epoch E` is named as `epoch steward`, which has index E.
-And the subsequent steward in the `epoch E` is named as the `backup steward`.
-For example, let's assume steward list is (S3, S2, S1) if in the previous epoch the roles were
-(`backup steward`: S2, `epoch steward`: S1), then in the next epoch they become
-(`backup steward`: S3, `epoch steward`: S2) by shifting.
-
-If the `epoch steward` is honest, the `backup steward` does not involve the process in epoch,
-and the `backup steward` will be the `epoch steward` within the `epoch E+1`.
-
-If the `epoch steward` is malicious, the `backup steward` is involved in the commitment phase in `epoch E`
-and the former steward becomes the `backup steward` in `epoch E`.
-
-Liveness criteria:
-
-Once the active `steward list` has completed its assigned epochs,
-
-members MUST proceed to elect the next set of stewards
-(which MAY include some or all of the previous members).
-This election is conducted through a type 2 consensus procedure, `steward election proposal`.
-
-A `Steward election proposal` is considered valid only if the resulting `steward list`
-is produced through a deterministic process that ensures an unbiased distribution of steward assignments,
-since allowing bias could enable a malicious participant to manipulate the list
-and retain control within a favored group for multiple epochs.
-
-The list MUST consist of at least `sn_min` members, including retained previous stewards,
-sorted according to the ascending value of `SHA256(epoch E || member id || group id)`,
-where `epoch E` is the epoch in which the election proposal is initiated,
-and `group id` for shuffling the list across the different groups.
-Any proposal with a list that does not adhere to this generation method MUST be rejected by all members.
-
-We assume that there are no recurring entries in `SHA256(epoch E || member id || group id)`, since the SHA256 outputs are unique
-when there is no repetition in the `member id` values, against the conflicts on sorting issues.
-
-### Multi steward with big consensuses
-
-In this model, all group modifications, such as adding or removing members,
-must be approved through consensus by all participants,
-including the steward assigned for `epoch E`.
-A configuration with multiple stewards operating under a shared consensus protocol offers
-increased decentralization and stronger protection against censorship.
-However, this benefit comes with reduced operational efficiency.
-The model is therefore best suited for small groups that value
-decentralization and censorship resistance more than performance.
-
-To create a multi steward with a big consensus,
-the group is initialized with a single steward as specified as follows:
-
-1. The steward initialized the group with the config file.
-This config file MUST contain (`sn_min`,`sn_max`) as the `steward list` size range.
-2. The steward adds the members as a centralized way till the number of members reaches the `sn_min`.
-Then, members propose lists by voting proposal with size `sn`
-as a consensus among all members, as mentioned in the consensus section 2, according to the checks:
-the size of the proposed list `sn` is in the interval (`sn_min`,`sn_max`).
-Note that if the total number of members is below `sn_min`,
-then the steward list size MUST be equal to the total member count.
-3. After the voting proposal ends up with a `steward list`,
-and group changes are ready to be committed as specified in single steward section
-with a difference which is members also check the committed steward is `epoch steward` or `backup steward`,
-otherwise anyone can create `emergency criteria proposal`.
-4. If the `epoch steward` violates the changing process as mentioned in the section Steward violation list,
-one of the members MUST initialize the `emergency criteria proposal` to remove the malicious Steward.
-Then `backup steward` fulfills the epoch by committing again correctly.
-
-A large consensus group provides better decentralization, but it requires significant coordination,
-which MAY not be suitable for groups with more than 1000 members.
-
-### Multi steward with small consensuses
-
-The small consensus model offers improved efficiency with a trade-off in decentralization.
-In this design, group changes require consensus only among the stewards, rather than all members.
-Regular members participate by periodically selecting the stewards by `steward election proposal`
-but do not take part in commit decision by `commit proposal`.
-This structure enables faster coordination since consensus is achieved within a smaller group of stewards.
-It is particularly suitable for large user groups, where involving every member in each decision would be impractical.
-
-The flow is similar to the big consensus including the `steward list` finalization with all members consensus
-only the difference here, the commit messages requires `commit proposal` only among the stewards.
-
-## Filtering proposals against the multiple comitting
-
-Since stewards are allowed to produce a commit even when they are not the designated `epoch steward`,
-multiple commits may appear within the same epoch, often reflecting recurring versions of the same proposal.
-To ensure a consistent outcome, the valid commit for the epoch SHOULD be selected as the one derived
-from the longest proposal chain, ordered by the ascending value of each proposal as `SHA256(proposal)`.
-All other cases, such as invalid commits or commits based on proposals that were not approved through voting,
-can be easily detected and discarded by the members.
-
-## Steward violation list
-
-A steward’s activity is called a violation if the action is one or more of the following:
-
-1. Broken commit: The steward releases a different commit message from the voted `commit proposal`.
-This activity is identified by the `members` since the [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) provides the methods
-that members can use to identify the broken commit messages that are possible in a few situations,
-such as commit and proposal incompatibility. Specifically, the broken commit can arise as follows:
-    1. The commit belongs to the earlier epoch.
-    2. The commit message should equal the latest epoch
-    3. The commit needs to be compatible with the previous epoch’s `MLS proposal`.
-2. Broken MLS proposal: The steward prepares a different `MLS proposal` for the corresponding `voting proposal`.
-This activity is identified by the `members` since both `MLS proposal` and `voting proposal` are visible
-and can be identified by checking the hash of `Proposal.payload` and `MLSProposal.payload` is the same as RFC9240 section 12.1. Proposals.
-3. Censorship and inactivity: The situation where there is a voting proposal that is visible for every member,
-and the Steward does not provide an MLS proposal and commit.
-This activity is again identified by the `members`since `voting proposals` are visible to every member in the group,
-therefore each member can verify that there is no `MLS proposal` corresponding to `voting proposal`.
-
-## Security Considerations
-
-In this section, the security considerations are shown as de-MLS assurance.
-
-1. Malicious Steward: A Malicious steward can act maliciously,
-as in the Steward violation list section.
-Therefore, de-MLS enforces that any steward only follows the protocol under the consensus order
-and commits without emergency criteria application.
-2. Malicious Member: A member is only marked as malicious
-when the member acts by releasing a commit message.
-3. Steward list election bias: Although SHA256 is used together with two global variables
-to shuffle stewards in a deterministic and verifiable manner,
-this approach only minimizes election bias; it does not completely eliminate it.
-This design choice is intentional, in order to preserve the efficiency advantages provided by the MLS mechanism.
-
-## Copyright
-
-Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)
-
-### References
-
- [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/)
- [Hashgraphlike Consensus](https://github.com/vacp2p/rfc-index/blob/consensus-hashgraph-like/vac/raw/consensus-hashgraphlike.md)
- [vacp2p/de-mls](https://github.com/vacp2p/de-mls)
+# ETH-MLS-OFFCHAIN
+
+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Secure channel setup using decentralized MLS and Ethereum accounts</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Ugur Sen [ugur@status.im](mailto:ugur@status.im)</td></tr>
+<tr><th>Contributors</th><td>s<br>e<br>e<br>m<br>e<br>n<br>k<br>i<br>n<br>a<br> <br>[<br>e<br>k<br>a<br>t<br>e<br>r<br>i<br>n<br>a<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>]<br>(<br>m<br>a<br>i<br>l<br>t<br>o<br>:<br>e<br>k<br>a<br>t<br>e<br>r<br>i<br>n<br>a<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>)</td></tr>
+</table>
+</div>
+## Abstract
+
+The following document specifies Ethereum authenticated scalable
+and decentralized secure group messaging application by
+integrating Message Layer Security (MLS) backend.
+Decentralization refers each user is a node in P2P network and
+each user has voice for any changes in group.
+This is achieved by integrating a consensus mechanism.
+Lastly, this RFC can also be referred to as de-MLS,
+decentralized MLS, to emphasize its deviation
+from the centralized trust assumptions of traditional MLS deployments.
+
+## Motivation
+
+Group messaging is a fundamental part of digital communication,
+yet most existing systems depend on centralized servers,
+which introduce risks around privacy, censorship, and unilateral control.
+In restrictive settings, servers can be blocked or surveilled;
+in more open environments, users still face opaque moderation policies,
+data collection, and exclusion from decision-making processes.
+To address this, we propose a decentralized, scalable peer-to-peer
+group messaging system where each participant runs a node, contributes
+to message propagation, and takes part in governance autonomously.
+Group membership changes are decided collectively through a lightweight
+partially synchronous, fault-tolerant consensus protocol without a centralized identity.
+This design enables truly democratic group communication and is well-suited
+for use cases like activist collectives, research collaborations, DAOs, support groups,
+and decentralized social platforms.
+
+## Format 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).
+
+### Assumptions
+
+- The nodes in the P2P network can discover other nodes or will connect to other nodes when subscribing to same topic in a gossipsub.
+- We MAY have non-reliable (silent) nodes.
+- We MUST have a consensus that is lightweight, scalable and finalized in a specific time.
+
+## Roles
+
+The three roles used in de-MLS is as follows:
+
+- `node`: Nodes are participants in the network that are not currently members
+of any secure group messaging session but remain available as potential candidates for group membership.
+- `member`: Members are special nodes in the secure group messaging who
+obtains current group key of secure group messaging.
+Each node is assigned a unique identity represented as a 20-byte value named `member id`.
+- `steward`: Stewards are special and transparent members in the secure group
+messaging who organize the changes by releasing commit messages upon the voted proposals.
+There are two special subsets of steward as epoch and backup steward,
+which are defined in the section de-MLS Objects.
+
+## MLS Background
+
+The de-MLS consists of MLS backend, so the MLS services and other MLS components
+are taken from the original [MLS specification](https://datatracker.ietf.org/doc/rfc9420/), with or without modifications.
+
+### MLS Services
+
+MLS is operated in two services authentication service (AS) and delivery service (DS).
+Authentication service enables group members to authenticate the credentials presented by other group members.
+The delivery service routes MLS messages among the nodes or
+members in the protocol in the correct order and
+manage the `keyPackage` of the users where the `keyPackage` is the objects
+ that provide some public information about a user.
+
+### MLS Objects
+
+Following section presents the MLS objects and components that used in this RFC:
+
+`Epoch`: Time intervals that changes the state that is defined by members,
+section 3.4 in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+`MLS proposal message:` Members MUST receive the proposal message prior to the
+corresponding commit message that initiates a new epoch with key changes,
+in order to ensure the intended security properties, section 12.1 in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/).
+Here, the add and remove proposals are used.
+
+`Application message`: This message type used in arbitrary encrypted communication between group members.
+This is restricted by [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) as if there is pending proposal,
+the application message should be cut.
+Note that: Since the MLS is based on servers, this delay between proposal and commit messages are very small.
+
+`Commit message:` After members receive the proposals regarding group changes,
+the committer, who may be any member of the group, as specified in  [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/),
+generates the necessary key material for the next epoch, including the appropriate welcome messages
+for new joiners and new entropy for removed members. In this RFC, the committers only MUST be stewards.
+
+### de-MLS Objects
+
+This section presents the de-MLS objects:
+
+`Voting proposal`: Similar to MLS proposals, but processed only if approved through a voting process.
+They function as application messages in the MLS group,
+allowing the steward to collect them without halting the protocol.
+There are three types of `voting proposal` according to the type of consensus as in shown Consensus Types section,
+these are, `commit proposal`, `steward election proposal` and `emergency criteria proposal`.
+
+`Epoch steward`: The steward assigned to commit in `epoch E` according to the steward list.
+Holds the primary responsibility for creating commit in that epoch.
+
+`Backup steward`: The steward next in line after the `epoch steward` on the `steward list` in `epoch E`.
+Only becomes active if the `epoch steward` is malicious or fails,
+in which case it completes the commitment phase.
+If unused in `epoch E`, it automatically becomes the `epoch steward` in `epoch E+1`.
+
+`Steward list`: It is an ordered list that contains the `member id`s of authorized stewards.
+Each steward in the list becomes main responsible for creating the commit message when its turn arrives,
+according to this order for each epoch.
+For example, suppose there are two stewards in the list `steward A` first and `steward B` last in the list.
+`steward A` is responsible for creating the commit message for first epoch.
+Similarly, `steward B` is for the last epoch.
+Since the `epoch steward` is the primary committer for an epoch,
+it holds the main responsibility for producing the commit.
+However, other stewards MAY also generate a commit within the same epoch to preserve liveness
+in case the epoch steward is inactive or slow.
+Duplicate commits are not re-applied and only the single valid commit for the epoch is accepted by the group,
+as in described in section filtering proposals against the multiple comitting.
+
+Therefore, if a malicious steward occurred, the `backup steward` will be charged with committing.
+Lastly, the size of the list named as `sn`, which also shows the epoch interval for steward list determination.
+
+## Flow
+
+General flow is as follows:
+
+- A steward initializes a group just once, and then sends out Group Announcements (GA) periodically.
+- Meanwhile, each `node` creates and sends their `credential` includes `keyPackage`.
+- Each `member` creates `voting proposals` sends them to from MLS group during `epoch E`.
+- Meanwhile, the `steward` collects finalized `voting proposals` from MLS group and converts them into
+`MLS proposals` then sends them with corresponding `commit messages`
+- Evantually, with the commit messages, all members starts the next `epoch E+1`.
+
+## Creating Voting Proposal
+
+A `member` MAY initializes the voting with the proposal payload
+which is implemented using [protocol buffers v3](https://protobuf.dev/) as follows:
+
+```protobuf
+
+syntax = "proto3";
+
+message Proposal {
+string name = 10;                 // Proposal name
+string payload = 11;              // Describes the what is voting fore 
+int32 proposal_id = 12;           // Unique identifier of the proposal
+bytes proposal_owner = 13;        // Public key of the creator
+repeated Vote votes = 14;         // Vote list in the proposal
+int32 expected_voters_count = 15; // Maximum number of distinct voters
+int32 round = 16;                 // Number of Votes
+int64 timestamp = 17;             // Creation time of proposal
+int64 expiration_time = 18;       // Time interval that the proposal is active
+bool liveness_criteria_yes = 19;  // Shows how managing the silent peers vote
+}
+```
+
+```bash
+message Vote {
+int32 vote_id = 20;             // Unique identifier of the vote
+bytes vote_owner = 21;          // Voter's public key
+int64 timestamp = 22;           // Time when the vote was cast
+bool vote = 23;                 // Vote bool value (true/false)
+bytes parent_hash = 24;         // Hash of previous owner's Vote
+bytes received_hash = 25;       // Hash of previous received Vote
+bytes vote_hash = 26;           // Hash of all previously defined fields in Vote
+bytes signature = 27;           // Signature of vote_hash
+}
+```
+
+The voting proposal MAY include adding a `node` or removing a `member`.
+After the `member` creates the voting proposal,
+it is emitted to the network via the MLS `Application message` with a lightweight,
+epoch based voting such as [hashgraphlike consensus.](https://github.com/vacp2p/rfc-index/blob/consensus-hashgraph-like/vac/raw/consensus-hashgraphlike.md)
+This consensus result MUST be finalized within the epoch as YES or NO.
+
+If the voting result is YES, this points out the voting proposal will be converted into
+the MLS proposal by the `steward` and following commit message that starts the new epoch.
+
+## Creating welcome message
+
+When a MLS `MLS proposal message` is created by the `steward`,
+a `commit message` SHOULD follow,
+as in section 12.04 [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) to the members.
+In order for the new `member` joining the group to synchronize with the current members
+who received the `commit message`,
+the `steward` sends a welcome message to the node as the new `member`,
+as in section 12.4.3.1. [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/).
+
+## Single steward
+
+To naive way to create a decentralized secure group messaging is having a single transparent `steward`
+who only applies the changes regarding the result of the voting.
+
+This is mostly similar with the general flow and specified in voting proposal and welcome message creation sections.
+
+1. Each time a single `steward` initializes a group with group parameters with parameters
+as in section 8.1. Group Context in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/).
+2. `steward` creates a group anouncement (GA) according to the previous step and
+broadcast it to the all network periodically. GA message is visible in network to all `nodes`.
+3. The each `node` who wants to be a `member` needs to obtain this anouncement and create `credential`
+includes `keyPackage` that is specified in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) section 10.
+4. The `node` send the `KeyPackages` in plaintext with its signature with current `steward` public key which
+anounced in welcome topic. This step is crucial for security, ensuring that malicious nodes/stewards
+cannot use others' `KeyPackages`.
+It also provides flexibility for liveness in multi-steward settings,
+allowing more than one steward to obtain `KeyPackages` to commit.
+5. The `steward` aggregates all `KeyPackages` utilizes them to provision group additions for new members,
+based on the outcome of the voting process.
+6. Any `member` start to create `voting proposals` for adding or removing users,
+and present them to the voting in the MLS group as an application message.
+
+However, unlimited use of `voting proposals` within the group may be misused by
+malicious or overly active members.
+Therefore, an application-level constraint can be introduced to limit the number
+or frequency of proposals initiated by each member to prevent spam or abuse.
+7. Meanwhile, the `steward` collects finalized `voting proposals` with in epoch `E`,
+that have received affirmative votes from members via application messages.
+Otherwise, the `steward` discards proposals that did not receive a majority of "YES" votes.
+Since voting proposals are transmitted as application messages, omitting them does not affect
+the protocol’s correctness or consistency.
+8. The `steward` converts all approved `voting proposals` into
+corresponding `MLS proposals` and `commit message`, and
+transmits both in a single operation as in [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) section 12.4,
+including welcome messages for the new members.
+Therefore, the `commit message` ends the previous epoch and create new ones.
+9. The `members` applied the incoming `commit message` by checking the signatures and `voting proposals`
+and synchronized with the upcoming epoch.
+
+## Multi stewards
+
+Decentralization has already been achieved in the previous section.
+However, to improve availability and ensure censorship resistance,
+the single steward protocol is extended to a multi steward architecture.
+In this design, each epoch is coordinated by a designated steward,
+operating under the same protocol as the single steward model.
+Thus, the multi steward approach primarily defines how steward roles
+rotate across epochs while preserving the underlying structure and logic of the original protocol.
+Two variants of the multi steward design are introduced to address different system requirements.
+
+### Consensus Types
+
+Consensus is agnostic with its payload; therefore, it can be used for various purposes.
+Note that each message for the consensus of proposals is an `application message` in the MLS object section.
+It is used in three ways as follows:
+
+1. `Commit proposal`:  It is the proposal instance that is specified in Creating Voting Proposal section
+with `Proposal.payload` MUST show the commit request from `members`.
+Any member MAY create this proposal in any epoch and `epoch steward` MUST collect and commit YES voted proposals.
+This is the only proposal type common to both single steward and multi steward designs.
+2. `Steward election proposal`: This is the process that finalizes the `steward list`,
+which sets and orders stewards responsible for creating commits over a predefined number of range in (`sn_min`,`sn_max`).
+The validity of the choosen `steward list` ends when the last steward in the list (the one at the final index) completes its commit.
+At that point, a new `steward election proposal` MUST be initiated again by any member during the corresponding epoch.
+The `Proposal.payload` field MUST represent the ordered identities of the proposed stewards.
+Each steward election proposal MUST be verified and finalized through the consensus process
+so that members can identify which steward will be responsible in each epoch
+and detect any unauthorized steward commits.
+3. `Emergency criteria proposal`: If there is a malicious member or steward,
+this event MUST be voted on to finalize it.
+If this returns YES, the next epoch MUST include the removal of the member or steward.
+In a specific case where a steward is removed from the group, causing the total number of stewards to fall below `sn_min`,  
+it is required to repeat the `steward election proposal`.
+`Proposal.payload` MUST consist of the evidence of the dishonesty as described in the Steward violation list,
+and the identifier of the malicious member or steward.
+This proposal can be created by any member in any epoch.
+
+The order of consensus proposal messages is important to achieving a consistent result.
+Therefore, messages MUST be prioritized by type in the following order, from highest to lowest priority:
+
+- `Emergency criteria proposal`
+
+- `Steward election proposal`
+
+- `Commit proposal`
+
+This means that if a higher-priority consensus proposal is present in the network,
+lower-priority messages MUST be withheld from transmission until the higher-priority proposals have been finalized.
+
+### Steward list creation
+
+The `steward list` consists of steward nominees who will become actual stewards if the `steward election proposal` is finalized with YES,
+is arbitrarily chosen from `member` and OPTIONALLY adjusted depending on the needs of the implementation.
+The `steward list` size, defined by the minimum `sn_min` and maximum `sn_max` bounds,
+is determined at the time of group creation.
+The `sn_min` requirement is applied only when the total number of members exceeds `sn_min`;
+if the number of available members falls below this threshold,
+the list size automatically adjusts to include all existing members.
+
+The actual size of the list MAY vary within this range as `sn`, with the minimum value being at least 1.
+
+The index of the slots shows epoch info and value of index shows `member id`s.
+The next in line steward for the `epoch E` is named as `epoch steward`, which has index E.
+And the subsequent steward in the `epoch E` is named as the `backup steward`.
+For example, let's assume steward list is (S3, S2, S1) if in the previous epoch the roles were
+(`backup steward`: S2, `epoch steward`: S1), then in the next epoch they become
+(`backup steward`: S3, `epoch steward`: S2) by shifting.
+
+If the `epoch steward` is honest, the `backup steward` does not involve the process in epoch,
+and the `backup steward` will be the `epoch steward` within the `epoch E+1`.
+
+If the `epoch steward` is malicious, the `backup steward` is involved in the commitment phase in `epoch E`
+and the former steward becomes the `backup steward` in `epoch E`.
+
+Liveness criteria:
+
+Once the active `steward list` has completed its assigned epochs,
+
+members MUST proceed to elect the next set of stewards
+(which MAY include some or all of the previous members).
+This election is conducted through a type 2 consensus procedure, `steward election proposal`.
+
+A `Steward election proposal` is considered valid only if the resulting `steward list`
+is produced through a deterministic process that ensures an unbiased distribution of steward assignments,
+since allowing bias could enable a malicious participant to manipulate the list
+and retain control within a favored group for multiple epochs.
+
+The list MUST consist of at least `sn_min` members, including retained previous stewards,
+sorted according to the ascending value of `SHA256(epoch E || member id || group id)`,
+where `epoch E` is the epoch in which the election proposal is initiated,
+and `group id` for shuffling the list across the different groups.
+Any proposal with a list that does not adhere to this generation method MUST be rejected by all members.
+
+We assume that there are no recurring entries in `SHA256(epoch E || member id || group id)`, since the SHA256 outputs are unique
+when there is no repetition in the `member id` values, against the conflicts on sorting issues.
+
+### Multi steward with big consensuses
+
+In this model, all group modifications, such as adding or removing members,
+must be approved through consensus by all participants,
+including the steward assigned for `epoch E`.
+A configuration with multiple stewards operating under a shared consensus protocol offers
+increased decentralization and stronger protection against censorship.
+However, this benefit comes with reduced operational efficiency.
+The model is therefore best suited for small groups that value
+decentralization and censorship resistance more than performance.
+
+To create a multi steward with a big consensus,
+the group is initialized with a single steward as specified as follows:
+
+1. The steward initialized the group with the config file.
+This config file MUST contain (`sn_min`,`sn_max`) as the `steward list` size range.
+2. The steward adds the members as a centralized way till the number of members reaches the `sn_min`.
+Then, members propose lists by voting proposal with size `sn`
+as a consensus among all members, as mentioned in the consensus section 2, according to the checks:
+the size of the proposed list `sn` is in the interval (`sn_min`,`sn_max`).
+Note that if the total number of members is below `sn_min`,
+then the steward list size MUST be equal to the total member count.
+3. After the voting proposal ends up with a `steward list`,
+and group changes are ready to be committed as specified in single steward section
+with a difference which is members also check the committed steward is `epoch steward` or `backup steward`,
+otherwise anyone can create `emergency criteria proposal`.
+4. If the `epoch steward` violates the changing process as mentioned in the section Steward violation list,
+one of the members MUST initialize the `emergency criteria proposal` to remove the malicious Steward.
+Then `backup steward` fulfills the epoch by committing again correctly.
+
+A large consensus group provides better decentralization, but it requires significant coordination,
+which MAY not be suitable for groups with more than 1000 members.
+
+### Multi steward with small consensuses
+
+The small consensus model offers improved efficiency with a trade-off in decentralization.
+In this design, group changes require consensus only among the stewards, rather than all members.
+Regular members participate by periodically selecting the stewards by `steward election proposal`
+but do not take part in commit decision by `commit proposal`.
+This structure enables faster coordination since consensus is achieved within a smaller group of stewards.
+It is particularly suitable for large user groups, where involving every member in each decision would be impractical.
+
+The flow is similar to the big consensus including the `steward list` finalization with all members consensus
+only the difference here, the commit messages requires `commit proposal` only among the stewards.
+
+## Filtering proposals against the multiple comitting
+
+Since stewards are allowed to produce a commit even when they are not the designated `epoch steward`,
+multiple commits may appear within the same epoch, often reflecting recurring versions of the same proposal.
+To ensure a consistent outcome, the valid commit for the epoch SHOULD be selected as the one derived
+from the longest proposal chain, ordered by the ascending value of each proposal as `SHA256(proposal)`.
+All other cases, such as invalid commits or commits based on proposals that were not approved through voting,
+can be easily detected and discarded by the members.
+
+## Steward violation list
+
+A steward’s activity is called a violation if the action is one or more of the following:
+
+1. Broken commit: The steward releases a different commit message from the voted `commit proposal`.
+This activity is identified by the `members` since the [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/) provides the methods
+that members can use to identify the broken commit messages that are possible in a few situations,
+such as commit and proposal incompatibility. Specifically, the broken commit can arise as follows:
+    1. The commit belongs to the earlier epoch.
+    2. The commit message should equal the latest epoch
+    3. The commit needs to be compatible with the previous epoch’s `MLS proposal`.
+2. Broken MLS proposal: The steward prepares a different `MLS proposal` for the corresponding `voting proposal`.
+This activity is identified by the `members` since both `MLS proposal` and `voting proposal` are visible
+and can be identified by checking the hash of `Proposal.payload` and `MLSProposal.payload` is the same as RFC9240 section 12.1. Proposals.
+3. Censorship and inactivity: The situation where there is a voting proposal that is visible for every member,
+and the Steward does not provide an MLS proposal and commit.
+This activity is again identified by the `members`since `voting proposals` are visible to every member in the group,
+therefore each member can verify that there is no `MLS proposal` corresponding to `voting proposal`.
+
+## Security Considerations
+
+In this section, the security considerations are shown as de-MLS assurance.
+
+1. Malicious Steward: A Malicious steward can act maliciously,
+as in the Steward violation list section.
+Therefore, de-MLS enforces that any steward only follows the protocol under the consensus order
+and commits without emergency criteria application.
+2. Malicious Member: A member is only marked as malicious
+when the member acts by releasing a commit message.
+3. Steward list election bias: Although SHA256 is used together with two global variables
+to shuffle stewards in a deterministic and verifiable manner,
+this approach only minimizes election bias; it does not completely eliminate it.
+This design choice is intentional, in order to preserve the efficiency advantages provided by the MLS mechanism.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)
+
+### References
+
+- [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/)
+- [Hashgraphlike Consensus](https://github.com/vacp2p/rfc-index/blob/consensus-hashgraph-like/vac/raw/consensus-hashgraphlike.md)
+- [vacp2p/de-mls](https://github.com/vacp2p/de-mls)
--- a/docs/vac/raw/eth-mls-onchain.md
+++ b/docs/vac/raw/eth-mls-onchain.md
@@ -1,13 +1,14 @@
---
-title: ETH-MLS-ONCHAIN
-name: Secure channel setup using decentralized MLS and Ethereum accounts
-status: raw
-category: Standards Track
-tags:
-editor: Ramses Fernandez <ramses@status.im>
-contributors: Aaryamann Challani <aaryamann@status.im>, Ekaterina Broslavskaya <ekaterina@status.im>, Ugur Sen <ugur@status.im>, Ksr <ksr@status.im>
---
+# ETH-MLS-ONCHAIN

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Secure channel setup using decentralized MLS and Ethereum accounts</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Ramses Fernandez &lt;ramses@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>A<br>a<br>r<br>y<br>a<br>m<br>a<br>n<br>n<br> <br>C<br>h<br>a<br>l<br>l<br>a<br>n<br>i<br> <br>&lt;<br>a<br>a<br>r<br>y<br>a<br>m<br>a<br>n<br>n<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>&gt;<br>,<br> <br>E<br>k<br>a<br>t<br>e<br>r<br>i<br>n<br>a<br> <br>B<br>r<br>o<br>s<br>l<br>a<br>v<br>s<br>k<br>a<br>y<br>a<br> <br>&lt;<br>e<br>k<br>a<br>t<br>e<br>r<br>i<br>n<br>a<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>&gt;<br>,<br> <br>U<br>g<br>u<br>r<br> <br>S<br>e<br>n<br> <br>&lt;<br>u<br>g<br>u<br>r<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>&gt;<br>,<br> <br>K<br>s<br>r<br> <br>&lt;<br>k<br>s<br>r<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>&gt;</td></tr>
+</table>
+</div>
 ## Motivation

 The need for secure communications has become paramount.  
--- a/docs/vac/raw/gossipsub-tor-push.md
+++ b/docs/vac/raw/gossipsub-tor-push.md
@@ -1,13 +1,13 @@
---
-title: GOSSIPSUB-TOR-PUSH
-name: Gossipsub Tor Push
-status: raw
-category: Standards Track
-tags:
-editor: Daniel Kaiser <danielkaiser@status.im>
-contributors:
---
+# GOSSIPSUB-TOR-PUSH

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Gossipsub Tor Push</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Daniel Kaiser &lt;danielkaiser@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document extends the [libp2p gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
--- a/docs/vac/raw/logos-capability-discovery.md
+++ b/docs/vac/raw/logos-capability-discovery.md
@@ -1,14 +1,14 @@
---
-title: LOGOS-CAPABILITY-DISCOVERY
-name: Logos Capability Discovery Protocol
-status: raw
-category: Standards Track
-tags:
-editor: Arunima Chaudhuri [arunima@status.im](mailto:arunima@status.im)
-contributors: Ugur Sen [ugur@status.im](mailto:ugur@status.im)
-
---
+# LOGOS-CAPABILITY-DISCOVERY

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Logos Capability Discovery Protocol</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Arunima Chaudhuri [arunima@status.im](mailto:arunima@status.im)</td></tr>
+<tr><th>Contributors</th><td>U<br>g<br>u<br>r<br> <br>S<br>e<br>n<br> <br>[<br>u<br>g<br>u<br>r<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>]<br>(<br>m<br>a<br>i<br>l<br>t<br>o<br>:<br>u<br>g<br>u<br>r<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>)</td></tr>
+</table>
+</div>
 > **Note:** This specification is currently a WIP and undergoing a high rate of changes.

 ## Abstract
--- a/docs/vac/raw/mix.md
+++ b/docs/vac/raw/mix.md
@@ -1,13 +1,14 @@
---
-title: LIBP2P-MIX
-name: Libp2p Mix Protocol
-status: raw
-category: Standards Track
-tags:
-editor: Prem Prathi <premprathi@proton.me>
-contributors: Akshaya Mani <akshaya@status.im>, Daniel Kaiser <danielkaiser@status.im>
---
+# LIBP2P-MIX

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Libp2p Mix Protocol</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Prem Prathi &lt;premprathi@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>A<br>k<br>s<br>h<br>a<br>y<br>a<br> <br>M<br>a<br>n<br>i<br> <br>&lt;<br>a<br>k<br>s<br>h<br>a<br>y<br>a<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>&gt;<br>,<br> <br>D<br>a<br>n<br>i<br>e<br>l<br> <br>K<br>a<br>i<br>s<br>e<br>r<br> <br>&lt;<br>d<br>a<br>n<br>i<br>e<br>l<br>k<br>a<br>i<br>s<br>e<br>r<br>@<br>s<br>t<br>a<br>t<br>u<br>s<br>.<br>i<br>m<br>&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 The Mix Protocol defines a decentralized anonymous message routing layer for libp2p networks.
--- a/docs/vac/raw/noise-x3dh-double-ratchet.md
+++ b/docs/vac/raw/noise-x3dh-double-ratchet.md
@@ -1,13 +1,13 @@
---
-title: NOISE-X3DH-DOUBLE-RATCHET
-name: Secure 1-to-1 channel setup using X3DH and the double ratchet
-status: raw
-category: Standards Track
-tags:
-editor: Ramses Fernandez <ramses@status.im>
-contributors:
---
+# NOISE-X3DH-DOUBLE-RATCHET

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Secure 1-to-1 channel setup using X3DH and the double ratchet</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Ramses Fernandez &lt;ramses@status.im&gt;</td></tr>
+</table>
+</div>
 ## Motivation

 The need for secure communications has become paramount.
--- a/docs/vac/raw/rln-interep-spec.md
+++ b/docs/vac/raw/rln-interep-spec.md
@@ -1,13 +1,12 @@
---
-title: RLN-INTEREP-SPEC
-name: Interep as group management for RLN
-status: raw
-category:  
-tags: rln
-editor: Aaryamann Challani <p1ge0nh8er@proton.me>
-contributors:
---
+# RLN-INTEREP-SPEC

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Interep as group management for RLN</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This spec integrates [Interep](https://interep.link)
--- a/docs/vac/raw/rln-stealth-commitments.md
+++ b/docs/vac/raw/rln-stealth-commitments.md
@@ -1,12 +1,13 @@
---
-title: RLN-STEALTH-COMMITMENTS
-name: RLN Stealth Commitment Usage
-category: Standards Track
-editor: Aaryamann Challani <p1ge0nh8er@proton.me>
-contributors:
- Jimmy Debe <jimmy@status.im>
---
+# RLN-STEALTH-COMMITMENTS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>RLN Stealth Commitment Usage</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>Jimmy Debe &lt;jimmy@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes the usage of stealth commitments
--- a/docs/vac/raw/rln-v2.md
+++ b/docs/vac/raw/rln-v2.md
@@ -1,12 +1,13 @@
---
-title: RLN-V2
-name: Rate Limit Nullifier V2
-status: raw
-editor: Rasul Ibragimov <curryrasul@gmail.com>
-contributors: 
- Lev Soukhanov <0xdeadfae@gmail.com>
---
+# RLN-V2

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Rate Limit Nullifier V2</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Editor</th><td>Rasul Ibragimov &lt;curryrasul@gmail.com&gt;</td></tr>
+<tr><th>Contributors</th><td>Lev Soukhanov &lt;0xdeadfae@gmail.com&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 The protocol specified in this document is an improvement of [32/RLN-V1](../32/rln-v1.md),
--- a/docs/vac/raw/sds.md
+++ b/docs/vac/raw/sds.md
@@ -1,12 +1,13 @@
---
-title: SDS
-name: Scalable Data Sync protocol for distributed logs
-status: raw
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
-  - Akhil Peddireddy <akhil@status.im>
---
+# SDS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Scalable Data Sync protocol for distributed logs</td></tr>
+<tr><th>Status</th><td>raw</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Akhil Peddireddy &lt;akhil@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification introduces the Scalable Data Sync (SDS) protocol
--- a/docs/vac/template.md
+++ b/docs/vac/template.md
@@ -1,14 +1,14 @@
---
-slug: XX
-title: TEMPLATE
-name: RFC Template
-status: raw/draft/stable/deprecated
-category: Standards Track/Informational/Best Current Practice
-tags: an optional list of tags, not standard
-editor: Daniel Kaiser <danielkaiser@status.im>
-contributors:
---
+# TEMPLATE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>RFC Template</td></tr>
+<tr><th>Slug</th><td>XX</td></tr>
+<tr><th>Status</th><td>raw/draft/stable/deprecated</td></tr>
+<tr><th>Category</th><td>Standards Track/Informational/Best Current Practice</td></tr>
+<tr><th>Editor</th><td>Daniel Kaiser &lt;danielkaiser@status.im&gt;</td></tr>
+</table>
+</div>
 ## (Info, remove this section)

 This section contains meta info about writing RFCs.
--- a/docs/waku/deprecated/16/rpc.md
+++ b/docs/waku/deprecated/16/rpc.md
@@ -1,12 +1,13 @@
---
-slug: 16
-title: 16/WAKU2-RPC
-name: Waku v2 RPC API
-status: deprecated
-tags: waku-core
-editor: Hanno Cornelius <hanno@status.im>
---
+# 16/WAKU2-RPC

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 RPC API</td></tr>
+<tr><th>Slug</th><td>16</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+</table>
+</div>
 ## Introduction

 This specification describes the JSON-RPC API that Waku v2 nodes MAY adhere to.
--- a/docs/waku/deprecated/18/swap.md
+++ b/docs/waku/deprecated/18/swap.md
@@ -1,12 +1,13 @@
---
-slug: 18
-title: 18/WAKU2-SWAP
-name: Waku SWAP Accounting
-status: deprecated
-editor: Oskar Thorén <oskarth@titanproxy.com>
-contributor: Ebube Ud <ebube@status.im>
---
+# 18/WAKU2-SWAP

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku SWAP Accounting</td></tr>
+<tr><th>Slug</th><td>18</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification outlines how we do accounting and settlement based on the provision
--- a/docs/waku/deprecated/5/waku0.md
+++ b/docs/waku/deprecated/5/waku0.md
@@ -1,16 +1,14 @@
---
-slug: 5
-title: 5/WAKU0
-name: Waku v0
-status: deprecated
-editor: Oskar Thorén <oskarth@titanproxy.com>
-contributors:
-  - Adam Babik <adam@status.im>
-  - Andrea Maria Piana <andreap@status.im>
-  - Dean Eigenmann <dean@status.im>
-  - Kim De Mey <kimdemey@status.im>
---
+# 5/WAKU0

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v0</td></tr>
+<tr><th>Slug</th><td>5</td></tr>
+<tr><th>Status</th><td>deprecated</td></tr>
+<tr><th>Editor</th><td>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+<tr><th>Contributors</th><td>Adam Babik &lt;adam@status.im&gt;<br>Andrea Maria Piana &lt;andreap@status.im&gt;<br>Dean Eigenmann &lt;dean@status.im&gt;<br>Kim De Mey &lt;kimdemey@status.im&gt;</td></tr>
+</table>
+</div>
 This specification describes the format of Waku messages within the ÐΞVp2p Wire Protocol.
 This spec substitutes [EIP-627](https://eips.ethereum.org/EIPS/eip-627).
 Waku is a fork of the original Whisper protocol that enables better usability
--- a/docs/waku/deprecated/fault-tolerant-store.md
+++ b/docs/waku/deprecated/fault-tolerant-store.md
@@ -1,12 +1,13 @@
---
-slug: 21
-title: 21/WAKU2-FAULT-TOLERANT-STORE
-name: Waku v2 Fault-Tolerant Store
-status: deleted
-editor: Sanaz Taheri <sanaz@status.im>
-contributors:
---
+# 21/WAKU2-FAULT-TOLERANT-STORE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Fault-Tolerant Store</td></tr>
+<tr><th>Slug</th><td>21</td></tr>
+<tr><th>Status</th><td>deleted</td></tr>
+<tr><th>Editor</th><td>Sanaz Taheri &lt;sanaz@status.im&gt;</td></tr>
+</table>
+</div>
 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
--- a/docs/waku/informational/22/toy-chat.md
+++ b/docs/waku/informational/22/toy-chat.md
@@ -1,14 +1,14 @@
---
-slug: 22
-title: 22/TOY-CHAT
-name: Waku v2 Toy Chat
-status: draft
-tags: waku/application
-editor: Franck Royer <franck@status.im>
-contributors:
-   - Hanno Cornelius <hanno@status.im>
---
+# 22/TOY-CHAT

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Toy Chat</td></tr>
+<tr><th>Slug</th><td>22</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Franck Royer &lt;franck@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+</table>
+</div>
 **Content Topic**: `/toy-chat/2/huilong/proto`.

 This specification explains a toy chat example using Waku v2.
--- a/docs/waku/informational/23/topics.md
+++ b/docs/waku/informational/23/topics.md
@@ -1,16 +1,15 @@
---
-slug: 23
-title: 23/WAKU2-TOPICS
-name: Waku v2 Topic Usage Recommendations
-status: draft
-category: Informational
-editor: Oskar Thoren <oskarth@titanproxy.com>
-contributors:
-  - Hanno Cornelius <hanno@status.im>
-  - Daniel Kaiser <danielkaiser@status.im>
-  - Filip Dimitrijevic <filip@status.im>
---
+# 23/WAKU2-TOPICS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Topic Usage Recommendations</td></tr>
+<tr><th>Slug</th><td>23</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Informational</td></tr>
+<tr><th>Editor</th><td>Oskar Thoren &lt;oskarth@titanproxy.com&gt;</td></tr>
+<tr><th>Contributors</th><td>Hanno Cornelius &lt;hanno@status.im&gt;<br>Daniel Kaiser &lt;danielkaiser@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 This document outlines recommended usage of topic names in Waku v2.
 In [10/WAKU2 spec](/waku/standards/core/10/waku2.md) there are two types of topics:

--- a/docs/waku/informational/27/peers.md
+++ b/docs/waku/informational/27/peers.md
@@ -1,13 +1,14 @@
---
-slug: 27
-title: 27/WAKU2-PEERS
-name: Waku v2 Client Peer Management Recommendations
-status: draft
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
- - Filip Dimitrijevic <filip@status.im>
---
+# 27/WAKU2-PEERS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Client Peer Management Recommendations</td></tr>
+<tr><th>Slug</th><td>27</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 `27/WAKU2-PEERS` describes a recommended minimal set of peer storage and
 peer management features to be implemented by Waku v2 clients.

--- a/docs/waku/informational/29/config.md
+++ b/docs/waku/informational/29/config.md
@@ -1,13 +1,14 @@
---
-slug: 29
-title: 29/WAKU2-CONFIG
-name: Waku v2 Client Parameter Configuration Recommendations
-status: draft
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
- - Filip Dimitrijevic <filip@status.im>
---
+# 29/WAKU2-CONFIG

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Client Parameter Configuration Recommendations</td></tr>
+<tr><th>Slug</th><td>29</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 `29/WAKU2-CONFIG` describes the RECOMMENDED values
 to assign to configurable parameters for Waku v2 clients.
 Since Waku v2 is built on [libp2p](https://github.com/libp2p/specs),
--- a/docs/waku/informational/30/adaptive-nodes.md
+++ b/docs/waku/informational/30/adaptive-nodes.md
@@ -1,13 +1,14 @@
---
-slug: 30
-title: 30/ADAPTIVE-NODES
-name: Adaptive nodes
-status: draft
-editor: Oskar Thorén <oskarth@titanproxy.com>
-contributors:
- - Filip Dimitrijevic <filip@status.im>
---
+# 30/ADAPTIVE-NODES

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Adaptive nodes</td></tr>
+<tr><th>Slug</th><td>30</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+<tr><th>Contributors</th><td>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 This is an informational spec that show cases the concept of adaptive nodes.

 ## Node types - a continuum
--- a/docs/waku/informational/README.md
+++ b/docs/waku/informational/README.md
@@ -0,0 +1,3 @@
+# Waku Informational RFCs
+
+Informational Waku documents covering guidance, examples, and supporting material.
--- a/docs/waku/standards/application/20/toy-eth-pm.md
+++ b/docs/waku/standards/application/20/toy-eth-pm.md
@@ -1,13 +1,13 @@
---
-slug: 20
-title: 20/TOY-ETH-PM
-name: Toy Ethereum Private Message
-status: draft
-tags: waku/application
-editor: Franck Royer <franck@status.im>
-contributors:
---
+# 20/TOY-ETH-PM

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Toy Ethereum Private Message</td></tr>
+<tr><th>Slug</th><td>20</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Franck Royer &lt;franck@status.im&gt;</td></tr>
+</table>
+</div>
 **Content Topics**:

 - Public Key Broadcast: `/eth-pm/1/public-key/proto`
--- a/docs/waku/standards/application/26/payload.md
+++ b/docs/waku/standards/application/26/payload.md
@@ -1,13 +1,14 @@
---
-slug: 26
-title: 26/WAKU2-PAYLOAD
-name: Waku Message Payload Encryption
-status: draft
-editor: Oskar Thoren <oskarth@titanproxy.com>
-contributors:
- Oskar Thoren <oskarth@titanproxy.com>
---
+# 26/WAKU2-PAYLOAD

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku Message Payload Encryption</td></tr>
+<tr><th>Slug</th><td>26</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Oskar Thoren &lt;oskarth@titanproxy.com&gt;</td></tr>
+<tr><th>Contributors</th><td>Oskar Thoren &lt;oskarth@titanproxy.com&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes how Waku provides confidentiality, authenticity, and
--- a/docs/waku/standards/application/53/x3dh.md
+++ b/docs/waku/standards/application/53/x3dh.md
@@ -1,20 +1,15 @@
---
-slug: 53
-title: 53/WAKU2-X3DH
-name: X3DH usage for Waku payload encryption
-status: draft
-category: Standards Track
-tags: waku-application
-editor: Aaryamann Challani <p1ge0nh8er@proton.me>
-contributors:
- - Andrea Piana <andreap@status.im>
- - Pedro Pombeiro <pedro@status.im>
- - Corey Petty <corey@status.im>
- - Oskar Thorén <oskarth@titanproxy.com>
- - Dean Eigenmann <dean@status.im>
- - Filip Dimitrijevic <filip@status.im>
---
+# 53/WAKU2-X3DH

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>X3DH usage for Waku payload encryption</td></tr>
+<tr><th>Slug</th><td>53</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Piana &lt;andreap@status.im&gt;<br>Pedro Pombeiro &lt;pedro@status.im&gt;<br>Corey Petty &lt;corey@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Dean Eigenmann &lt;dean@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document describes a method that can be used to provide a secure channel
--- a/docs/waku/standards/application/54/x3dh-sessions.md
+++ b/docs/waku/standards/application/54/x3dh-sessions.md
@@ -1,20 +1,15 @@
---
-slug: 54
-title: 54/WAKU2-X3DH-SESSIONS
-name: Session management for Waku X3DH 
-status: draft
-category: Standards Track
-tags: waku-application
-editor: Aaryamann Challani <p1ge0nh8er@proton.me>
-contributors:
- - Andrea Piana <andreap@status.im>
- - Pedro Pombeiro <pedro@status.im>
- - Corey Petty <corey@status.im>
- - Oskar Thorén <oskarth@titanproxy.com>
- - Dean Eigenmann <dean@status.im>
- - Filip Dimitrijevic <filip@status.im>
---
+# 54/WAKU2-X3DH-SESSIONS

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Session management for Waku X3DH</td></tr>
+<tr><th>Slug</th><td>54</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
+<tr><th>Contributors</th><td>Andrea Piana &lt;andreap@status.im&gt;<br>Pedro Pombeiro &lt;pedro@status.im&gt;<br>Corey Petty &lt;corey@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Dean Eigenmann &lt;dean@status.im&gt;<br>Filip Dimitrijevic &lt;filip@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This document specifies how to manage sessions based on an X3DH key exchange.
--- a/docs/waku/standards/application/README.md
+++ b/docs/waku/standards/application/README.md
@@ -0,0 +1,3 @@
+# Waku Standards - Application
+
+Application-layer specifications built on top of Waku core protocols.
--- a/docs/waku/standards/core/10/waku2.md
+++ b/docs/waku/standards/core/10/waku2.md
@@ -1,16 +1,36 @@
---
-slug: 10
-title: 10/WAKU2
-name: Waku v2
-status: draft
-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>
---
+# 10/WAKU2
+
+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2</td></tr>
+<tr><th>Slug</th><td>10</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Sanaz Taheri &lt;sanaz@status.im&gt;<br>Hanno Cornelius &lt;hanno@status.im&gt;<br>Reeshav Khan &lt;reeshav@status.im&gt;<br>Daniel Kaiser &lt;danielkaiser@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+</table>
+</div>
+<!-- timeline:start -->
+
+## Timeline
+
+- **2025-12-18** — [`d03e699`](https://github.com/vacp2p/rfc-index/blob/d03e699084774ebecef9c6d4662498907c5e2080/docs/waku/standards/core/10/waku2.md) — ci: add mdBook configuration (#233)
+- **2025-04-15** — [`34aa3f3`](https://github.com/vacp2p/rfc-index/blob/34aa3f3647cd5f0ae6a9af7fad47c3c8ee32c866/waku/standards/core/10/waku2.md) — Fix links 10/WAKU2 (#153)
+- **2025-04-09** — [`cafa04f`](https://github.com/vacp2p/rfc-index/blob/cafa04fb93c461034e1754cf750409a6236cf6ee/waku/standards/core/10/waku2.md) — 10/WAKU2: Update (#125)
+- **2024-11-20** — [`ff87c84`](https://github.com/vacp2p/rfc-index/blob/ff87c84dc71d4f933bab188993914069fea12baa/waku/standards/core/10/waku2.md) — Update Waku Links (#104)
+- **2024-09-13** — [`3ab314d`](https://github.com/vacp2p/rfc-index/blob/3ab314d87d4525ff1296bf3d9ec634d570777b91/waku/standards/core/10/waku2.md) — Fix Files for Linting (#94)
+- **2024-03-21** — [`2eaa794`](https://github.com/vacp2p/rfc-index/blob/2eaa7949c4abe7d14e2b9560e8c045bf2e937c9a/waku/standards/core/10/waku2.md) — Broken Links + Change Editors (#26)
+- **2024-02-01** — [`8e14d58`](https://github.com/vacp2p/rfc-index/blob/8e14d584bf90f59aab790c9b8e62dd6adf5da100/waku/standards/core/10/waku2.md) — Update waku2.md
+- **2024-02-01** — [`6cf68fd`](https://github.com/vacp2p/rfc-index/blob/6cf68fd03e35f5889a827d0e7d053879e2162a4e/waku/standards/core/10/waku2.md) — Update waku2.md
+- **2024-02-01** — [`6734b16`](https://github.com/vacp2p/rfc-index/blob/6734b1690817d1647feeccc07f28c13fc1c3b789/waku/standards/core/10/waku2.md) — Update waku2.md
+- **2024-01-31** — [`356649a`](https://github.com/vacp2p/rfc-index/blob/356649a5b690dd56f7de42961eeeeb676dd71b88/waku/standards/core/10/waku2.md) — Update and rename WAKU2.md to waku2.md
+- **2024-01-27** — [`550238c`](https://github.com/vacp2p/rfc-index/blob/550238ca71eb03506d400db579d8fdbab1acd6ad/waku/standards/core/10/WAKU2.md) — Rename README.md to WAKU2.md
+- **2024-01-27** — [`eef961b`](https://github.com/vacp2p/rfc-index/blob/eef961bfe3b1cf6aab66df5450555afd1d3543cb/waku/standards/core/10-WAKU2/README.md) — remove rfs folder
+- **2024-01-26** — [`d6651b7`](https://github.com/vacp2p/rfc-index/blob/d6651b7f2a72974685871b3c25c7514dd5a4e679/waku/rfcs/standards/core/10-WAKU2/README.md) — Update README.md
+- **2024-01-25** — [`6e98666`](https://github.com/vacp2p/rfc-index/blob/6e98666f71f01fd5fa348ba71d8d55a265891a80/waku/rfcs/standards/core/10-WAKU2/README.md) — Rename README.md to README.md
+- **2024-01-25** — [`9b740d8`](https://github.com/vacp2p/rfc-index/blob/9b740d887522349f8d9c80c580d3777d7f6f63af/waku/specs/standards/core/10-WAKU2/README.md) — Rename waku/10/README.md to waku/specs/standards/core/10-WAKU2/README.md
+- **2024-01-24** — [`330c35b`](https://github.com/vacp2p/rfc-index/blob/330c35b56eecf3876c8246fbddb9e40b5211b566/waku/10/README.md) — Create README.md
+
+<!-- timeline:end -->

 ## Abstract

--- a/docs/waku/standards/core/11/relay.md
+++ b/docs/waku/standards/core/11/relay.md
@@ -1,15 +1,14 @@
---
-slug: 11
-title: 11/WAKU2-RELAY
-name: Waku v2 Relay
-status: stable
-tags: waku-core
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
-  - Oskar Thorén <oskarth@titanproxy.com>
-  - Sanaz Taheri <sanaz@status.im>
---
+# 11/WAKU2-RELAY

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Relay</td></tr>
+<tr><th>Slug</th><td>11</td></tr>
+<tr><th>Status</th><td>stable</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Sanaz Taheri &lt;sanaz@status.im&gt;</td></tr>
+</table>
+</div>
 `11/WAKU2-RELAY` specifies a [Publish/Subscribe approach](https://docs.libp2p.io/concepts/publish-subscribe/)
 to peer-to-peer messaging with a strong focus on privacy,
 censorship-resistance, security and scalability.
--- a/docs/waku/standards/core/12/filter.md
+++ b/docs/waku/standards/core/12/filter.md
@@ -1,18 +1,14 @@
---
-slug: 12
-title: 12/WAKU2-FILTER
-name: Waku v2 Filter
-status: draft
-tags: waku-core
-version: 01
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
-  - Dean Eigenmann <dean@status.im>
-  - Oskar Thorén <oskar@status.im>
-  - Sanaz Taheri <sanaz@status.im>
-  - Ebube Ud <ebube@status.im>
---
+# 12/WAKU2-FILTER

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Filter</td></tr>
+<tr><th>Slug</th><td>12</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Dean Eigenmann &lt;dean@status.im&gt;<br>Oskar Thorén &lt;oskar@status.im&gt;<br>Sanaz Taheri &lt;sanaz@status.im&gt;<br>Ebube Ud &lt;ebube@status.im&gt;</td></tr>
+</table>
+</div>
 previous versions: [00](/waku/standards/core/12/previous-versions/00/filter.md)

 **Protocol identifiers**:
--- a/docs/waku/standards/core/12/previous-versions/00/filter.md
+++ b/docs/waku/standards/core/12/previous-versions/00/filter.md
@@ -1,19 +1,14 @@
---
-slug: 12
-title: 12/WAKU2-FILTER
-name: Waku v2 Filter
-status: draft
-tags: waku-core
-version: v00
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
-  - Dean Eigenmann <dean@status.im>
-  - Oskar Thorén <oskarth@titanproxy.com>
-  - Sanaz Taheri <sanaz@status.im>
-  - Ebube Ud <ebube@status.im>
---
-
+# 12/WAKU2-FILTER

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Filter</td></tr>
+<tr><th>Slug</th><td>12</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Dean Eigenmann &lt;dean@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Sanaz Taheri &lt;sanaz@status.im&gt;<br>Ebube Ud &lt;ebube@status.im&gt;</td></tr>
+</table>
+</div>
 `WakuFilter` is a protocol that enables subscribing to messages that a peer receives.
 This is a more lightweight version of `WakuRelay`
 specifically designed for bandwidth restricted devices.
--- a/docs/waku/standards/core/13/previous-versions/00/store.md
+++ b/docs/waku/standards/core/13/previous-versions/00/store.md
@@ -1,19 +1,14 @@
---
-slug: 13
-title: 13/WAKU2-STORE
-name: Waku v2 Store
-status: draft
-tags: waku-core
-version: 00
-editor: Simon-Pierre Vivier <simvivier@status.im>
-contributors:
-  - Dean Eigenmann <dean@status.im>
-  - Oskar Thorén <oskarth@titanproxy.com>
-  - Aaryamann Challani <p1ge0nh8er@proton.me>
-  - Sanaz Taheri <sanaz@status.im>
-  - Hanno Cornelius <hanno@status.im>
---
+# 13/WAKU2-STORE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Store</td></tr>
+<tr><th>Slug</th><td>13</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Simon-Pierre Vivier &lt;simvivier@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Dean Eigenmann &lt;dean@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;<br>Sanaz Taheri &lt;sanaz@status.im&gt;<br>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification explains the `13/WAKU2-STORE` protocol
--- a/docs/waku/standards/core/13/store.md
+++ b/docs/waku/standards/core/13/store.md
@@ -1,17 +1,14 @@
---
-slug: 13
-title: 13/WAKU2-STORE
-name: Waku Store Query
-status: draft
-tags: waku-core
-version: 01
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
-  - Dean Eigenmann <dean@status.im>
-  - Oskar Thorén <oskarth@titanproxy.com>
-  - Aaryamann Challani <p1ge0nh8er@proton.me>
-  - Sanaz Taheri <sanaz@status.im>
---
+# 13/WAKU2-STORE
+
+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku Store Query</td></tr>
+<tr><th>Slug</th><td>13</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Dean Eigenmann &lt;dean@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;<br>Sanaz Taheri &lt;sanaz@status.im&gt;</td></tr>
+</table>
+</div>
 Previous version: [00](/waku/standards/core/13/previous-versions/00/store.md)

 ## Abstract
--- a/docs/waku/standards/core/14/message.md
+++ b/docs/waku/standards/core/14/message.md
@@ -1,19 +1,15 @@
---
-slug: 14
-title: 14/WAKU2-MESSAGE
-name: Waku v2 Message
-status: stable
-category: Standards Track
-tags: waku/core-protocol
-editor: Hanno Cornelius <hanno@status.im>
-contributors:
-  - Sanaz Taheri <sanaz@status.im>
-  - Aaryamann Challani <p1ge0nh8er@proton.me>
-  - Lorenzo Delgado <lorenzo@status.im>
-  - Abhimanyu Rawat <abhi@status.im>
-  - Oskar Thorén <oskarth@titanproxy.com>
---
+# 14/WAKU2-MESSAGE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Message</td></tr>
+<tr><th>Slug</th><td>14</td></tr>
+<tr><th>Status</th><td>stable</td></tr>
+<tr><th>Category</th><td>Standards Track</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Sanaz Taheri &lt;sanaz@status.im&gt;<br>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;<br>Lorenzo Delgado &lt;lorenzo@status.im&gt;<br>Abhimanyu Rawat &lt;abhi@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 [10/WAKU2](/waku/standards/core/10/waku2.md) is a family of modular peer-to-peer protocols
--- a/docs/waku/standards/core/15/bridge.md
+++ b/docs/waku/standards/core/15/bridge.md
@@ -1,12 +1,13 @@
---
-slug: 15
-title: 15/WAKU-BRIDGE
-name: Waku Bridge
-status: draft
-tags: waku-core
-editor: Hanno Cornelius <hanno@status.im>
---
+# 15/WAKU-BRIDGE

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku Bridge</td></tr>
+<tr><th>Slug</th><td>15</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes how [6/WAKU1](/waku/standards/legacy/6/waku1.md)
--- a/docs/waku/standards/core/17/rln-relay.md
+++ b/docs/waku/standards/core/17/rln-relay.md
@@ -1,17 +1,14 @@
---
-slug: 17
-title: 17/WAKU2-RLN-RELAY
-name: Waku v2 RLN Relay
-status: draft
-tags: waku-core
-editor: Alvaro Revuelta <alvaro@status.im>
-contributors:
-  - Oskar Thorén <oskarth@titanproxy.com>
-  - Aaryamann Challani <p1ge0nh8er@proton.me>
-  - Sanaz Taheri <sanaz@status.im>
-  - Hanno Cornelius <hanno@status.im>
---
+# 17/WAKU2-RLN-RELAY

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 RLN Relay</td></tr>
+<tr><th>Slug</th><td>17</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Alvaro Revuelta &lt;alvaro@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Oskar Thorén &lt;oskarth@titanproxy.com&gt;<br>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;<br>Sanaz Taheri &lt;sanaz@status.im&gt;<br>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+</table>
+</div>
 ## Abstract

 This specification describes the `17/WAKU2-RLN-RELAY` protocol,
--- a/docs/waku/standards/core/19/lightpush.md
+++ b/docs/waku/standards/core/19/lightpush.md
@@ -1,14 +1,14 @@
---
-slug: 19
-title: 19/WAKU2-LIGHTPUSH
-name: Waku v2 Light Push
-status: draft
-editor: Hanno Cornelius <hanno@status.im> 
-contributors: 
-  - Daniel Kaiser <danielkaiser@status.im>
-  - Oskar Thorén <oskarth@titanproxy.com>
---
+# 19/WAKU2-LIGHTPUSH

+<div class="rfc-meta">
+<table>
+<tr><th>Name</th><td>Waku v2 Light Push</td></tr>
+<tr><th>Slug</th><td>19</td></tr>
+<tr><th>Status</th><td>draft</td></tr>
+<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
+<tr><th>Contributors</th><td>Daniel Kaiser &lt;danielkaiser@status.im&gt;<br>Oskar Thorén &lt;oskarth@titanproxy.com&gt;</td></tr>
+</table>
+</div>
 **Protocol identifier**: `/vac/waku/lightpush/2.0.0-beta1`

 ## Motivation and Goals
--- a/Show More
+++ b/Show More