## Specification Status
This specification contains a mix of:
diff --git a/docs/codex/raw/codex-marketplace.md b/docs/codex/raw/codex-marketplace.md
index af7357a..df6cc0a 100644
--- 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
-contributors:
- - Mark Spanbroek
- - Adam Uhlíř
- - Eric Mastro
- - Jimmy Debe
- - Filip Dimitrijevic
----
+# CODEX-MARKETPLACE
+
+
+
Name
Codex Storage Marketplace
+
Slug
codex-marketplace
+
Status
raw
+
Category
Standards Track
+
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>
+
+
## 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.
diff --git a/docs/nomos/deprecated/README.md b/docs/nomos/deprecated/README.md
new file mode 100644
index 0000000..6908a7b
--- /dev/null
+++ b/docs/nomos/deprecated/README.md
@@ -0,0 +1,3 @@
+# Nomos Deprecated Specifications
+
+Deprecated Nomos specifications kept for archival and reference purposes.
diff --git a/docs/nomos/deprecated/claro.md b/docs/nomos/deprecated/claro.md
index 055a7e5..5fd8dd9 100644
--- 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
-created: 01-JUL-2022
-revised: <2022-08-26 Fri 13:11Z>
-uri:
-contributors:
- - Álvaro Castro-Castilla
- - Mark Evenson
----
+# CONSENSUS-CLARO
+
+
+
Name
Claro Consensus Protocol
+
Status
deprecated
+
Category
Standards Track
+
Editor
Corey Petty <corey@status.im>
+
Contributors
Álvaro Castro-Castilla Mark Evenson
+
+
## Abstract
This document specifies Claro: a Byzantine, fault-tolerant, binary decision
diff --git a/docs/nomos/raw/README.md b/docs/nomos/raw/README.md
new file mode 100644
index 0000000..abbe5bc
--- /dev/null
+++ 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.
diff --git a/docs/nomos/raw/nomosda-encoding.md b/docs/nomos/raw/nomosda-encoding.md
index 67c84f1..7b4265a 100644
--- 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
-contributors:
-- Daniel Kashepava
-- Álvaro Castro-Castilla
-- Filip Dimitrijevic
-- Thomas Lavaur
-- Mehmet Gonen
----
+# NOMOSDA-ENCODING
+
+
+
Name
NomosDA Encoding Protocol
+
Status
raw
+
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>
+
+
## 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.
diff --git a/docs/nomos/raw/nomosda-network.md b/docs/nomos/raw/nomosda-network.md
index 9b06743..8376790 100644
--- 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
-contributors:
-- Álvaro Castro-Castilla
-- Daniel Kashepava
-- Gusto Bacvinka
-- Filip Dimitrijevic
----
+# NOMOS-DA-NETWORK
+
+
+
Name
NomosDA Network
+
Status
raw
+
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>
+
+
## Introduction
NomosDA is the scalability solution protocol for data availability within the Nomos network.
diff --git a/docs/nomos/raw/p2p-hardware-requirements.md b/docs/nomos/raw/p2p-hardware-requirements.md
index 0a26007..5b59e1b 100644
--- 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
-contributors:
-- Filip Dimitrijevic
----
+# P2P-HARDWARE-REQUIREMENTS
+
## 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.
diff --git a/docs/nomos/raw/p2p-nat-solution.md b/docs/nomos/raw/p2p-nat-solution.md
index 4c71724..005bc02 100644
--- 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
-contributors:
-- Álvaro Castro-Castilla
-- Daniel Sanchez-Quiros
-- Petar Radovic
-- Gusto Bacvinka
-- Youngjoon Lee
-- Filip Dimitrijevic
----
+# P2P-NAT-SOLUTION
+
+
+
Name
Nomos P2P Network NAT Solution Specification
+
Status
raw
+
Category
networking
+
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>
+
+
## 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.
diff --git a/docs/nomos/raw/p2p-network-bootstrapping.md b/docs/nomos/raw/p2p-network-bootstrapping.md
index fd3a591..11758ff 100644
--- 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
-contributors:
-- Álvaro Castro-Castilla
-- Petar Radovic
-- Gusto Bacvinka
-- Antonio Antonino
-- Youngjoon Lee
-- Filip Dimitrijevic
----
+# P2P-NETWORK-BOOTSTRAPPING
+
+
+
Name
Nomos P2P Network Bootstrapping Specification
+
Status
raw
+
Category
networking
+
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>
+
+
## 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:
diff --git a/docs/nomos/raw/p2p-network.md b/docs/nomos/raw/p2p-network.md
index a75dfad..a67b43a 100644
--- 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
-contributors:
-- Filip Dimitrijevic
----
+# NOMOS-P2P-NETWORK
+
+
+
Name
Nomos P2P Network Specification
+
Status
draft
+
Category
networking
+
Editor
Daniel Sanchez-Quiros <danielsq@status.im>
+
Contributors
Filip Dimitrijevic <filip@status.im>
+
+
## 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.
diff --git a/docs/nomos/raw/sdp.md b/docs/nomos/raw/sdp.md
index 7857852..61965a1 100644
--- 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
-contributors:
-- Mehmet
-- Daniel Sanchez Quiros
-- Álvaro Castro-Castilla
-- Thomas Lavaur
-- Filip Dimitrijevic
-- Gusto Bacvinka
-- David Rusu
----
+# NOMOS-SDP
+
+
+
Name
Nomos Service Declaration Protocol Specification
+
Status
raw
+
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>
Status Community Directory Curation Voting using Waku v2
+
Slug
24
+
Status
draft
+
Editor
Szymon Szlachtowicz <szymon.s@ethworks.io>
+
+
## Abstract
This specification is a voting protocol for peers to submit votes to a smart contract.
diff --git a/docs/status/28/featuring.md b/docs/status/28/featuring.md
index 0c9b47d..78227e9 100644
--- 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
----
+# 28/STATUS-FEATURING
+
+
+
Name
Status community featuring using waku v2
+
Slug
28
+
Status
draft
+
Editor
Szymon Szlachtowicz <szymon.s@ethworks.io>
+
+
## Abstract
This specification describes a voting method to feature different active Status Communities.
diff --git a/docs/status/55/1to1-chat.md b/docs/status/55/1to1-chat.md
index 9c735bc..67c3318 100644
--- 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
-contributors:
-- Andrea Piana
-- Pedro Pombeiro
-- Corey Petty
-- Oskar Thorén
-- Dean Eigenmann
----
+# 55/STATUS-1TO1-CHAT
+
+
+
Name
Status 1-to-1 Chat
+
Slug
55
+
Status
draft
+
Category
Standards Track
+
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>
+
+
## Abstract
This specification describes how the Status 1-to-1 chat protocol is implemented
diff --git a/docs/status/56/communities.md b/docs/status/56/communities.md
index 795eb17..0948e21 100644
--- 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
-contributors:
-- Andrea Piana
-- Prem Chaitanya Prathi
----
+# 56/STATUS-COMMUNITIES
+
+
+
Name
Status Communities that run over Waku v2
+
Slug
56
+
Status
draft
+
Category
Standards Track
+
Editor
Aaryamann Challani <p1ge0nh8er@proton.me>
+
Contributors
Andrea Piana <andreap@status.im> Prem Chaitanya Prathi <prem@waku.org>
+
+
## Abstract
This document describes the design of Status Communities over Waku v2,
diff --git a/docs/status/61/community-history-service.md b/docs/status/61/community-history-service.md
index 6a19a8f..0e39657 100644
--- 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
-contributors:
- - Sanaz Taheri
- - John Lea
----
+# 61/STATUS-Community-History-Service
+
+
+
Name
Status Community History Service
+
Slug
61
+
Status
draft
+
Category
Standards Track
+
Editor
r4bbit <r4bbit@status.im>
+
Contributors
Sanaz Taheri <sanaz@status.im> John Lea <john@status.im>
+
+
## Abstract
Messages are stored permanently by store nodes
diff --git a/docs/status/62/payloads.md b/docs/status/62/payloads.md
index 56c257a..505ac1f 100644
--- 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
-contributors:
-- Adam Babik
-- Andrea Maria Piana
-- Oskar Thoren
-- Samuel Hawksby-Robinson
----
+# 62/STATUS-PAYLOADS
+
+
+
Name
Status Message Payloads
+
Slug
62
+
Status
draft
+
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>
+
+
## Abstract
This specification describes how the payload of each message in Status looks
diff --git a/docs/status/63/keycard-usage.md b/docs/status/63/keycard-usage.md
index 56144e7..9a1c39f 100644
--- 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
-contributors:
- - Jimmy Debe
----
+# 63/STATUS-Keycard-Usage
+
+
+
Name
Status Keycard Usage
+
Slug
63
+
Status
draft
+
Category
Standards Track
+
Editor
Aaryamann Challani <p1ge0nh8er@proton.me>
+
Contributors
Jimmy Debe <jimmy@status.im>
+
+
## Terminology
- **Account**: A valid
diff --git a/docs/status/65/account-address.md b/docs/status/65/account-address.md
index 18eab35..d57c91c 100644
--- 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
-contributors:
-- Corey Petty
-- Oskar Thorén
-- Samuel Hawksby-Robinson
----
+# 65/STATUS-ACCOUNT-ADDRESS
+
+
+
Name
Status Account Address
+
Slug
65
+
Status
draft
+
Category
Standards Track
+
Editor
Aaryamann Challani <p1ge0nh8er@proton.me>
+
Contributors
Corey Petty <corey@status.im> Oskar Thorén <oskarth@titanproxy.com> Samuel Hawksby-Robinson <samuel@status.im>
+
+
## Abstract
This specification details what a Status account address is and
diff --git a/docs/status/71/push-notification-server.md b/docs/status/71/push-notification-server.md
index 02966b2..4c6cd07 100644
--- 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
-contributors:
- - Andrea Maria Piana
----
+# 71/STATUS-PUSH-NOTIFICATION-SERVER
+
+
+
Name
Push Notification Server
+
Slug
71
+
Status
draft
+
Category
Standards Track
+
Editor
Jimmy Debe <jimmy@status.im>
+
Contributors
Andrea Maria Piana <andreap@status.im>
+
+
## Abstract
A push notification server implementation for IOS devices and Android devices.
diff --git a/docs/status/deprecated/3rd-party.md b/docs/status/deprecated/3rd-party.md
index 70d5dc7..8ad2728 100644
--- 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
-contributors:
- - Volodymyr Kozieiev
----
+# 3RD-PARTY
+
+
+
Name
3rd party
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Volodymyr Kozieiev <volodymyr@status.im>
+
+
## Abstract
This specification discusses 3rd party APIs that Status relies on.
diff --git a/docs/status/deprecated/IPFS-gateway-for-sticker-Pack.md b/docs/status/deprecated/IPFS-gateway-for-sticker-Pack.md
index 2a3ea93..43f6f17 100644
--- 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
-contributors:
- - Gheorghe Pinzaru
----
+# IPFS-gateway-for-Sticker-Pack
+
+
+
Name
IPFS gateway for Sticker Pack
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Gheorghe Pinzaru <gheorghe@status.im>
+
+
## Abstract
This specification describes how Status uses the IPFS gateway
diff --git a/docs/status/deprecated/README.md b/docs/status/deprecated/README.md
new file mode 100644
index 0000000..cb7fc9c
--- /dev/null
+++ b/docs/status/deprecated/README.md
@@ -0,0 +1,3 @@
+# Status Deprecated Specifications
+
+Deprecated Status specifications maintained for archival purposes.
diff --git a/docs/status/deprecated/account.md b/docs/status/deprecated/account.md
index 3175d24..3e6f777 100644
--- 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
-contributors:
- - Corey Petty
- - Oskar Thorén
- - Samuel Hawksby-Robinson
----
+# ACCOUNT
+
+
+
Name
Account
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Corey Petty <corey@status.im> Oskar Thorén <oskar@status.im> Samuel Hawksby-Robinson <samuel@status.im>
+
+
## Abstract
This specification explains what a Status account is,
diff --git a/docs/status/deprecated/client.md b/docs/status/deprecated/client.md
index cd68afc..83e1479 100644
--- 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
-contributors:
- - Adam Babik
- - Andrea Maria Piana
- - Dean Eigenmann
- - Corey Petty
- - Oskar Thorén
- - Samuel Hawksby-Robinson
----
+# CLIENT
+
+
+
Name
Client
+
Status
deprecated
+
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>
+
+
## Abstract
This specification describes how to write a Status client for communicating
diff --git a/docs/status/deprecated/dapp-browser-API-usage.md b/docs/status/deprecated/dapp-browser-API-usage.md
index ab39eb1..10b6a7b 100644
--- 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
-contributors:
----
+# Dapp browser API usage
+
+
+
Name
Dapp browser API usage
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
+
## Abstract
This document describes requirements that an application must fulfill in order to provide a proper environment for Dapps running inside a browser.
diff --git a/docs/status/deprecated/eips.md b/docs/status/deprecated/eips.md
index 3ef936a..ed92109 100644
--- 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
-contributors:
--
----
+# EIPS
+
+
+
Name
EIPS
+
Status
deprecated
+
Editor
Ricardo Guilherme Schmidt <ricardo3@status.im>
+
Contributors
None
+
+
## Abstract
This specification describes how Status relates with EIPs.
diff --git a/docs/status/deprecated/ethereum-usage.md b/docs/status/deprecated/ethereum-usage.md
index 9488750..55b939a 100644
--- 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
-contributors:
- - Andrea Maria Piana
----
+# ETHEREUM-USAGE
+
+
+
Name
Status interactions with the Ethereum blockchain
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Andrea Maria Piana <andreap@status.im>
+
+
## Abstract
This specification documents all the interactions that the Status client has
diff --git a/docs/status/deprecated/group-chat.md b/docs/status/deprecated/group-chat.md
index cd8e7b2..48a519c 100644
--- 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
-contributors:
- - Andrea Piana
----
+# GROUP-CHAT
+
+
+
Name
Group Chat
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Andrea Piana <andreap@status.im>
+
+
## Abstract
This document describes the group chat protocol used by the Status application.
diff --git a/docs/status/deprecated/keycard-usage-for-wallet-and-chat-keys.md b/docs/status/deprecated/keycard-usage-for-wallet-and-chat-keys.md
index d1aa1fd..bc2fe6c 100644
--- 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
-contributors:
- - Roman Volosovskyi
----
+# Keycard Usage for Wallet and Chat Keys
+
+
+
Name
Keycard Usage for Wallet and Chat Keys
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Roman Volosovskyi <roman@status.im>
+
+
## Abstract
In this specification, we describe how Status communicates with Keycard to create, store and use multiaccount.
diff --git a/docs/status/deprecated/notifications.md b/docs/status/deprecated/notifications.md
index ca00ecb..3bc2137 100644
--- 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
-contributors:
- - Eric Dvorsak
----
+# NOTIFICATIONS
+
+
+
+
Name
Notifications
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Eric Dvorsak <eric@status.im>
+
+
## Local Notifications
diff --git a/docs/status/deprecated/payloads.md b/docs/status/deprecated/payloads.md
index b2ddb7c..48dc40c 100644
--- 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
-contributors:
-- Adam Babik
-- Andrea Maria Piana
-- Oskar Thorén
----
+# PAYLOADS
+
+
+
Name
Payloads
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Adam Babik <adam@status.im> Andrea Maria Piana <andreap@status.im> Oskar Thorén <oskar@status.im>
+
+
## Abstract
This specification describes how the payload of each message in Status looks like.
diff --git a/docs/status/deprecated/push-notification-server.md b/docs/status/deprecated/push-notification-server.md
index 2d90701..6613acf 100644
--- 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
-contributors:
- - Andrea Maria Piana
----
+# PUSH-NOTIFICATION-SERVER
+
+
+
Name
Push notification server
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Andrea Maria Piana <andreap@status.im>
+
+
## 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/).
diff --git a/docs/status/deprecated/secure-transport.md b/docs/status/deprecated/secure-transport.md
index 4d786b5..1f93165 100644
--- 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
-contributors:
- - Andrea Maria Piana
- - Corey Petty
- - Dean Eigenmann
- - Oskar Thorén
- - Pedro Pombeiro
----
+# SECURE-TRANSPORT
+
+
+
Name
Secure Transport
+
Status
deprecated
+
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>
+
+
## Abstract
This document describes how Status provides a secure channel between two peers,
diff --git a/docs/status/deprecated/waku-mailserver.md b/docs/status/deprecated/waku-mailserver.md
index b8082d4..b5eca01 100644
--- 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
-contributors:
- - Adam Babik
- - Oskar Thorén
- - Samuel Hawksby-Robinson
----
+# WAKU-MAILSERVER
+
+
+
Name
Waku Mailserver
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Adam Babik <adam@status.im> Oskar Thorén <oskar@status.im> Samuel Hawksby-Robinson <samuel@status.im>
+
+
## Abstract
Being mostly offline is an intrinsic property of mobile clients.
diff --git a/docs/status/deprecated/waku-usage.md b/docs/status/deprecated/waku-usage.md
index 2b242ef..7494bea 100644
--- 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
-contributors:
- - Adam Babik
- - Corey Petty
- - Oskar Thorén
- - Samuel Hawksby-Robinson
----
+# WAKU-USAGE
+
+
+
Name
Waku Usage
+
Status
deprecated
+
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>
+
+
## Abstract
Status uses [Waku](/waku/standards/legacy/6/waku1.md) to provide privacy-preserving routing
diff --git a/docs/status/deprecated/whisper-mailserver.md b/docs/status/deprecated/whisper-mailserver.md
index 7fa7600..da87632 100644
--- 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
-contributors:
- - Adam Babik
- - Oskar Thorén
----
+# WHISPER-MAILSERVER
+
+
+
Name
Whisper mailserver
+
Status
deprecated
+
Editor
Filip Dimitrijevic <filip@status.im>
+
Contributors
Adam Babik <adam@status.im> Oskar Thorén <oskar@status.im>
+
+
## Abstract
Being mostly offline is an intrinsic property of mobile clients.
diff --git a/docs/status/deprecated/whisper-usage.md b/docs/status/deprecated/whisper-usage.md
index 3ebfdf4..f5d095a 100644
--- 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
-contributors:
- - Adam Babik
- - Andrea Piana
- - Corey Petty
- - Oskar Thorén
----
+# WHISPER-USAGE
+
+
+
Name
Whisper Usage
+
Status
deprecated
+
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>
+
+
## Abstract
Status uses [Whisper](https://eips.ethereum.org/EIPS/eip-627) to provide
diff --git a/docs/status/raw/README.md b/docs/status/raw/README.md
new file mode 100644
index 0000000..a0fca64
--- /dev/null
+++ b/docs/status/raw/README.md
@@ -0,0 +1,3 @@
+# Status Raw Specifications
+
+Early-stage Status specifications that precede draft or stable status.
diff --git a/docs/status/raw/simple-scaling.md b/docs/status/raw/simple-scaling.md
index e8516b6..c06fa73 100644
--- 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
-contributors:
-- Alvaro Revuelta
----
+# STATUS-SIMPLE-SCALING
+
+
+
Name
Status Simple Scaling
+
Status
raw
+
Category
Informational
+
Editor
Daniel Kaiser <danielkaiser@status.im>
+
Contributors
Alvaro Revuelta <alrevuelta@status.im>
+
+
## Abstract
This document describes how to scale
diff --git a/docs/status/raw/status-app-protocols.md b/docs/status/raw/status-app-protocols.md
index 9a1fcc6..8cc52d7 100644
--- 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
-contributors:
-- Jimmy Debe
-- Aaryamann Challani
-
----
+# STATUS-PROTOCOLS
+
+
+
Name
Status Protocol Stack
+
Status
raw
+
Category
Standards Track
+
Editor
Hanno Cornelius <hanno@status.im>
+
Contributors
Jimmy Debe <jimmy@status.im> Aaryamann Challani <p1ge0nh8er@proton.me>
+
+
## Abstract
This specification describes the Status Application protocol stack.
diff --git a/docs/status/raw/status-mvds.md b/docs/status/raw/status-mvds.md
index 465d36e..ee82964 100644
--- 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
-contributors:
----
+# STATUS-MVDS-USAGE
+
+
+
Name
MVDS Usage in Status
+
Status
raw
+
Category
Best Current Practice
+
Editor
Kaichao Sun <kaichao@status.im>
+
+
## Abstract
This document lists the types of messages that are using [MVDS](/vac/2/mvds.md)
diff --git a/docs/status/raw/url-data.md b/docs/status/raw/url-data.md
index 1a5662a..a9d285e 100644
--- 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
-contributors:
- - Aaryamann Challani
----
+# STATUS-URL-DATA
+
+
+
Name
Status URL Data
+
Status
raw
+
Category
Standards Track
+
Editor
Felicio Mununga <felicio@status.im>
+
Contributors
Aaryamann Challani <aaryamann@status.im>
+
+
## Abstract
This document specifies serialization, compression, and
diff --git a/docs/status/raw/url-scheme.md b/docs/status/raw/url-scheme.md
index a640e69..8c9b18f 100644
--- 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
-contributors:
----
+# STATUS-URL-SCHEME
+
+
+
Name
Status URL Scheme
+
Status
raw
+
Category
Standards Track
+
Editor
Felicio Mununga <felicio@status.im>
+
+
## Abstract
This document describes URL scheme for previewing and
diff --git a/docs/vac/1/coss.md b/docs/vac/1/coss.md
index 601df2a..3d3e3c2 100644
--- 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
-contributors:
- - Oskar Thoren
- - Pieter Hintjens
- - André Rebentisch
- - Alberto Barrionuevo
- - Chris Puttick
- - Yurii Rashkovskii
- - Jimmy Debe
----
+# 1/COSS
+
+
+
Name
Consensus-Oriented Specification System
+
Slug
1
+
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>
+
+
This document describes a consensus-oriented specification system (COSS)
for building interoperable technical specifications.
COSS is based on a lightweight editorial process that
diff --git a/docs/vac/2/mvds.md b/docs/vac/2/mvds.md
index a6311c2..e0386b1 100644
--- 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
-contributors:
- - Dean Eigenmann
- - Oskar Thorén
----
+# 2/MVDS
+
+
+
Name
Minimum Viable Data Synchronization
+
Slug
2
+
Status
stable
+
Editor
Sanaz Taheri <sanaz@status.im>
+
Contributors
Dean Eigenmann <dean@status.im> Oskar Thorén <oskarth@titanproxy.com>
+
+
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]:
diff --git a/docs/vac/25/libp2p-dns-discovery.md b/docs/vac/25/libp2p-dns-discovery.md
index 27698cd..fcec806 100644
--- 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
-contributors:
----
+# 25/LIBP2P-DNS-DISCOVERY
+
+
+
Name
Libp2p Peer Discovery via DNS
+
Slug
25
+
Status
deleted
+
Editor
Hanno Cornelius <hanno@status.im>
+
+
`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,
diff --git a/docs/vac/3/remote-log.md b/docs/vac/3/remote-log.md
index 2afeda6..b874c06 100644
--- 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
-contributors:
- - Dean Eigenmann
----
+# 3/REMOTE-LOG
+
+
+
Name
Remote log specification
+
Slug
3
+
Status
draft
+
Editor
Oskar Thorén <oskarth@titanproxy.com>
+
Contributors
Dean Eigenmann <dean@status.im>
+
+
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.
diff --git a/docs/vac/32/rln-v1.md b/docs/vac/32/rln-v1.md
index 53b7455..a4aeeec 100644
--- 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
-contributors:
-- Barry Whitehat
-- Sanaz Taheri
-- Oskar Thorén
-- Onur Kilic
-- Blagoj Dimovski
-- Rasul Ibragimov
----
+# 32/RLN-V1
+
+
+
Name
Rate Limit Nullifier
+
Slug
32
+
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>
+
+
## Abstract
The following specification covers the RLN construct
diff --git a/docs/vac/4/mvds-meta.md b/docs/vac/4/mvds-meta.md
index d0e26bd..6189ead 100644
--- 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
-contributors:
- - Dean Eigenmann
- - Andrea Maria Piana
- - Oskar Thorén
----
+# 4/MVDS-META
+
+
+
Name
MVDS Metadata Field
+
Slug
4
+
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>
+
+
In this specification, we describe a method to construct message history that
will aid the consistency guarantees of [2/MVDS](../2/mvds.md).
Additionally,
diff --git a/docs/vac/raw/consensus-hashgraphlike.md b/docs/vac/raw/consensus-hashgraphlike.md
index ee0b798..0c39de3 100644
--- 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
+
+
+
+
Name
Hashgraphlike Consensus Protocol
+
Status
raw
+
Category
Standards Track
+
Editor
Ugur Sen [ugur@status.im](mailto:ugur@status.im)
+
Contributors
s e e m e n k i n a
[ e k a t e r i n a @ s t a t u s . i m ] ( m a i l t o : e k a t e r i n a @ s t a t u s . i m )
+
+
+## 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)
diff --git a/docs/vac/raw/decentralized-messaging-ethereum.md b/docs/vac/raw/decentralized-messaging-ethereum.md
index c3859cf..f275eb0 100644
--- 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
-contributors:
----
+# ETH-DCGKA
+
+
+
Name
Decentralized Key and Session Setup for Secure Messaging over Ethereum
+
Status
raw
+
Category
informational
+
Editor
Ramses Fernandez-Valencia <ramses@status.im>
+
+
## Abstract
This document introduces a decentralized group messaging protocol
diff --git a/docs/vac/raw/deleted/eth-secpm.md b/docs/vac/raw/deleted/eth-secpm.md
index f90156c..63c9f5e 100644
--- 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
-contributors:
----
+# ETH-SECPM
+
+
+
Name
Secure channel setup using Ethereum accounts
+
Status
deleted
+
Category
Standards Track
+
Editor
Ramses Fernandez <ramses@status.im>
+
+
## NOTE
The content of this specification has been split between
diff --git a/docs/vac/raw/eth-mls-offchain.md b/docs/vac/raw/eth-mls-offchain.md
index 5c40534..820715d 100644
--- 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
+
+
+
+
Name
Secure channel setup using decentralized MLS and Ethereum accounts
+
Status
raw
+
Category
Standards Track
+
Editor
Ugur Sen [ugur@status.im](mailto:ugur@status.im)
+
Contributors
s e e m e n k i n a
[ e k a t e r i n a @ s t a t u s . i m ] ( m a i l t o : e k a t e r i n a @ s t a t u s . i m )
+
+
+## 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)
diff --git a/docs/vac/raw/eth-mls-onchain.md b/docs/vac/raw/eth-mls-onchain.md
index eda25f5..26460a5 100644
--- 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
-contributors: Aaryamann Challani , Ekaterina Broslavskaya , Ugur Sen , Ksr
----
+# ETH-MLS-ONCHAIN
+
+
+
Name
Secure channel setup using decentralized MLS and Ethereum accounts
+
Status
raw
+
Category
Standards Track
+
Editor
Ramses Fernandez <ramses@status.im>
+
Contributors
A a r y a m a n n
C h a l l a n i
< a a r y a m a n n @ s t a t u s . i m > ,
E k a t e r i n a
B r o s l a v s k a y a
< e k a t e r i n a @ s t a t u s . i m > ,
U g u r
S e n
< u g u r @ s t a t u s . i m > ,
K s r
< k s r @ s t a t u s . i m >
+
+
## Motivation
The need for secure communications has become paramount.
diff --git a/docs/vac/raw/gossipsub-tor-push.md b/docs/vac/raw/gossipsub-tor-push.md
index ce06331..5503733 100644
--- 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
-contributors:
----
+# GOSSIPSUB-TOR-PUSH
+
+
+
Name
Gossipsub Tor Push
+
Status
raw
+
Category
Standards Track
+
Editor
Daniel Kaiser <danielkaiser@status.im>
+
+
## Abstract
This document extends the [libp2p gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
diff --git a/docs/vac/raw/logos-capability-discovery.md b/docs/vac/raw/logos-capability-discovery.md
index 93d7ca4..13e39ec 100644
--- 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
+
[ u g u r @ s t a t u s . i m ] ( m a i l t o : u g u r @ s t a t u s . i m )
+
+
> **Note:** This specification is currently a WIP and undergoing a high rate of changes.
## Abstract
diff --git a/docs/vac/raw/mix.md b/docs/vac/raw/mix.md
index 4319a74..67b69f0 100644
--- 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
-contributors: Akshaya Mani , Daniel Kaiser
----
+# LIBP2P-MIX
+
+
+
Name
Libp2p Mix Protocol
+
Status
raw
+
Category
Standards Track
+
Editor
Prem Prathi <premprathi@proton.me>
+
Contributors
A k s h a y a
M a n i
< a k s h a y a @ s t a t u s . i m > ,
D a n i e l
K a i s e r
< d a n i e l k a i s e r @ s t a t u s . i m >
+
+
## Abstract
The Mix Protocol defines a decentralized anonymous message routing layer for libp2p networks.
diff --git a/docs/vac/raw/noise-x3dh-double-ratchet.md b/docs/vac/raw/noise-x3dh-double-ratchet.md
index 0b6e516..aaaa49e 100644
--- 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
-contributors:
----
+# NOISE-X3DH-DOUBLE-RATCHET
+
+
+
Name
Secure 1-to-1 channel setup using X3DH and the double ratchet
+
Status
raw
+
Category
Standards Track
+
Editor
Ramses Fernandez <ramses@status.im>
+
+
## Motivation
The need for secure communications has become paramount.
diff --git a/docs/vac/raw/rln-interep-spec.md b/docs/vac/raw/rln-interep-spec.md
index 4df5139..ef7f631 100644
--- 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
-contributors:
----
+# RLN-INTEREP-SPEC
+
## Abstract
This specification describes the usage of stealth commitments
diff --git a/docs/vac/raw/rln-v2.md b/docs/vac/raw/rln-v2.md
index 4e4ab72..46f36f6 100644
--- 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
-contributors:
-- Lev Soukhanov <0xdeadfae@gmail.com>
----
+# RLN-V2
+
+
+
Name
Rate Limit Nullifier V2
+
Status
raw
+
Editor
Rasul Ibragimov <curryrasul@gmail.com>
+
Contributors
Lev Soukhanov <0xdeadfae@gmail.com>
+
+
## Abstract
The protocol specified in this document is an improvement of [32/RLN-V1](../32/rln-v1.md),
diff --git a/docs/vac/raw/sds.md b/docs/vac/raw/sds.md
index c9d14ba..ecb9c85 100644
--- 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
-contributors:
- - Akhil Peddireddy
----
+# SDS
+
+
+
Name
Scalable Data Sync protocol for distributed logs
+
Status
raw
+
Editor
Hanno Cornelius <hanno@status.im>
+
Contributors
Akhil Peddireddy <akhil@status.im>
+
+
## Abstract
This specification introduces the Scalable Data Sync (SDS) protocol
diff --git a/docs/vac/template.md b/docs/vac/template.md
index 815258e..d4039de 100644
--- 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
-contributors:
----
+# TEMPLATE
+
+
+
Name
RFC Template
+
Slug
XX
+
Status
raw/draft/stable/deprecated
+
Category
Standards Track/Informational/Best Current Practice
+
Editor
Daniel Kaiser <danielkaiser@status.im>
+
+
## (Info, remove this section)
This section contains meta info about writing RFCs.
diff --git a/docs/waku/deprecated/16/rpc.md b/docs/waku/deprecated/16/rpc.md
index b958939..75f961e 100644
--- 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
----
+# 16/WAKU2-RPC
+
+
+
Name
Waku v2 RPC API
+
Slug
16
+
Status
deprecated
+
Editor
Hanno Cornelius <hanno@status.im>
+
+
## Introduction
This specification describes the JSON-RPC API that Waku v2 nodes MAY adhere to.
diff --git a/docs/waku/deprecated/18/swap.md b/docs/waku/deprecated/18/swap.md
index 2326a47..ccce74f 100644
--- 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
-contributor: Ebube Ud
----
+# 18/WAKU2-SWAP
+
+
+
Name
Waku SWAP Accounting
+
Slug
18
+
Status
deprecated
+
Editor
Oskar Thorén <oskarth@titanproxy.com>
+
+
## Abstract
This specification outlines how we do accounting and settlement based on the provision
diff --git a/docs/waku/deprecated/5/waku0.md b/docs/waku/deprecated/5/waku0.md
index 78b7b44..c68cf50 100644
--- 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
-contributors:
- - Adam Babik
- - Andrea Maria Piana
- - Dean Eigenmann
- - Kim De Mey
----
+# 5/WAKU0
+
+
+
Name
Waku v0
+
Slug
5
+
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>
+
+
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
diff --git a/docs/waku/deprecated/fault-tolerant-store.md b/docs/waku/deprecated/fault-tolerant-store.md
index c2d3945..cc7a68d 100644
--- 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
-contributors:
----
+# 21/WAKU2-FAULT-TOLERANT-STORE
+
+
+
Name
Waku v2 Fault-Tolerant Store
+
Slug
21
+
Status
deleted
+
Editor
Sanaz Taheri <sanaz@status.im>
+
+
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
diff --git a/docs/waku/informational/22/toy-chat.md b/docs/waku/informational/22/toy-chat.md
index c58e813..c424e99 100644
--- 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
-contributors:
- - Hanno Cornelius
----
+# 22/TOY-CHAT
+
+
+
Name
Waku v2 Toy Chat
+
Slug
22
+
Status
draft
+
Editor
Franck Royer <franck@status.im>
+
Contributors
Hanno Cornelius <hanno@status.im>
+
+
**Content Topic**: `/toy-chat/2/huilong/proto`.
This specification explains a toy chat example using Waku v2.
diff --git a/docs/waku/informational/23/topics.md b/docs/waku/informational/23/topics.md
index 64e89cd..82aaa07 100644
--- 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
-contributors:
- - Hanno Cornelius
- - Daniel Kaiser
- - Filip Dimitrijevic
----
+# 23/WAKU2-TOPICS
+
+
+
Name
Waku v2 Topic Usage Recommendations
+
Slug
23
+
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>
+
+
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:
diff --git a/docs/waku/informational/27/peers.md b/docs/waku/informational/27/peers.md
index 01516e9..0f3019e 100644
--- 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
-contributors:
- - Filip Dimitrijevic
----
+# 27/WAKU2-PEERS
+
+
+
Name
Waku v2 Client Peer Management Recommendations
+
Slug
27
+
Status
draft
+
Editor
Hanno Cornelius <hanno@status.im>
+
Contributors
Filip Dimitrijevic <filip@status.im>
+
+
`27/WAKU2-PEERS` describes a recommended minimal set of peer storage and
peer management features to be implemented by Waku v2 clients.
diff --git a/docs/waku/informational/29/config.md b/docs/waku/informational/29/config.md
index 098382d..16bf850 100644
--- 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
-contributors:
- - Filip Dimitrijevic
----
+# 29/WAKU2-CONFIG
+
## Abstract
This specification describes how Waku provides confidentiality, authenticity, and
diff --git a/docs/waku/standards/application/53/x3dh.md b/docs/waku/standards/application/53/x3dh.md
index 5c06632..b761ed0 100644
--- 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
-contributors:
- - Andrea Piana
- - Pedro Pombeiro
- - Corey Petty
- - Oskar Thorén
- - Dean Eigenmann
- - Filip Dimitrijevic
----
+# 53/WAKU2-X3DH
+
+
+
Name
X3DH usage for Waku payload encryption
+
Slug
53
+
Status
draft
+
Category
Standards Track
+
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>
+
+
## Abstract
This document describes a method that can be used to provide a secure channel
diff --git a/docs/waku/standards/application/54/x3dh-sessions.md b/docs/waku/standards/application/54/x3dh-sessions.md
index a909ca0..5e0c17d 100644
--- 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
-contributors:
- - Andrea Piana
- - Pedro Pombeiro
- - Corey Petty
- - Oskar Thorén
- - Dean Eigenmann
- - Filip Dimitrijevic
----
+# 54/WAKU2-X3DH-SESSIONS
+
+
+
Name
Session management for Waku X3DH
+
Slug
54
+
Status
draft
+
Category
Standards Track
+
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>
+
+
## Abstract
This document specifies how to manage sessions based on an X3DH key exchange.
diff --git a/docs/waku/standards/application/README.md b/docs/waku/standards/application/README.md
new file mode 100644
index 0000000..85b378a
--- /dev/null
+++ b/docs/waku/standards/application/README.md
@@ -0,0 +1,3 @@
+# Waku Standards - Application
+
+Application-layer specifications built on top of Waku core protocols.
diff --git a/docs/waku/standards/core/10/waku2.md b/docs/waku/standards/core/10/waku2.md
index bfbc543..0231cea 100644
--- 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
-contributors:
- - Sanaz Taheri
- - Hanno Cornelius
- - Reeshav Khan
- - Daniel Kaiser
- - Oskar Thorén
----
+# 10/WAKU2
+
+
+
+
Name
Waku v2
+
Slug
10
+
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>
Oskar Thorén <oskarth@titanproxy.com> Sanaz Taheri <sanaz@status.im>
+
+
`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.
diff --git a/docs/waku/standards/core/12/filter.md b/docs/waku/standards/core/12/filter.md
index cf257a4..d47070d 100644
--- 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
-contributors:
- - Dean Eigenmann
- - Oskar Thorén
- - Sanaz Taheri
- - Ebube Ud
----
+# 12/WAKU2-FILTER
+
+
+
Name
Waku v2 Filter
+
Slug
12
+
Status
draft
+
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>
+
+
previous versions: [00](/waku/standards/core/12/previous-versions/00/filter.md)
**Protocol identifiers**:
diff --git a/docs/waku/standards/core/12/previous-versions/00/filter.md b/docs/waku/standards/core/12/previous-versions/00/filter.md
index 5889a0d..4dcdb19 100644
--- 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
-contributors:
- - Dean Eigenmann
- - Oskar Thorén
- - Sanaz Taheri
- - Ebube Ud
----
-
+# 12/WAKU2-FILTER
+
+
+
Name
Waku v2 Filter
+
Slug
12
+
Status
draft
+
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>
+
+
`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.
diff --git a/docs/waku/standards/core/13/previous-versions/00/store.md b/docs/waku/standards/core/13/previous-versions/00/store.md
index a80b91e..164c871 100644
--- 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
-contributors:
- - Dean Eigenmann
- - Oskar Thorén
- - Aaryamann Challani
- - Sanaz Taheri
- - Hanno Cornelius
----
+# 13/WAKU2-STORE
+
+
+
Name
Waku v2 Store
+
Slug
13
+
Status
draft
+
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>
+
+
## Abstract
This specification explains the `13/WAKU2-STORE` protocol
diff --git a/docs/waku/standards/core/13/store.md b/docs/waku/standards/core/13/store.md
index 6b8d0c3..2b9bc55 100644
--- 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
-contributors:
- - Dean Eigenmann
- - Oskar Thorén
- - Aaryamann Challani
- - Sanaz Taheri
----
+# 13/WAKU2-STORE
+
+
+
+
Name
Waku Store Query
+
Slug
13
+
Status
draft
+
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>