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.

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/<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)

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
 

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 <[email protected]>
 contributors:

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)

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)
 

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)

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)

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)