feat: Add raw spec for /gossipsub-relay/1.0.0 protocol

Fix lint issue in sds.md

vac/raw/eth-mls-offchain.md

@@ -0,0 +1,241 @@
+---
+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 members of network without being in any secure group messaging.
+- `member`: Members are special nodes in the secure group messaging who
+obtains current group key of secure group messaging.
+- `steward`: Stewards are special and transparent members in secure group
+messaging who organizes the changes upon the voted-proposals.
+
+## 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`: Fixed 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
+
+`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.
+
+## 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 correspondng `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 `steward` aggregates all `KeyPackages` utilizes them to provision group additions for new members,
+based on the outcome of the voting process.
+5. 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.
+6. 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.
+7. 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.
+
+## 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.
+
+### Multi steward with single consensus
+
+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.
+
+### Multi steward with two consensuses
+
+The two-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 but do not take part in each decision.
+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.
+
+## 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)

vac/raw/gossipsub-relay.md

@@ -0,0 +1,124 @@
+---
+title: GOSSIPSUB-RELAY
+name: GossipSub Relay Protocol
+status: raw
+editor: Akshaya Mani <akshaya@status.im>
+contributors: Richard Ramos <richard@status.im>, Daniel Kaiser <danielkaiser@status.im>
+---
+
+**Protocol identifier**: `/gossipsub-relay/1.0.0`
+
+## Motivation and Goals
+
+The Gossipsub Relay Protocol defines a minimal request/response interface
+that allows external clients to inject pre-constructed GossipSub messages
+into the relay logic of a full GossipSub node, without requiring mesh
+participation or GossipSub protocol support.
+
+This enables lightweight or stateless clients and anonymity systems&mdash;such as
+mixnets&mdash;to send messages into the GossipSub network without joining the mesh,
+maintaining long-lived streams, or managing peer scoring.
+
+## Use Case: Mixnet Integration
+
+A motivating use case is the Mix Protocol, where a sender anonymously routes a
+message through a mix network composed of participating libp2p nodes. The final
+hop on the mix network (*i.e.,* the exit node) forwards the message to the
+Gossipsub Relay Protocol at the destination node.
+
+The Relay handler receives the message as a raw byte stream and passes it to
+the handler of the local Gossipsub instance, which then processes and
+disseminates the message as if it arrived from a regular mesh peer.
+
+This design cleanly separates the anonymous routing layer, offered by Mix,
+from the GossipSub relay logic.
+
+## Protocol Overview
+
+`/gossipsub-relay/1.0.0` is a unary request/response protocol where:
+
+- The client sends a single request containing a serialized `RPC` protobuf
+  message, as defined by the
+  [Gossipsub specification](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub).
+- The server passes this byte sequence directly the handler of the local
+  GossipSub instance, without attempting to parse or interpret it.
+- The server responds with a simple acknowledgment&mdash;`success` or `error`&mdash;
+  and closes the stream.
+
+The server node MUST run both the GossipSub and GossipSub Relay protocols. The
+Relay Protocol is agnostic to the structure of the payload. It serves only as
+an interface between the client and the local GossipSub logic.
+
+Unlike `Waku Lightpush`, this protocol **does not** trigger a publish
+operation directly. Instead, it defers all processing and relaying to the
+local Gossipsub instance.
+
+## Protobuf
+
+The relay protocol uses a simple wrapper message for binary payload injection:
+
+```protobuf
+  syntax = "proto3";
+
+  message Request {
+    // Opaque byte sequence representing a serialized GossipSub RPC message.
+    bytes data = 1;
+  }
+
+  message Response {
+    // Indicates success or failure of message injection
+    bool is_success = 1;
+
+    // Optional error or status message
+    string info = 2;
+  }
+```
+
+## Protocol Requirements
+
+libp2p nodes implementing `/gossipsub-relay/1.0.0` MUST:
+
+- Run a full local GossipSub instance.
+- Accept incoming streams using `/gossipsub-relay/1.0.0`.
+- On receiving a `Request`, treat the data field as an opaque byte sequence.
+- Invoke the local GossipSub handler with the `data`. The local GossipSub
+  instance then validates and relays the `data` as if it was received from a
+  mesh peer.
+- Respond with a `Response` indicating whether the injection succeeded.
+
+Clients may open a new stream for subsequent requests.
+
+The relay protocol itself MUST NOT inspect or parse the payload. The local
+GossipSub handler is responsible for parsing the received bytes and validating
+that it conforms to a valid `RPC` message as defined by the Gossipsub spec.
+
+## Security Considerations
+
+This protocol enables arbitrary clients to inject raw payloads into the local
+GossipSub handler without performing origin authentication or message
+integrity checks.
+
+Implementers SHOULD take steps to mitigate abuse, such as:
+
+- Enforce per-IP or per-peer rate limits.
+- Reject oversized payloads.
+
+The relay node itself SHOULD remain stateless with respect to injected
+messages.
+
+## Compatibility
+
+This protocol is transport-agnostic and can be mounted alongside other
+Gossipsub-compatible protocols. It does not require any changes to the core
+Gossipsub specification.
+
+To receive messages via this protocol, a node MUST also mount the GossipSub protocol.
+
+## Copyright
+
+Copyright and related rights waived via
+[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+- [libp2p Gossipsub specification](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub)

vac/raw/sds.md

@@ -55,6 +55,9 @@ but improves scalability by reducing direct interactions between participants.
 Each message has a globally unique, immutable ID (or hash).
 Messages can be requested from the high-availability caches or
 other participants using the corresponding message ID.
+* **Participant ID:**
+Each participant has a globally unique, immutable ID
+visible to other participants in the communication.
 
 ## Wire protocol
 
@@ -75,7 +78,7 @@ message HistoryEntry {
 }
 
 message Message {
-  // 1 Reserved for sender/participant id
+  string sender_id = 1;           // Participant ID of the message sender
   string message_id = 2;          // Unique identifier of the message
   string channel_id = 3;          // Identifier of the channel to which the message belongs
   optional int32 lamport_timestamp = 10;    // Logical timestamp for causal ordering in channel
@@ -85,7 +88,8 @@ message Message {
 }
 ```
 
-Each message MUST include its globally unique identifier in the `message_id` field,
+The sending participant MUST include its own globally unique identifier in the `sender_id` field.
+In addition, it MUST include a globally unique identifier for the message in the `message_id` field,
 likely based on a message hash.
 The `channel_id` field MUST be set to the identifier of the channel of group communication
 that is being synchronized.
@@ -98,6 +102,10 @@ These fields MAY be left unset in the case of [ephemeral messages](#ephemeral-me
 The message `content` MAY be left empty for [periodic sync messages](#periodic-sync-message),
 otherwise it MUST contain the application-level content
 
+> **_Note:_** Close readers may notice that, outside of filtering messages originating from the sender itself,
+the `sender_id` field is not used for much.
+Its importance is expected to increase once a p2p retrieval mechanism is added to SDS, as is planned for the protocol.
+
 ### Participant state
 
 Each participant MUST maintain:
@@ -157,6 +165,8 @@ of unacknowledged outgoing messages.
 
 Upon receiving a message,
 
+* the participant SHOULD ignore the message if it has a `sender_id` matching its own.
+* the participant MAY deduplicate the message by comparing its `message_id` to previously received message IDs.
 * the participant MUST [review the ACK status](#review-ack-status) of messages
 in its unacknowledged outgoing buffer
 using the received message's causal history and bloom filter.

waku/standards/core/66/metadata.md

@@ -3,9 +3,10 @@ slug: 66
 title: 66/WAKU2-METADATA
 name: Waku Metadata Protocol
 status: draft
-editor: Alvaro Revuelta <alrevuelta@status.im>
+editor: Franck Royer <franck@status.im>
 contributors:
- - Filip Dimitrijevic <filip@status.im>
+  - Filip Dimitrijevic <filip@status.im>
+  - Alvaro Revuelta <alrevuelta@status.im>
 ---
 
 ## Abstract
@@ -15,16 +16,19 @@ that can be associated with a [10/WAKU2](/waku/standards/core/10/waku2.md) node.
 
 ## Metadata Protocol
 
-Waku specifies a req/resp protocol that provides information about the node's medatadata.
-Such metadata is meant to be used by the node to decide if a peer is worth connecting
-or not.
+The keywords “MUST”, // List style “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,
+“NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+Waku specifies a req/resp protocol that provides information about the node's capabilities.
+Such metadata MAY be used by other peers for subsequent actions such as light protocol requests or disconnection.
+
 The node that makes the request,
 includes its metadata so that the receiver is aware of it,
-without requiring an extra interaction.
+without requiring another round trip.
 The parameters are the following:
 
 * `clusterId`: Unique identifier of the cluster that the node is running in.
-* `shards`: Shard indexes that the node is subscribed to.
+* `shards`: Shard indexes that the node is subscribed to via [`11/WAKU2-RELAY`](/waku/standards/core/11/relay.md).
 
 ***Protocol Identifier***
 
@@ -48,6 +52,51 @@ message WakuMetadataResponse {
 }
 ```
 
+## Implementation Suggestions
+
+### Triggering Metadata Request
+
+A node SHOULD proceed with metadata request upon first connection to a remote node.
+A node SHOULD use the remote node's libp2p peer id as identifier for this heuristic.
+
+A node MAY proceed with metadata request upon reconnection to a remote peer.
+
+A node SHOULD store the remote peer's metadata information for future reference.
+A node MAY implement a TTL regarding a remote peer's metadata, and refresh it upon expiry by initiating another metadata request.
+It is RECOMMENDED to set the TTL to 6 hours.
+
+A node MAY trigger a metadata request after receiving an error response from a remote note
+stating they do not support a specific cluster or shard.
+For example, when using a request-response service such as [`19/WAKU2-LIGHTPUSH`](/waku/standards/core/19/lightpush.md).
+
+### Providing Cluster Id
+
+A node MUST include their cluster id into their metadata payload.
+It is RECOMMENDED for a node to operate on a single cluster id.
+
+### Providing Shard Information
+
+* Nodes that mount [`11/WAKU2-RELAY`](/waku/standards/core/11/relay.md) MAY include the shards they are subscribed to in their metadata payload.
+* Shard-relevant services are message related services,
+  such as [`13/WAKU2-STORE`](/waku/standards/core/13/store.md), [12/WAKU2-FILTER](/waku/standards/core/12/filter.md)
+  and [`19/WAKU2-LIGHTPUSH`](/waku/standards/core/19/lightpush.md)
+  but not [`34/WAKU2-PEER-EXCHANGE`](/waku/standards/core/34/peer-exchange.md)
+* Nodes that mount [`11/WAKU2-RELAY`](/waku/standards/core/11/relay.md) and a shard-relevant service SHOULD include the shards they are subscribed to in their metadata payload.
+* Nodes that do not mount [`11/WAKU2-RELAY`](/waku/standards/core/11/relay.md) SHOULD NOT include any shard information
+
+### Using Cluster Id
+
+When reading the cluster id of a remote peer, the local node MAY disconnect if their cluster id is different from the remote peer.
+
+### Using Shard Information
+
+It is NOT RECOMMENDED to disconnect from a peer based on the fact that their shard information is different from the local node.
+
+Ahead of doing a shard-relevant request,
+a node MAY use the previously received metadata shard information to select a peer that support the targeted shard.
+
+For non-shard-relevant requests, a node SHOULD NOT discriminate a peer based on medata shard information.
+
 ## Copyright
 
 Copyright and related rights waived via