diff --git a/status/raw/simple-scaling.md b/status/raw/simple-scaling.md index 6940d31c..e8516b61 100644 --- a/status/raw/simple-scaling.md +++ b/status/raw/simple-scaling.md @@ -63,14 +63,14 @@ efficient way will be part of a future document. Sharding the [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) network is an integral part of scaling the Status app. -[51/WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md) +[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) specifies shards clusters, which are sets of `1024` shards (separate pubsub mesh networks). Content topics specified by application protocols can be distributed over these shards. The Status app protocols are assigned to shard cluster `16`, -as defined in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md). +as defined in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md). -[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md) +[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) specifies three sharding methods. This document uses *static sharding*, which leaves the distribution of content topics to application protocols, @@ -88,7 +88,7 @@ The 1024 shards within the main Status shard cluster are allocated as follows. | 768 - 895 | 1:1 chat | | 896 - 1023 | media and control msgs | -Shard indices are mapped to pubsub topic names as follows (specified in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)). +Shard indices are mapped to pubsub topic names as follows (specified in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). `/waku/2/rs//` @@ -154,7 +154,7 @@ message CommunityDescription { } ``` -> *Note*: Currently, Status app has allocated shared cluster `16` in [52/WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md). +> *Note*: Currently, Status app has allocated shared cluster `16` in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md). Status app could allocate more shard clusters, for instance to establish a test net. We could add the shard cluster index to the community description as well. The recommendation for now, @@ -168,7 +168,7 @@ Status communities can be mapped to shards in two ways: static, and owner-based. With static mapping, communities are assigned a specific shard index within the Status shard cluster. -This mapping is similar in nature to the shard cluster allocation in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md). +This mapping is similar in nature to the shard cluster allocation in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md). Shard indices allocated in that way are in the range `16 - 127`. The Status CC community uses index `16` (not to confuse with shard cluster index `16`, which is the Status shard cluster). @@ -310,7 +310,7 @@ Light protocols comprise * [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) for sending messages * [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md) for requesting messages with specific attributes -* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md) +* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md) for discovering peers ## Waku Archive @@ -333,7 +333,7 @@ In fact, the archive service can be offered by infrastructure nodes. ## Discovery -Shard discovery is covered by [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md). +Shard discovery is covered by [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md). This allows the Status app to abstract from the discovery process and simply address shards by their index. @@ -344,7 +344,7 @@ this document suggests using [libp2p rendezvous](https://github.com/libp2p/specs Nodes can check whether they are behind a restrictive NAT using the [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md). -> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md), +> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md), or [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md): Nodes behind restrictive NATs SHOULD not announce their publicly unreachable address via [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) discovery. @@ -369,9 +369,9 @@ functionality offered by the libp2p circuit relay protocols, and to upgrade to a direct connection. Nodes that do not announce themselves at all and only plan to use light protocols, -MAY use rendezvous discovery instead of or along-side [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md). +MAY use rendezvous discovery instead of or along-side [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md). For these nodes, rendezvous and -[WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md) +[WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md) offer the same functionality, but return node sets sampled in different ways. Using both can help increasing connectivity. @@ -401,7 +401,7 @@ The string conversion SHOULD remove leading zeros. field is of type string, a more efficient byte encoding is not utilized. Registering shard 2 in the Status shard cluster (with shard cluster index 16, -see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md), +see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md), the register query would look like ```rs @@ -601,7 +601,7 @@ It could be rate-limited with RLN. This document makes several trade-offs to privacy and anonymity. Todo: elaborate. -See [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/waku-RFC/informational/adversarial-models.md) +See [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/master/informational/adversarial-models.md) for information on Waku Anonymity. ## Copyright @@ -614,12 +614,12 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public * [55/STATUS-1TO1-CHAT](../55/1to1-chat.md) * [23/WAKU2-TOPICS](../../waku/informational/23/topics.md) * [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) -* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md) -* [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md) +* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) +* [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md) * [30/ADAPTIVE-NODES](../../waku/informational/30/adaptive-nodes.md) * [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) * [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md) -* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md) +* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md) * [13/WAKU2-STORE](../../waku/standards/core/13/store.md) * [libp2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md) * [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md) @@ -629,9 +629,9 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public * [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md) * [scoring](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) * [Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/) -* [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/waku-RFC/informational/adversarial-models.md) +* [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/master/informational/adversarial-models.md) ## Informative * [Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/) -* [WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md) +* [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md) diff --git a/status/raw/status-waku-usage.md b/status/raw/status-waku-usage.md deleted file mode 100644 index 77fad169..00000000 --- a/status/raw/status-waku-usage.md +++ /dev/null @@ -1,218 +0,0 @@ ---- -title: STATUS-WAKU2-USAGE -name: Status Waku2 Usage -status: raw -category: Best Current Practice -description: Defines how the Status application uses the Waku protocols. -editor: Aaryamann Challani -contributors: -- Jimmy Debe - ---- - -## Abstract - -Status is a chat application which has several features, -including, but not limited to - - -- Private 1:1 chats, described by [55/STATUS-1TO1-CHAT](/spec/55) -- Large scale group chats, described by [56/STATUS-COMMUNITIES](/spec/56) - -This specification describes how a Status implementation will make use of -the underlying infrastructure, Waku, -which is described in [10/WAKU2](/spec/10). - -## Background - -The Status application aspires to achieve censorship resistance and -incorporates specific privacy features, -leveraging the comprehensive set of protocols offered by Waku to enhance these attributes. -Waku protocols provide secure communication capabilities over decentralized networks. -Once integrated, an application will benefit from privacy-preserving, -censorship resistance and spam protected communcation. - -Since Status uses a large set of Waku protocols, -it is imperative to describe how each are used. - -## Terminology - -| Name | Description | -| --------------- | --------- | -| `RELAY`| This refers to the Waku Relay protocol, described in [11/WAKU2-RELAY](/spec/11) | -| `FILTER` | This refers to the Waku Filter protocol, described in [12/WAKU2-FILTER](/spec/12) | -| `STORE` | This refers to the Waku Store protocol, described in [13/WAKU2-STORE](/spec/13) | -| `MESSAGE` | This refers to the Waku Message format, described in [14/WAKU2-MESSAGE](/spec/14) | -| `LIGHTPUSH` | This refers to the Waku Lightpush protocol, described in [19/WAKU2-LIGHTPUSH](/spec/19) | -| Discovery | This refers to a peer discovery method used by a Waku node. | -| `Pubsub Topic` / `Content Topic` | This refers to the routing of messages within the Waku network, described in [23/WAKU2-TOPICS](/spec/23/) | - -### Waku Node - -Software that is configured with a set of Waku protocols. -A Status client comprises of a Waku node that is a `RELAY` node or a non-relay node. - -### Light Client - -A Status client that operates within resource constrained environments -is a node configured as light client. -Light clients do not run a `RELAY`. -Instead, Status light clients, -can request services from other `RELAY` node that provide `LIGHTPUSH` service. - -## Protocol Usage - -The key words “MUST”, “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). - -The following is a list of Waku Protocols used by a Status application. - -### 1. `RELAY` - -The `RELAY` MUST NOT be used by Status light clients. -The `RELAY` is used to broadcast messages between Status clients. -All Status messages are transformed into [14/WAKU2-MESSAGE](/spec/14), -which are sent over the wire. - -All Status message types are described in [62/STATUS-PAYLOAD](/spec/62). -Status Clients MUST transform the following object into a `MESSAGE` -as described below - - -```go - -type StatusMessage struct { - SymKey[] []byte // [optional] The symmetric key used to encrypt the message - PublicKey []byte // [optional] The public key to use for asymmetric encryption - Sig string // [optional] The private key used to sign the message - PubsubTopic string // The Pubsub topic to publish the message to - ContentTopic string // The Content topic to publish the message to - Payload []byte // A serialized representation of a Status message to be sent - Padding []byte // Padding that must be applied to the Payload - TargetPeer string // [optional] The target recipient of the message - Ephemeral bool // If the message is not to be stored, this is set to `true` -} - -``` - -1. A user MUST only provide either a Symmetric key OR -an Asymmetric keypair to encrypt the message. -If both are received, the implementation MUST throw an error. -2. `WakuMessage.Payload` MUST be set to `StatusMessage.Payload` -3. `WakuMessage.Key` MUST be set to `StatusMessage.SymKey` -4. `WakuMessage.Version` MUST be set to `1` -5. `WakuMessage.Ephemeral` MUST be set to `StatusMessage.Ephemeral` -6. `WakuMessage.ContentTopic` MUST be set to `StatusMessage.ContentTopic` -7. `WakuMessage.Timestamp` MUST be set to the current Unix epoch timestamp -(in nanosecond precision) - -### 2. `STORE` - -This protocol MUST remain optional according to the user's preferences, -it MAY be enabled on Light clients as well. - -Messages received via [11/WAKU2-RELAY](/spec/11), are stored in a database. -When Waku node running this protocol is service node, -it MUST provide the complete list of network messages. -Status clients SHOULD request historical messages from this service node. - -The messages that have the `WakuMessage.Ephemeral` flag set to true will not be stored. - -The Status client MAY provide a method to prune the database of -older records to save storage. - -### 3. `FILTER` - -This protocol SHOULD be enabled on Light clients. - -This protocol SHOULD be used to filter messages based on a given criteria, -such as the `Content Topic` of a `MESSAGE`. -This allows a reduction in bandwidth consumption by the Status client. - -#### Content filtering protocol identifers - -The `filter-subcribe` SHOULD be implemented on `RELAY` nodes -to provide `FILTER` services. - -`filter-subscribe`: - -> /vac/waku/filter-subscribe/2.0.0-beta1 - -The `filter-push` SHOULD be implemented on light clients to receive messages. - -`filter-push`: - -> /vac/waku/filter-push/2.0.0-beta1 - -Status clients SHOULD apply a filter for all the `Content Topic` -they are interested in, such as `Content Topic` derived from - - -1. 1:1 chats with other users, described in [55/STATUS-1TO1-CHAT](/spec/55) -2. Group chats -3. Community Channels, described in [56/STATUS-COMMUNITIES](/spec/56) - -### 4. `LIGHTPUSH` - -The `LIGHTPUSH` protocol MUST be enabled on Status light clients. -A Status `RELAY` node MAY implement `LIGHTPUSH` to support light clients. -Peers will be able to publish messages, -without running a full-fledged [11/WAKU2-RELAY](/spec/11) protocol. - -When a Status client is publishing a message, -it MUST check if Light mode is enabled, -and if so, it MUST publish the message via this protocol. - -### 5. Discovery - -A discovery method MUST be supported by Light clients and Full clients - -Status clients SHOULD make use of the following peer discovery methods -that are provided by Waku, such as - - -1. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459) -2. [33/WAKU2-DISCV5](/spec/33): A node discovery protocol to -create decentralized network of interconnected Waku nodes. -3. [34/WAKU2-PEER-EXCHANGE](/spec/34): -A peer discovery protocol for resource restricted devices. - -Status clients MAY use any combination of the above peer discovery methods, -which is suited best for their implementation. - -## Security/Privacy Considerations - -This specification inherits the security and -privacy considerations from the following specifications - - -1. [10/WAKU2](/spec/10) -2. [11/WAKU2-RELAY](/spec/11) -3. [12/WAKU2-FILTER](/spec/12) -4. [13/WAKU2-STORE](/spec/13) -5. [14/WAKU2-MESSAGE](/spec/14) -6. [23/WAKU2-TOPICS](/spec/23) -7. [19/WAKU2-LIGHTPUSH](/spec/19) -8. [55/STATUS-1TO1-CHAT](/spec/55) -9. [56/STATUS-COMMUNITIES](/spec/56) -10. [62/STATUS-PAYLOAD](/spec/62) -11. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459) -12. [33/WAKU2-DISCV5](/spec/33) -13. [34/WAKU2-PEER-EXCHANGE](/spec/34) - -## Copyright - -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). - -## References - -1. [55/STATUS-1TO1-CHAT](/spec/55) -2. [56/STATUS-COMMUNITIES](/spec/56) -3. [10/WAKU2](/spec/10) -4. [11/WAKU2-RELAY](/spec/11) -5. [12/WAKU2-FILTER](/spec/12) -6. [13/WAKU2-STORE](/spec/13) -7. [14/WAKU2-MESSAGE](/spec/14) -8. [23/WAKU2-TOPICS](/spec/23) -9. [19/WAKU2-LIGHTPUSH](/spec/19) -10. [64/WAKU2-NETWORK](/spec/64) -11. [62/STATUS-PAYLOAD](/spec/62) -12. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459) -13. [33/WAKU2-DISCV5](/spec/33) -14. [34/WAKU2-PEER-EXCHANGE](/spec/34) diff --git a/status/raw/url-data.md b/status/raw/url-data.md index 5c7bdeaa..1a5662ab 100644 --- a/status/raw/url-data.md +++ b/status/raw/url-data.md @@ -26,7 +26,7 @@ this specification proposes a standard method for encoding data within URLs. - Community: Refer to [STATUS-COMMUNITIES](../56/communities.md) - Channel: Refer to terminology in [STATUS-COMMUNITIES](../56/communities.md) - User: Refer to terminology in [STATUS-COMMUNITIES](../56/communities.md) -- Shard Refer to terminology in [51/WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) +- Shard Refer to terminology in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) ## Wire Format diff --git a/vac/template.md b/vac/template.md index 48ea3222..815258e5 100644 --- a/vac/template.md +++ b/vac/template.md @@ -1,9 +1,9 @@ --- slug: XX -title: XX/(WAKU2|LOGOS|CODEX|*)-TEMPLATE -name: (Waku v2 | Logos | Codex) RFC Template -status: (raw|draft|stable) -category: (Standards Track|Informational|Best Current Practice) +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: diff --git a/waku/informational/23/topics.md b/waku/informational/23/topics.md index 934faeb9..02e0beab 100644 --- a/waku/informational/23/topics.md +++ b/waku/informational/23/topics.md @@ -19,9 +19,9 @@ In [10/WAKU2 spec](../../standards/core/10/waku2.md) there are two types of topi ## Pubsub Topics Pubsub topics are used for routing of messages (see [11/WAKU2-RELAY](../../standards/core/11/relay.md)), -and can be named implicitly by Waku sharding (see [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)). +and can be named implicitly by Waku sharding (see [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). This document comprises recommendations for explicitly naming pubsub topics -(e.g. when choosing *named sharding* as specified in [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)). +(e.g. when choosing *named sharding* as specified in [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). ### Pubsub Topic Format @@ -80,7 +80,7 @@ but for different domains completely. ### Named Topic Sharding Example -The following is an example of named sharding, as specified in [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md). +The following is an example of named sharding, as specified in [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md). ```text waku/2/waku-9_shard-0/ @@ -175,7 +175,7 @@ Copyright and related rights waived via - [10/WAKU2 spec](../../standards/core/10/waku2.md) - [11/WAKU2-RELAY](../../standards/core/11/relay.md) -- [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md) +- [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) - [Ethereum 2 P2P spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#topics-and-messages) - [14/WAKU2-MESSAGE](../../standards/core/14/message.md) - [12/WAKU2-FILTER](../../standards/core/12/filter.md) diff --git a/waku/standards/core/10/waku2.md b/waku/standards/core/10/waku2.md index c326b8da..b1e81d35 100644 --- a/waku/standards/core/10/waku2.md +++ b/waku/standards/core/10/waku2.md @@ -224,7 +224,7 @@ It is possible to bypass the discovery domain by specifying static nodes. #### Use of ENR -[31/WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md) +[WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md) describes the usage of [EIP-778 ENR (Ethereum Node Records)](https://eips.ethereum.org/EIPS/eip-778) for Waku v2 discovery purposes. It introduces two new ENR fields, `multiaddrs` and @@ -574,7 +574,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public 17. [Node Discovery v5](https://github.com/ethereum/devp2p/blob/8fd5f7e1c1ec496a9d8dc1640a8548b8a8b5986b/discv5/discv5.md) -18. [31/WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md) +18. [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md) 19. [EIP-778 ENR (Ethereum Node Records)](https://eips.ethereum.org/EIPS/eip-778) diff --git a/waku/standards/core/14/message.md b/waku/standards/core/14/message.md index 694e66ce..af30ee57 100644 --- a/waku/standards/core/14/message.md +++ b/waku/standards/core/14/message.md @@ -118,7 +118,7 @@ The key agreement is performed out of band. And provides an encrypted signature and padding for some form of unlinkability. - **Version 2:** -The payload SHOULD be encoded according to [35/WAKU2-NOISE]([/spec/35](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)). +The payload SHOULD be encoded according to [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md). Waku Noise protocol provides symmetric encryption and asymmetric key exchange. Any `version` value not included in this list is reserved for future specification. @@ -254,5 +254,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public - [6/WAKU1](../../legacy/6/waku1.md) - [Google Protocol buffers v3](https://developers.google.com/protocol-buffers/) - [26/WAKU-PAYLOAD](../../application/26/payload.md) -- [35/WAKU2-NOISE]([/spec/35](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)) +- [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md) - [62/STATUS-PAYLOADS](../../../../status/62/payloads.md/#clock-vs-timestamp-and-message-ordering) diff --git a/waku/standards/core/19/lightpush.md b/waku/standards/core/19/lightpush.md index 4ab4a566..036d09fe 100644 --- a/waku/standards/core/19/lightpush.md +++ b/waku/standards/core/19/lightpush.md @@ -50,7 +50,7 @@ message PushRPC { Nodes that respond to `PushRequests` MUST either relay the encapsulated message via [11/WAKU2-RELAY](../11/relay.md) protocol on the specified `pubsub_topic`, -or forward the `PushRequest` via 19/LIGHTPUSH on a [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) +or forward the `PushRequest` via 19/LIGHTPUSH on a [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/master/standards/application/dandelion.md) stem. If they are unable to do so for some reason, they SHOULD return an error code in `PushResponse`. @@ -71,5 +71,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References * [11/WAKU2-RELAY](../11/relay.md) -* [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) +* [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/master/standards/application/dandelion.md) * [17/WAKU2-RLN-RELAY](../17/rln-relay.md) diff --git a/waku/standards/core/33/discv5.md b/waku/standards/core/33/discv5.md index b4abdafd..39aca3b0 100644 --- a/waku/standards/core/33/discv5.md +++ b/waku/standards/core/33/discv5.md @@ -41,7 +41,7 @@ within the network. in order of increasing decentralization * hard coded bootstrap nodes -* [`DNS discovery`](https://rfc.vac.dev/spec/10/#discovery-domain) (based on [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459)) +* [`DNS discovery`](../10/waku2.md/#discovery-domain) (based on [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459)) * `peer-exchange` (work in progress) * `33/WAKU2-DISCV5` (specified in this document) @@ -74,7 +74,7 @@ This also increases decentralization. isolated from the Ethereum Discovery v5 network. Another simple solution would be taking part in the Ethereum Discovery network, -and filtering Waku nodes based on whether they support [WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md). +and filtering Waku nodes based on whether they support [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md). This solution is more resilient towards eclipse attacks. However, this discovery method is very inefficient for small percentages of Waku nodes @@ -206,12 +206,12 @@ raises research questions that we will address in future stages of our discv5 ro 1. [10/WAKU2](../10/waku2.md) 1. [11/WAKU2-RELAY](../11/relay.md) -1. [`WAKU2-ENR`](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md) +1. [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md) 1. [Node Discovery Protocol v5 (`discv5`)](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) 1. [`discv5` semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md). 1. [`discv5` wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) 1. [`discv5` topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement) -1. [Waku DNS discovery](https://rfc.vac.dev/spec/10/#discovery-domain) +1. [Waku DNS discovery](../10/waku2.md/#discovery-domain) 1. [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md) 1. [`EIP-1459`](https://eips.ethereum.org/EIPS/eip-1459) 1. [`GossipSub`](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)