rfc-index: Update

.github/workflows/.gitignore

@@ -0,0 +1 @@
+.DS_Store

status/raw/status-app-protocols.md

@@ -14,7 +14,7 @@
 ## Abstract
 
 This specification describes the Status Application protocol stack.
 It focuses on elements and features in the protocol stack for all application-level functions:
 
 - functional scope (also _broadcast audience_)
 - content topic
@@ -23,7 +23,7 @@
 - encryption layer
 - transport layer (Waku)
 
 It also introduces strategies to restrict resource usage, distribute large messages, etc.
 Application-level functions are out of scope and specified separately. See:
 
 - [55/STATUS-1TO1-CHAT](../55/1to1-chat.md)
@@ -53,31 +53,31 @@
 - Status 1:1 Chat, as specified in [55/STATUS-1TO1-CHAT](../55/1to1-chat.md)
 - Status Private Group Chat, as specified in a subsection of [55/STATUS-1TO1-CHAT](../55/1to1-chat.md#negotiation-of-a-11-chat-amongst-multiple-participants-group-chat)
 
 <!-- TODO: list functions not related to main app features, such as user sync, backup, push notifications, etc. -->
 
 Each application-level function, regardless which feature set it supports, has the following properties:
 
 1. Functional scope
-1. Content topic
-1. Ephemerality
+2. Content topic
+3. Ephemerality
 
 ### Functional Scope
 
 Each Status app-level message MUST define a functional scope.
 The functional scope MUST define the _minimum_ scope of the audience that should _participate_ in the app function the message is related to.
 In other words, it determines the minimum subset of Status app participants
 that should have access to messages related to that function.
 
 Note that the functional scope is distinct from the number of participants that is _addressed_ by a specific message.
 For example, a participant will address a 1:1 chat to only one other participant.
 However, since all users of the Status app MUST be able to participate in 1:1 chats,
 the functional scope of messages enabling 1:1 chats MUST be a global scope.
 Similarly, since private group chats can be set up between any subset of Status app users,
 the functional scope for messages related to private group chats MUST be global.
 As a counter-example, messages that originate within a community (and are _addressed_ to members of that community)
 are only of interest to participants that are also members of that community.
 Such messages MUST have a community-wide functional scope.
 A third group of messages are addressed only to the participant that generated those messages itself.
 These _self-addressed_ messages MUST have a local functional scope.
 
 If we further make a distinction between "control" and "content" messages,
@@ -87,22 +87,23 @@
 
 #### Global scope
 
 1. _Global control_: messages enabling the basic functioning of the app to control features that all app users should be able to participate in. Examples include Contact Requests, Community Invites, global Status Updates, Group Chat Invites, etc.
 2. _Global content_: messages carrying user-generated content for global functions. Examples include 1:1 chat messages, images shared over private group chats, etc.
 
 #### Community scope
 
-3. _Community control_: messages enabling the basic functioning of the app to control features _only relevant to members of a specific community_. Examples include Community Membership Updates, community Status Updates, etc.
-4. _Community content_: messages carrying user-generated content _only for members of a specific community_.
+1._Community control_: messages enabling the basic functioning of the app to control features _only relevant to members of a specific community_. Examples include Community Membership Updates, community Status Updates, etc.
+2. _Community content_: messages carrying user-generated content _only for members of a specific community_.
 
 #### Local scope
 
-5. _Local_: messages related to functions that are only relevant to a single user. Also known as _self-addressed messages_. Examples include messages used to exchange information between app installations, such as User Backup and Sync messages.
+1. _Local_: messages related to functions that are only relevant to a single user. Also known as _self-addressed messages_. Examples include messages used to exchange information between app installations, such as User Backup and Sync messages.
 
 Note that the functional scope is a logical property of Status messages.
 It SHOULD however inform the underlying [transport layer sharding](#pubsub-topics-and-sharding) and [transport layer subscriptions](#subscribing).
 In general a Status client SHOULD subscribe to participate in:
-- all global functions,
+
+- all global functions
 - (only) the community functions for communities of which it is a member, and
 - its own local functions.
 
@@ -140,7 +141,7 @@
 The end-to-end reliability layer contains the functions related to one of the two end-to-end reliability schemes defined for Status app messages:
 
 1. Minimum Viable protocol for Data Synchronisation, or MVDS (see [STATUS-MVDS-USAGE](./status-mvds.md))
-1. Scalable distributed log reliability (spec and a punchier name TBD, see the [original forum post announcement](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16))
+2. Scalable distributed log reliability (spec and a punchier name TBD, see the [original forum post announcement](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16))
 
 Ephemeral messages SHOULD omit this layer.
 Non-ephemeral 1:1 chat messages SHOULD make use of MVDS to achieve reliable data synchronisation between the two parties involved in the communication.
@@ -243,8 +244,8 @@
 The specific Waku discovery protocol used for discovery depends on the use case and resource-availability of the client.
 
 1. [EIP-1459: DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459) is useful for initial connection to bootstrap peers.
-1. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) allows decentralized discovery of Waku peers.
-1. [34/WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md) allows requesting peers from a service node
+2. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) allows decentralized discovery of Waku peers.
+3. [34/WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md) allows requesting peers from a service node
 and is appropriate for resource-restricted discovery.
 
 All clients SHOULD use DNS-based discovery on startup
