Broken Links + Change Editors (#26)

Fix to broken links, changed links, and added new editors to spec, 10,
12, 14, 17, 19.

status/55/1to1-chat.md

@@ -40,7 +40,7 @@ This document describes how 2 peers communicate with each other to send messages
 This protocol MAY use any key-exchange mechanism previously discussed -
 
 1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) 
-2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)
+2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
 
 This protocol can provide end-to-end encryption to give peers a strong degree of privacy and security. 
 Public chat messages are publicly readable by anyone since there's no permission model for who is participating in a public chat.
@@ -67,7 +67,7 @@ It is handled by the key-exchange protocol used. For example,
 
 1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md), the session management is described in [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md)
 
-2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md), the session management is described in [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise-sessions/noise-sessions.md)
+2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md), the session management is described in [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md)
 
 ## Negotiation of a 1:1 chat amongst multiple participants (group chat)
 
@@ -203,7 +203,7 @@ To change the display image of the group chat, group admins MUST use an `IMAGE_C
 
 ## Security Considerations
 
-1. Inherits the security considerations of the key-exchange mechanism used, e.g., [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) or [WAKU2-NOISE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)
+1. Inherits the security considerations of the key-exchange mechanism used, e.g., [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md) or [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
 
 ## Copyright
 
@@ -212,10 +212,10 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References
 
 1. [53/WAKU2-X3DH](../../waku/standards/application/53/x3dh.md)
-2. [35/WAKU2-NOISE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise.md)
+2. [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
 3. [65/STATUS-ACCOUNT](../65/account-address.md)
 4. [54/WAKU2-X3DH-SESSIONS](../../waku/standards/application/54/x3dh-sessions.md)
-5. [37/WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/noise-sessions/noise-sessions.md)
+5. [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md)
 6. [56/STATUS-COMMUNITIES](../56/communities.md)
 7. [chat_message.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/chat_message.proto#L1)
 8. [emoji_reaction.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/emoji_reaction.proto)

status/61/community-history-service.md

@@ -321,7 +321,7 @@ There are two scenarios in which member nodes can receive such a magnet link mes
 2. The member node requests messages for a time range of up to 30 days from store nodes (this is the case when a new community member joins a community)
 
 ### Downloading message archives
-When member nodes receive a message with a `CommunityMessageHistoryArchive` ([62/STATUS-PAYLOAD](../62/payload.md)) from the aforementioned channnel, they MUST extract the `magnet_uri` and pass it to their underlying BitTorrent client so they can fetch the latest message history archive index, which is the `index` file of the torrent (see [Creating message archive torrents](#creating-message-archive-torrents)).
+When member nodes receive a message with a `CommunityMessageHistoryArchive` ([62/STATUS-PAYLOADS](../62/payloads.md)) from the aforementioned channnel, they MUST extract the `magnet_uri` and pass it to their underlying BitTorrent client so they can fetch the latest message history archive index, which is the `index` file of the torrent (see [Creating message archive torrents](#creating-message-archive-torrents)).
 
 Due to the nature of distributed systems, there's no guarantee that a received message is the "last" message. This is especially true when member nodes request historical messages from store nodes. 
 
@@ -389,4 +389,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [Extensions for Peers to Send Metadata Files](https://www.bittorrent.org/beps/bep_0009.html)
 * [org channels spec](../56/communities.md)
 * [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md)
-* [62/STATUS-PAYLOAD](../62/payload.md)
+* [62/STATUS-PAYLOADS](../62/payloads.md)

vac/25/libp2p-dns-discovery.md

@@ -9,7 +9,7 @@ contributors:
 
 `25/LIBP2P-DNS-DISCOVERY` specifies a scheme to implement [`libp2p`](https://libp2p.io/) peer discovery via DNS for Waku v2.
 The generalised purpose is to retrieve an arbitrarily long, authenticated, updateable list of [`libp2p` peers](https://docs.libp2p.io/concepts/peer-id/) to bootstrap connection to a `libp2p` network.
-Since [`10/WAKU2`](https://rfc.vac.dev/spec/10/) currently specifies use of [`libp2p` peer identities](https://docs.libp2p.io/concepts/peer-id/),
+Since [`10/WAKU2`](../../waku/standards/core/10/waku2.md) currently specifies use of [`libp2p` peer identities](https://docs.libp2p.io/concepts/peer-id/),
 this method is suitable for a new Waku v2 node to discover other Waku v2 nodes to connect to.
 
 This specification is largely based on [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459),
@@ -126,7 +126,7 @@ Copyright and related rights waived via
 
 # References
 
-1. [`10/WAKU2`](https://rfc.vac.dev/spec/10/)
+1. [`10/WAKU2`](../../waku/standards/core/10/waku2.md)
 1. [EIP-1459: Client Protocol](https://eips.ethereum.org/EIPS/eip-1459#client-protocol)
 1. [EIP-1459: Node Discovery via DNS ](https://eips.ethereum.org/EIPS/eip-1459)
 1. [`libp2p`](https://libp2p.io/)

vac/32/rln-v1.md

@@ -52,7 +52,7 @@ Depending on the application requirements, the registration can be implemented i
 - centralized registrations, by using a central server
 - decentralized registrations, by using a smart contract
 
-What is important is that the users' identity commitments (explained in section [User Indetity](#user-identity)) are stored in a Merkle tree,
+What is important is that the users' identity commitments (explained in section [User Identity](#user-identity)) are stored in a Merkle tree,
 and the users can obtain a Merkle proof proving that they are part of the group.
 
 Also depending on the application requirements,

vac/70/eth-secpm.md

@@ -17,7 +17,7 @@ Therefore a decentralized approach to secure communication becomes increasingly
 offering a robust solution to address these challenges.
 
 This specification outlines a private messaging service using the Ethereum blockchain as authentication service. 
-Rooted in the existing [model](https://rfc.vac.dev/spec/20/), 
+Rooted in the existing [model](../../waku/standards/application/20/toy-eth-pm.md), 
 this proposal addresses the deficiencies related to forward privacy and authentication inherent in the current framework.
 The specification is divided into 3 sections:
 

waku/informational/23/topics.md

@@ -89,7 +89,7 @@ This is used for content based filtering.
 See [14/WAKU2-MESSAGE spec](../../standards/core/14/message.md) for where this is specified.
 Note that this doesn't impact routing of messages between relaying nodes,
 but it does impact how request/reply protocols such as 
-[12/WAKU2-FILTER](../../standards/core/14/filter.md) and [13/WAKU2-STORE](../../standards/core/13/store.md) are used.
+[12/WAKU2-FILTER](../../standards/core/12/filter.md) and [13/WAKU2-STORE](../../standards/core/13/store.md) are used.
 
 This is especially useful for nodes that have limited bandwidth,
 and only want to pull down messages that match this given content topic.
@@ -163,7 +163,7 @@ Copyright and related rights waived via
 * [RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/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/14/filter.md)
+* [12/WAKU2-FILTER](../../standards/core/12/filter.md)
 * [13/WAKU2-STORE](../../standards/core/13/store.md)
 * [6/WAKU1](../../deprecated/5/waku0.md)
 * [15/WAKU-BRIDGE](../../standards/core/15/bridge.md)

waku/informational/27/peers.md

@@ -74,7 +74,7 @@ This requires keeping track of the [last time each peer was disconnected](#track
 
 A Waku v2 client MAY choose to implement a keep-alive mechanism to certain peers.
 If a client chooses to implement keep-alive on a connection,
-it SHOULD do so by sending periodic [libp2p pings](https://docs.libp2p.io/concepts/protocols/#ping) as per `10/WAKU2` [client recommendations](../../standards/core/10/WAKU2.md/#recommendations-for-clients).
+it SHOULD do so by sending periodic [libp2p pings](https://docs.libp2p.io/concepts/protocols/#ping) as per `10/WAKU2` [client recommendations](../../standards/core/10/waku2.md/#recommendations-for-clients).
 The recommended period between pings SHOULD be _at most_ 50% of the shortest idle connection timeout for the specific client and transport.
 For example, idle TCP connections often times out after 10 to 15 minutes.
 
@@ -96,4 +96,4 @@ Copyright and related rights waived via
 - [`18/WAKU2-SWAP`](../../standards/application/18/swap.md)
 - [backing off period](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#prune-backoff-and-peer-exchange)
 - [libp2p pings](https://docs.libp2p.io/concepts/protocols/#ping)
-- [`10/WAKU2` client recommendations](https://rfc.vac.dev/spec/10/#recommendations-for-clients)
+- [`10/WAKU2` client recommendations](../../standards/core/10/waku2.md/#recommendations-for-clients)

waku/standards/application/18/swap.md

@@ -141,7 +141,7 @@ In the soft phase only accounting is performed, without consequence for the
 peers. No disconnect or sending of cheques is performed at this tage.
 
 SWAP protocol is performed in conjunction with another request-reply protocol to account for its usage.
-It SHOULD be done for [13/WAKU2-STORE](../../standards/core/13/store.md)
+It SHOULD be done for [13/WAKU2-STORE](../../core/13/store.md)
 and it MAY be done for other request/reply protocols.
 
 A client SHOULD log accounting state per peer
@@ -173,7 +173,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 1. [Prisoner's Dilemma](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma)
 2. [Axelrod - Evolution of Cooperation (book)](https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation)
 3. [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth)
-4. [13/WAKU2-STORE](../../standards/core/13/store.md)
+4. [13/WAKU2-STORE](../../core/13/store.md)
 
 <!--
 

waku/standards/application/20/toy-eth-pm.md

@@ -46,10 +46,10 @@ The proposed protocol MUST adhere to the following design requirements:
 2. Bob is willing to participate to Eth-PM, and publishes `B'`,
 3. Bob's ownership of `B'` MUST be verifiable,
 4. Alice wants to send message `M` to Bob,
-5. Bob SHOULD be able to get `M` using [10/WAKU2 spec](../../standards/core/10/waku2.md),
+5. Bob SHOULD be able to get `M` using [10/WAKU2 spec](../../core/10/waku2.md),
 6. Participants only have access to their Ethereum Wallet via the Web3 API,
 7. Carole MUST NOT be able to read `M`'s content even if she is storing it or relaying it,
-8. [Waku Message Version 1](../../standards/application/26/payload.md) Asymmetric Encryption is used for encryption purposes.
+8. [Waku Message Version 1](../26/payload.md) Asymmetric Encryption is used for encryption purposes.
 
 ## Limitations
 
@@ -155,7 +155,7 @@ it is not enough in itself to deduce Bob's Public Key.
 This is why the protocol dictates that Bob MUST send his Public Key first,
 and Alice MUST receive it before she can send him a message.
 
-Moreover, nim-waku, the reference implementation of [13/WAKU2-STORE](../../standards/core/13/store.md)),
+Moreover, nim-waku, the reference implementation of [13/WAKU2-STORE](../../core/13/store.md),
 stores messages for a maximum period of 30 days.
 This means that Bob would need to broadcast his public key at least every 30 days to be reachable.
 
@@ -202,10 +202,10 @@ Alice MAY monitor the Waku v2 to collect Ethereum Address and Encryption Public
 Alice SHOULD verify that the `signature`s of `PublicKeyMessage`s she receives are valid as per EIP-712.
 She SHOULD drop any message without a signature or with an invalid signature.
 
-Using Bob's Encryption Public Key, retrieved via [10/WAKU2](../../standards/core/10/waku2.md), Alice MAY now send an encrypted message to Bob.
+Using Bob's Encryption Public Key, retrieved via [10/WAKU2 spec](../../core/10/waku2.md), Alice MAY now send an encrypted message to Bob.
 
 If she wishes to do so, Alice MUST encrypt her message `M` using Bob's Encryption Public Key `B'`,
