mirror of
https://github.com/vacp2p/rfc-index.git
synced 2026-01-06 22:34:02 -05:00
Update Waku Links (#104)
Change Waku links that do not point to master waku/specs repo. Also update title for template, to look better on the rfc website.
This commit is contained in:
@@ -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/<cluster_id>/<shard_number>`
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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 <danielkaiser@status.im>
|
||||
contributors:
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
Reference in New Issue
Block a user