@@ -263,14 +264,14 @@
 The specific Waku protocol used for subscription depends on the resource-availability of the client:
 
 1. Filter client protocol, as specified in [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md), allows subscribing for traffic with content topic granularity and is appropriate for resource-restricted subscriptions.
-1. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows subscribing to traffic only with pubsub topic granularity and therefore is more resource-intensive. Relay subscription also allows the application instance to contribute to the overall routing infrastructure, which adds to its overall higher resource usage but benefits the ecosystem.
+2. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows subscribing to traffic only with pubsub topic granularity and therefore is more resource-intensive. Relay subscription also allows the application instance to contribute to the overall routing infrastructure, which adds to its overall higher resource usage but benefits the ecosystem.
 
 Full clients SHOULD use relay protocol as preferred method to subscribe to pubsub topics matching the scopes:
 
 1. Global control
-1. Global content
-1. Community control, for each community of which the app user is a member
-1. Community content, for each community of which the app user is a member
+2. Global content
+3. Community control, for each community of which the app user is a member
+4. Community content, for each community of which the app user is a member
 
 Light clients SHOULD use filter protocol to subscribe only to the content topics relevant to the user.
 
@@ -290,14 +291,14 @@
 The specific Waku protocol used for publishing depends on the resource-availability of the client:
 
 1. Lightpush protocol, as specified in [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) allows publishing to a pubsub topic via an intermediate "full node" and is more appropriate for resource-restricted publishing.
-1. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows publishing directly into the relay routing network and is therefore more resource-intensive.
+2. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows publishing directly into the relay routing network and is therefore more resource-intensive.
 
 Full clients SHOULD use relay protocol to publish to pubsub topics matching the scopes:
 
 1. Global control
-1. Global content
-1. Community control, for each community of which the app user is a member
-1. Community content, for each community of which the app user is a member
+2. Global content
+3. Community control, for each community of which the app user is a member
+4. Community content, for each community of which the app user is a member
 
 Light clients SHOULD use lightpush protocol to publish control and content messages.
 
@@ -397,13 +398,13 @@
 ## References
 
 1. [55/STATUS-1TO1-CHAT](../55/1to1-chat.md)
-1. [56/STATUS-COMMUNITIES](../56/communities.md)
-1. [10/WAKU2](../../waku/standards/core/10/waku2.md)
-1. [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
-1. [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md)
-1. [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md)
-1. [23/WAKU2-TOPICS](../../waku/informational/23/topics.md)
-1. [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md)
-1. [Scalable distributed log reliability](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16)
-1. [STATUS-MVDS-USAGE](./status-mvds.md)
-1. [WAKU2-STORE](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md)
+2. [56/STATUS-COMMUNITIES](../56/communities.md)
+3. [10/WAKU2](../../waku/standards/core/10/waku2.md)
+4. [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
+5. [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md)
+6. [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md)
+7. [23/WAKU2-TOPICS](../../waku/informational/23/topics.md)
+8. [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md)
+9. [Scalable distributed log reliability](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16)
+10. [STATUS-MVDS-USAGE](./status-mvds.md)
+11. [WAKU2-STORE](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md)

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

@@ -18,7 +18,7 @@ This specification describes the `17/WAKU2-RLN-RELAY` protocol,
 which is an extension of [`11/WAKU2-RELAY`](../11/relay.md)
 to provide spam protection using [Rate Limiting Nullifiers (RLN)](../../../../vac/32/rln-v1.md).
 
-The security objective is to contain spam activity in the (64/WAKU-NETWORK)[]
+The security objective is to contain spam activity in the [64/WAKU-NETWORK](../64/network.md)
 by enforcing a global messaging rate to all the peers.
 Peers that violate the messaging rate are considered spammers and
 their message is considered spam.
@@ -374,9 +374,10 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References
 
 1. [`11/WAKU2-RELAY`](../11/relay.md)
-2. [RLN](../../../../vac/32/rln-v1.md)
-3. [14/WAKU2-MESSAGE](../14/message.md)
-4. [RLN documentation](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view)
-5. [Public inputs to the RLN circuit](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Public-Inputs)
-6. [Shamir secret sharing scheme used in RLN](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Linear-Equation-amp-SSS)
-7. [RLN internal nullifier](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Nullifiers)
+2. [64/WAKU-NETWORK](../64/network.md)
+3. [RLN](../../../../vac/32/rln-v1.md)
+4. [14/WAKU2-MESSAGE](../14/message.md)
+5. [RLN documentation](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view)
+6. [Public inputs to the RLN circuit](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Public-Inputs)
+7. [Shamir secret sharing scheme used in RLN](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Linear-Equation-amp-SSS)
+8. [RLN internal nullifier](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Nullifiers)