-as per [26/WAKU-PAYLOAD Asymmetric Encryption specs](../../standards/application/26/payload.md/#asymmetric).
+as per [26/WAKU-PAYLOAD Asymmetric Encryption specs](../26/payload.md/#asymmetric).
 
 Alice SHOULD now publish this message on the Private Message content topic.
 
@@ -214,12 +214,12 @@ Alice SHOULD now publish this message on the Private Message content topic.
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
 
 ## References
-- [10/WAKU2 spec](../../standards/core/10/waku2.md)
-- [Waku Message Version 1](../../standards/application/26/payload.md)
+- [10/WAKU2 spec](../../core/10/waku2.md)
+- [Waku Message Version 1](../26/payload.md)
 - [X3DH](https://www.signal.org/docs/specifications/x3dh/)
 - [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
 - [Status secure transport spec](https://specs.status.im/spec/5)
 - [EIP-712](https://eips.ethereum.org/EIPS/eip-712)
-- [13/WAKU2-STORE](../../standards/core/13/store.md))
+- [13/WAKU2-STORE](../../core/13/store.md)
 - [The Graph](https://thegraph.com/)
 

waku/standards/application/21/fault-tolerant-store.md

@@ -7,14 +7,14 @@ editor: Sanaz Taheri <sanaz@status.im>
 contributors:
 ---
 
- The reliability of [13/WAKU2-STORE](../../standards/core/13/store.md) protocol heavily relies on the fact that full nodes i.e., those who persist messages have high availability and uptime and do not miss any messages. 
+ The reliability of [13/WAKU2-STORE](../../core/13/store.md) protocol heavily relies on the fact that full nodes i.e., those who persist messages have high availability and uptime and do not miss any messages. 
  If a node goes offline, then it will risk missing all the messages transmitted in the network during that time. 
  In this specification, we provide a method that makes the store protocol resilient in presence of faulty nodes. 
  Relying on this method,  nodes that have been offline for a time window will be able to fix the gap in their message history when getting back online. 
  Moreover, nodes with lower availability and uptime can leverage this method to reliably provide the store protocol services as a full node.
 
 ## Method description 
- As the first step towards making the [13/WAKU2-STORE](../../standards/core/13/store.md) protocol fault-tolerant, we introduce a new type of time-based query through which nodes fetch message history from each other based on their desired time window. 
+ As the first step towards making the [13/WAKU2-STORE](../../core/13/store.md) protocol fault-tolerant, we introduce a new type of time-based query through which nodes fetch message history from each other based on their desired time window. 
  This method operates based on the assumption that the querying node knows some other nodes in the store protocol which have been online for that targeted time window.  
 
 ## Security Consideration
@@ -23,7 +23,7 @@ The main security consideration to take into account while using this method is
 This will gradually result in the extraction of the node's activity pattern which can lead to inference attacks. 
 
 ## Wire Specification
-We extend the [HistoryQuery](../../standards/core/13/store.md/#payloads) protobuf message with two fields of `start_time` and `end_time` to signify the time range to be queried. 
+We extend the [HistoryQuery](../../core/13/store.md/#payloads) protobuf message with two fields of `start_time` and `end_time` to signify the time range to be queried. 
 
 ### Payloads
 
@@ -46,10 +46,10 @@ message HistoryQuery {
 RPC call to query historical messages.
 - `start_time`: this field MAY be filled out to signify the starting point of the queried time window. 
   This field holds the Unix epoch time in nanoseconds.  
-  The `messages` field of the corresponding [`HistoryResponse`](../../standards/core/13/store.md/#HistoryResponse) MUST contain historical waku messages whose [`timestamp`](../../standards/core/14/message.md/#Payloads) is larger than or equal to the `start_time`.
+  The `messages` field of the corresponding [`HistoryResponse`](../../core/13/store.md/#HistoryResponse) MUST contain historical waku messages whose [`timestamp`](../../core/14/message.md/#Payloads) is larger than or equal to the `start_time`.
 - `end_time` this field MAY be filled out to signify the ending point of the queried time window. 
   This field holds the Unix epoch time in nanoseconds.
-  The `messages` field of the corresponding [`HistoryResponse`](../../standards/core/13/store.md/#HistoryResponse) MUST contain historical waku messages whose [`timestamp`](../../standards/core/14/message.md/#Payloads) is less than or equal to the `end_time`.
+  The `messages` field of the corresponding [`HistoryResponse`](../../core/13/store.md/#HistoryResponse) MUST contain historical waku messages whose [`timestamp`](../../core/14/message.md/#Payloads) is less than or equal to the `end_time`.
 
   A time-based query is considered valid if its `end_time` is larger than or equal to the `start_time`. 
   Queries that do not adhere to this condition will not get through e.g. an open-end time query in which the `start_time` is given but no  `end_time` is supplied is not valid. 
@@ -61,7 +61,7 @@ In order to account for nodes asynchrony, and assuming that nodes may be out of
 That is if the original window is [`l`,`r`] then the history query SHOULD be made for `[start_time: l - 20s, end_time: r + 20s]`.
 
 Note that `HistoryQuery` preserves `AND` operation among the queried attributes. 
-As such,  The `messages` field of the corresponding [`HistoryResponse`](../../standards/core/13/store.md/#HistoryResponse) MUST contain historical waku messages that satisfy the indicated  `pubsubtopic` AND `contentFilters` AND the time range [`start_time`, `end_time`]. 
+As such,  The `messages` field of the corresponding [`HistoryResponse`](../../core/13/store.md/#HistoryResponse) MUST contain historical waku messages that satisfy the indicated  `pubsubtopic` AND `contentFilters` AND the time range [`start_time`, `end_time`]. 
 
 ## Copyright
 
@@ -70,5 +70,5 @@ Copyright and related rights waived via
 
 ## References
 
-- [13/WAKU2-STORE](../../standards/core/13/store.md)
+- [13/WAKU2-STORE](../../core/13/store.md)
 - [`timestamp`](../../standards/core/14/message.md/#Payloads)