diff --git a/fetch-content.js b/fetch-content.js index bca226dbf..ae5e7164d 100644 --- a/fetch-content.js +++ b/fetch-content.js @@ -43,7 +43,7 @@ async function fetchFromGitHub(url, callback) { res.on('end', () => { const parsedData = JSON.parse(data) - console.log('parsedData:', parsedData) + // console.log('parsedData:', parsedData) callback(null, parsedData) }) }, @@ -70,7 +70,20 @@ async function fetchDirectoryContents(dirUrl, basePath, prefixToRemove) { new RegExp(`^${prefixToRemove}`), '', ) - const filePath = path.join(basePath, relativePath) + + function adjustPathForMarkdown(filePath) { + const parts = filePath.split('/') + + if (parts?.length === 1) return filePath + + if (parts[parts.length - 1].endsWith('.md')) { + parts.splice(parts.length - 2, 1) + } + + return parts.join('/') + } + + const filePath = path.join(basePath, adjustPathForMarkdown(relativePath)) if (file.type === 'file') { await downloadAndSaveFile(file.download_url, filePath) @@ -85,11 +98,14 @@ function parseSlugFromFrontmatter(content) { const frontmatterMatch = content.match(/---\s*\n([\s\S]*?)\n---/) if (frontmatterMatch) { const frontmatterContent = frontmatterMatch[1] - const slugMatch = frontmatterContent.match(/^slug:\s*(\d+)/m) - if (slugMatch) { - return parseInt(slugMatch[1], 10) + function extractNumberFromTitle(content) { + const parts = content.split('/') + return parseInt(parts[0].split(' ')[1], 10) } + + const number = extractNumberFromTitle(frontmatterContent) + return number } return 1 // Return null if not found } @@ -109,6 +125,12 @@ async function downloadAndSaveFile(url, filePath) { const fileExtension = path.extname(filePath) + function updateMarkdownImagePath(content, number) { + const regex = /(!\[.*?\]\(\.\/)images/g + + return content.replace(regex, `$1${number}/images`) + } + if (fileExtension === '.md' || fileExtension === '.mdx') { // Remove 'tags' line from frontmatter because the format is wrong content = content.replace(/tags:.*\n?/, '') @@ -129,6 +151,8 @@ async function downloadAndSaveFile(url, filePath) { // // parse sidebarPosition from the slug in the frontmatter const sidebarPosition = parseSlugFromFrontmatter(content) || 1 + content = updateMarkdownImagePath(content, sidebarPosition) + // Insert sidebar_position at the end of frontmatter if it doesn't exist if ( /^---\s*[\s\S]+?---/.test(content) && @@ -143,10 +167,10 @@ async function downloadAndSaveFile(url, filePath) { fs.writeFile(fullFilePath, content, err => { if (err) { - console.error('Error saving file:', err.message) + // console.error('Error saving file:', err.message) return } - console.log('Downloaded and saved:', filePath) + // console.log('Downloaded and saved:', filePath) }) }) }) @@ -163,6 +187,6 @@ directoriesToSync.forEach(dirName => { const prefixToRemove = dirName + '/' fetchDirectoryContents(baseUrl, baseSavePath, prefixToRemove).then(() => { - console.log(`Synced ${dirName}`) + // console.log(`Synced ${dirName}`) }) }) diff --git a/nomos/38/claro.md b/nomos/claro.md similarity index 99% rename from nomos/38/claro.md rename to nomos/claro.md index c94a256c3..2daf80cc4 100644 --- a/nomos/38/claro.md +++ b/nomos/claro.md @@ -10,7 +10,7 @@ uri: \ contributors: - Álvaro Castro-Castilla - Mark Evenson -sidebar_position: 1 +sidebar_position: 38 --- ## Abstract diff --git a/status/55/1to1-chat.md b/status/1to1-chat.md similarity index 94% rename from status/55/1to1-chat.md rename to status/1to1-chat.md index 794e051e0..b16014b8f 100644 --- a/status/55/1to1-chat.md +++ b/status/1to1-chat.md @@ -11,7 +11,7 @@ contributors: - Corey Petty \ - Oskar Thorén \ - Dean Eigenmann \ -sidebar_position: 1 +sidebar_position: 55 --- ## Abstract @@ -39,7 +39,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. @@ -66,7 +66,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) @@ -202,7 +202,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 @@ -211,10 +211,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) diff --git a/status/65/account-address.md b/status/account-address.md similarity index 99% rename from status/65/account-address.md rename to status/account-address.md index e81815c2b..4e163e1e0 100644 --- a/status/65/account-address.md +++ b/status/account-address.md @@ -9,7 +9,7 @@ contributors: - Corey Petty \ - Oskar Thorén \ - Samuel Hawksby-Robinson \ -sidebar_position: 1 +sidebar_position: 65 --- ## Abstract diff --git a/status/56/communities.md b/status/communities.md similarity index 99% rename from status/56/communities.md rename to status/communities.md index 672541b32..98dd61bdb 100644 --- a/status/56/communities.md +++ b/status/communities.md @@ -7,7 +7,7 @@ description: Status Communities allow multiple users to communicate in a discuss editor: Aaryamann Challani \ contributors: - Andrea Piana \ -sidebar_position: 1 +sidebar_position: 56 --- ## Abstract diff --git a/status/61/community-history-service.md b/status/community-history-service.md similarity index 98% rename from status/61/community-history-service.md rename to status/community-history-service.md index 835bb055a..27f6bebd3 100644 --- a/status/61/community-history-service.md +++ b/status/community-history-service.md @@ -8,7 +8,7 @@ editor: r4bbit \ contributors: - Sanaz Taheri \ - John Lea \ -sidebar_position: 1 +sidebar_position: 61 --- ## Abstract @@ -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) diff --git a/status/24/curation.md b/status/curation.md similarity index 99% rename from status/24/curation.md rename to status/curation.md index 3ba334175..b2658b79e 100644 --- a/status/24/curation.md +++ b/status/curation.md @@ -4,7 +4,7 @@ name: Status Community Directory Curation Voting using Waku v2 status: draft description: A voting protocol for SNT holders to submit votes to a smart contract. Voting is immutable, which helps avoid sabotage from malicious peers. editor: Szymon Szlachtowicz \ -sidebar_position: 1 +sidebar_position: 24 --- ## Abstract diff --git a/status/28/featuring.md b/status/featuring.md similarity index 99% rename from status/28/featuring.md rename to status/featuring.md index 55a669fc2..805b0c869 100644 --- a/status/28/featuring.md +++ b/status/featuring.md @@ -4,7 +4,7 @@ name: Status community featuring using waku v2 status: draft description: To gain new members, current SNT holders can vote to feature an active Status community to the larger Status audience. editor: Szymon Szlachtowicz \ -sidebar_position: 1 +sidebar_position: 28 --- ## Abstract diff --git a/status/63/keycard-usage.md b/status/keycard-usage.md similarity index 99% rename from status/63/keycard-usage.md rename to status/keycard-usage.md index b6bcc7cec..cf0b97da0 100644 --- a/status/63/keycard-usage.md +++ b/status/keycard-usage.md @@ -7,7 +7,7 @@ description: Describes how an application can use the Status Keycard to create, editor: Aaryamann Challani \ contributors: - Jimmy Debe \ -sidebar_position: 1 +sidebar_position: 63 --- ## Terminology diff --git a/status/62/payloads.md b/status/payloads.md similarity index 99% rename from status/62/payloads.md rename to status/payloads.md index 0ad70a0b2..bd409165f 100644 --- a/status/62/payloads.md +++ b/status/payloads.md @@ -8,7 +8,7 @@ contributors: - Andrea Maria Piana \ - Oskar Thoren \ - Samuel Hawksby-Robinson \ -sidebar_position: 1 +sidebar_position: 62 --- ## Abstract diff --git a/status/71/push-notification-server.md b/status/push-notification-server.md similarity index 99% rename from status/71/push-notification-server.md rename to status/push-notification-server.md index 72b30d981..1fac80f85 100644 --- a/status/71/push-notification-server.md +++ b/status/push-notification-server.md @@ -7,7 +7,7 @@ description: A set of methods to allow Status clients to use push notification s editor: Jimmy Debe \ contributors: - Andrea Maria Piana \ -sidebar_position: 1 +sidebar_position: 71 --- ## Abstract @@ -62,11 +62,11 @@ The party releasing the app MUST run its own [gorush](https://github.com/applebo ### Push Notification Server Flow #### Registration Process: -![registration](./images/registration.png) +![registration](./71/images/registration.png) #### Sending and Receiving Notification Process: -![notification](./images/notification.png) +![notification](./71/images/notification.png) ### Registering Client @@ -406,7 +406,7 @@ message PushNotificationResponse { Where `message_id` is the `message_id` sent by the client. #### Handle Notification Response: -- A `PushNotificationResponse` message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads.md) with type set to `PUSH_NOTIFICATION_RESPONSE`. +- A `PushNotificationResponse` message MUST be wrapped in a [`ApplicationMetadataMessage`](../62/payloads.md) with type set to��`PUSH_NOTIFICATION_RESPONSE`. - The response MUST be sent on the [partitioned topic](../../waku/standards/application/54/x3dh-sessions.md) of the sender and MUST not be encrypted using the [secure transport](../../waku/standards/application/53/x3dh.md) to facilitate the usage of ephemeral keys. diff --git a/status/raw/simple-scaling.md b/status/simple-scaling.md similarity index 99% rename from status/raw/simple-scaling.md rename to status/simple-scaling.md index a36672643..2fa3946f6 100644 --- a/status/raw/simple-scaling.md +++ b/status/simple-scaling.md @@ -7,7 +7,7 @@ description: Describes how to scale Status Communities and Status 1-to-1 chats u editor: Daniel Kaiser \ contributors: - Alvaro Revuelta \ -sidebar_position: 1 +sidebar_position: 57 --- ## Abstract diff --git a/status/raw/status-waku-usage.md b/status/status-waku-usage.md similarity index 100% rename from status/raw/status-waku-usage.md rename to status/status-waku-usage.md diff --git a/vac/README.md b/vac/README.md index 8e3a9ee0a..467da7773 100644 --- a/vac/README.md +++ b/vac/README.md @@ -1,9 +1,4 @@ -# Vac RFCs +# Vac Raw Specifications -Vac builds public good protocols for the decentralise web. -Vac acts as a custodian for the protocols that live in the RFC-Index repository. -With the goal of widespread adoption, -Vac will make sure the protocols adhere to the set of principles, -including but not limited to liberty, security, privacy, decentralisation, and inclusivity. - -To learn more, visit [Vac Research](https://vac.dev/) +All Vac specifications that have not reached **draft** status will live in this repository. +To learn more about **raw** specifications, take a look at [1/COSS](../1/coss.md). diff --git a/vac/1/coss.md b/vac/coss.md similarity index 99% rename from vac/1/coss.md rename to vac/coss.md index 7c7afdef4..641e97685 100644 --- a/vac/1/coss.md +++ b/vac/coss.md @@ -104,7 +104,7 @@ Every specification has an independent lifecycle that documents clearly its curr A specification has six possible states that reflect its maturity and contractual weight: -![Lifecycle diagram](./images/lifecycle.png) +![Lifecycle diagram](./1/images/lifecycle.png) ### Raw Specifications diff --git a/vac/70/eth-secpm.md b/vac/eth-secpm.md similarity index 99% rename from vac/70/eth-secpm.md rename to vac/eth-secpm.md index 85e2019ef..2f20dc19c 100644 --- a/vac/70/eth-secpm.md +++ b/vac/eth-secpm.md @@ -5,7 +5,7 @@ status: raw category: Standards Track editor: Ramses Fernandez \ contributors: -sidebar_position: 1 +sidebar_position: 70 --- ## Motivation @@ -16,7 +16,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: diff --git a/vac/46/gossipsub-tor-push.md b/vac/gossipsub-tor-push.md similarity index 99% rename from vac/46/gossipsub-tor-push.md rename to vac/gossipsub-tor-push.md index 34bddbfcb..dc395774a 100644 --- a/vac/46/gossipsub-tor-push.md +++ b/vac/gossipsub-tor-push.md @@ -5,7 +5,7 @@ status: raw category: Standards Track editor: Daniel Kaiser \ contributors: -sidebar_position: 1 +sidebar_position: 46 --- ## Abstract diff --git a/vac/25/libp2p-dns-discovery.md b/vac/libp2p-dns-discovery.md similarity index 95% rename from vac/25/libp2p-dns-discovery.md rename to vac/libp2p-dns-discovery.md index 5562ad440..7687db293 100644 --- a/vac/25/libp2p-dns-discovery.md +++ b/vac/libp2p-dns-discovery.md @@ -4,12 +4,12 @@ name: Libp2p Peer Discovery via DNS status: deleted editor: Hanno Cornelius \ contributors: -sidebar_position: 1 +sidebar_position: 25 --- `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/) diff --git a/vac/4/mvds-meta.md b/vac/mvds-meta.md similarity index 99% rename from vac/4/mvds-meta.md rename to vac/mvds-meta.md index 692239bde..9a1871c1e 100644 --- a/vac/4/mvds-meta.md +++ b/vac/mvds-meta.md @@ -7,7 +7,7 @@ contributors: - Dean Eigenmann \ - Andrea Maria Piana \ - Oskar Thorén \ -sidebar_position: 1 +sidebar_position: 4 --- In this specification, we describe a method to construct message history that will aid the consistency guarantees of [2/MVDS](../2/mvds.md). Additionally, we explain how data sync can be used for more lightweight messages that do not require full synchronization. diff --git a/vac/2/mvds.md b/vac/mvds.md similarity index 99% rename from vac/2/mvds.md rename to vac/mvds.md index eff014475..17e503a4e 100644 --- a/vac/2/mvds.md +++ b/vac/mvds.md @@ -6,7 +6,7 @@ editor: Sanaz Taheri \ contributors: - Dean Eigenmann \ - Oskar Thorén \ -sidebar_position: 1 +sidebar_position: 2 --- In this specification, we describe a minimum viable protocol for data synchronization inspired by the Bramble Synchronization Protocol[^1]. This protocol is designed to ensure reliable messaging between peers across an unreliable peer-to-peer (P2P) network where they may be unreachable or unresponsive. diff --git a/vac/raw/README.md b/vac/raw/README.md deleted file mode 100644 index 467da7773..000000000 --- a/vac/raw/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# Vac Raw Specifications - -All Vac specifications that have not reached **draft** status will live in this repository. -To learn more about **raw** specifications, take a look at [1/COSS](../1/coss.md). diff --git a/vac/3/remote-log.md b/vac/remote-log.md similarity index 99% rename from vac/3/remote-log.md rename to vac/remote-log.md index 3e0e54826..5f814a67e 100644 --- a/vac/3/remote-log.md +++ b/vac/remote-log.md @@ -5,7 +5,7 @@ status: draft editor: Oskar Thorén \ contributors: - Dean Eigenmann \ -sidebar_position: 1 +sidebar_position: 3 --- A remote log is a replication of a local log. This means a node can read data that originally came from a node that is offline. diff --git a/vac/48/rln-interep-spec.md b/vac/rln-interep-spec.md similarity index 99% rename from vac/48/rln-interep-spec.md rename to vac/rln-interep-spec.md index d6d3f8291..5ae02c988 100644 --- a/vac/48/rln-interep-spec.md +++ b/vac/rln-interep-spec.md @@ -5,7 +5,7 @@ status: raw category: editor: Aaryamann Challani \ contributors: -sidebar_position: 1 +sidebar_position: 48 --- ## Abstract diff --git a/vac/32/rln-v1.md b/vac/rln-v1.md similarity index 99% rename from vac/32/rln-v1.md rename to vac/rln-v1.md index 18d6837d7..30ce4acf8 100644 --- a/vac/32/rln-v1.md +++ b/vac/rln-v1.md @@ -9,7 +9,7 @@ contributors: - Oskar Thorén \ - Onur Kilic \ - Blagoj Dimovski \ -sidebar_position: 1 +sidebar_position: 32 --- ## Abstract @@ -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, diff --git a/vac/58/rln-v2.md b/vac/rln-v2.md similarity index 99% rename from vac/58/rln-v2.md rename to vac/rln-v2.md index 5deb0d47e..ee47b7af8 100644 --- a/vac/58/rln-v2.md +++ b/vac/rln-v2.md @@ -5,7 +5,7 @@ status: raw editor: Rasul Ibragimov \ contributors: - Lev Soukhanov \<0xdeadfae@gmail.com\> -sidebar_position: 1 +sidebar_position: 58 --- ## Abstract diff --git a/waku/README.md b/waku/README.md index 1ad1766d5..a203b2cc6 100644 --- a/waku/README.md +++ b/waku/README.md @@ -1,5 +1,6 @@ -## Waku RFCs +## Deprecated RFCs -Waku builds a family of privacy-preserving, censorship-resistant communication protocols for web3 applications. - -Contributors can visit [Waku RFCs](https://github.com/waku-org/specs) for new Waku specifications under discussion. +Deprecated specifications are no longer used in Waku products. +This subdirectory is for achrive purpose and +should not be used in production ready implementations. +Visit [Waku RFCs](https://github.com/waku-org/specs) for new Waku specifications under discussion. diff --git a/waku/deprecated/README.md b/waku/deprecated/README.md deleted file mode 100644 index a203b2cc6..000000000 --- a/waku/deprecated/README.md +++ /dev/null @@ -1,6 +0,0 @@ -## Deprecated RFCs - -Deprecated specifications are no longer used in Waku products. -This subdirectory is for achrive purpose and -should not be used in production ready implementations. -Visit [Waku RFCs](https://github.com/waku-org/specs) for new Waku specifications under discussion. diff --git a/waku/deprecated/5/waku0.md b/waku/deprecated/waku0.md similarity index 99% rename from waku/deprecated/5/waku0.md rename to waku/deprecated/waku0.md index 497f84fd4..58ffb01a1 100644 --- a/waku/deprecated/5/waku0.md +++ b/waku/deprecated/waku0.md @@ -8,7 +8,7 @@ contributors: - Andrea Maria Piana \ - Dean Eigenmann \ - Kim De Mey \ -sidebar_position: 1 +sidebar_position: 5 --- This specification describes the format of Waku messages within the ÐΞVp2p Wire Protocol. This spec substitutes [EIP-627](https://eips.ethereum.org/EIPS/eip-627). Waku is a fork of the original Whisper protocol that enables better usability for resource restricted devices, such as mostly-offline bandwidth-constrained smartphones. It does this through (a) light node support, (b) historic messages (with a mailserver) (c) expressing topic interest for better bandwidth usage and (d) basic rate limiting. diff --git a/waku/informational/30/images/adaptive_protocol_selection.jpg b/waku/informational/30/images/adaptive_protocol_selection.jpg index de04de0ec..6704ad3cf 100644 Binary files a/waku/informational/30/images/adaptive_protocol_selection.jpg and b/waku/informational/30/images/adaptive_protocol_selection.jpg differ diff --git a/waku/informational/30/adaptive-nodes.md b/waku/informational/adaptive-nodes.md similarity index 88% rename from waku/informational/30/adaptive-nodes.md rename to waku/informational/adaptive-nodes.md index caa929b66..c244e1bc2 100644 --- a/waku/informational/30/adaptive-nodes.md +++ b/waku/informational/adaptive-nodes.md @@ -4,7 +4,7 @@ name: Adaptive nodes status: draft editor: Oskar Thorén \ contributors: -sidebar_position: 1 +sidebar_position: 30 --- This is an informational spec that show cases the concept of adaptive nodes. @@ -13,7 +13,7 @@ This is an informational spec that show cases the concept of adaptive nodes. We can look at node types as a continuum, from more restricted to less restricted, fewer resources to more resources. -![Node types - a continuum](./images/adaptive_node_continuum2.png) +![Node types - a continuum](./30/images/adaptive_node_continuum2.png) ### Possible limitations @@ -53,7 +53,7 @@ Incentives to run a node is currently planned around: Each node can choose which protocols to support, depending on its resources and goals. -![Protocol selection](./images/adaptive_node_protocol_selection2.png) +![Protocol selection](./30/images/adaptive_node_protocol_selection2.png) In the case of protocols like [11/WAKU2-RELAY](../../standards/core/11/relay.md) etc (12, 13, 19, 21) these correspond to Libp2p protocols. @@ -69,11 +69,11 @@ We can better visualize the network with some illustrative examples. The first one shows an example topology with different PubSub topics for the relay protocol. -![Waku Network visualization](./images/adaptive_node_network_topology_protocols2.png) +![Waku Network visualization](./30/images/adaptive_node_network_topology_protocols2.png) ### Legend -![Waku Network visualization legend](./images/adaptive_node_network_topology_protocols_legend.png) +![Waku Network visualization legend](./30/images/adaptive_node_network_topology_protocols_legend.png) The dotted box shows what content topics (application-specific) a node is interested in. @@ -91,7 +91,7 @@ Behavior and interaction with other protocols specified in Vac RFCs, e.g. 25/LIB This one shows a cross-section of nodes in different dimensions and shows how the connections look different for different protocols. -![Node Cross Section](./images/adaptive_node_cross_section2.png) +![Node Cross Section](./30/images/adaptive_node_cross_section2.png) ## Copyright diff --git a/waku/informational/29/config.md b/waku/informational/config.md similarity index 99% rename from waku/informational/29/config.md rename to waku/informational/config.md index 887c5c131..03bb34b6f 100644 --- a/waku/informational/29/config.md +++ b/waku/informational/config.md @@ -4,7 +4,7 @@ name: Waku v2 Client Parameter Configuration Recommendations status: draft editor: Hanno Cornelius \ contributors: -sidebar_position: 1 +sidebar_position: 29 --- `29/WAKU2-CONFIG` describes the RECOMMENDED values to assign to configurable parameters for Waku v2 clients. diff --git a/waku/informational/27/peers.md b/waku/informational/peers.md similarity index 96% rename from waku/informational/27/peers.md rename to waku/informational/peers.md index f7b57596b..0eae009ce 100644 --- a/waku/informational/27/peers.md +++ b/waku/informational/peers.md @@ -4,7 +4,7 @@ name: Waku v2 Client Peer Management Recommendations status: draft editor: Hanno Cornelius \ contributors: -sidebar_position: 1 +sidebar_position: 27 --- `27/WAKU2-PEERS` describes a recommended minimal set of peer storage and peer management features to be implemented by Waku v2 clients. @@ -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) diff --git a/waku/informational/23/topics.md b/waku/informational/topics.md similarity index 97% rename from waku/informational/23/topics.md rename to waku/informational/topics.md index cefed9603..541ddd6d3 100644 --- a/waku/informational/23/topics.md +++ b/waku/informational/topics.md @@ -7,7 +7,7 @@ editor: Oskar Thoren \ contributors: - Hanno Cornelius \ - Daniel Kaiser \ -sidebar_position: 1 +sidebar_position: 23 --- This document outlines recommended usage of topic names in Waku v2. @@ -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) diff --git a/waku/informational/22/toy-chat.md b/waku/informational/toy-chat.md similarity index 98% rename from waku/informational/22/toy-chat.md rename to waku/informational/toy-chat.md index 5d8913f3d..dd84f2fab 100644 --- a/waku/informational/22/toy-chat.md +++ b/waku/informational/toy-chat.md @@ -5,7 +5,7 @@ status: draft editor: Franck Royer \ contributors: - Hanno Cornelius \ -sidebar_position: 1 +sidebar_position: 22 --- **Content Topic**: `/toy-chat/2/huilong/proto`. diff --git a/waku/standards/application/21/fault-tolerant-store.md b/waku/standards/application/fault-tolerant-store.md similarity index 69% rename from waku/standards/application/21/fault-tolerant-store.md rename to waku/standards/application/fault-tolerant-store.md index 6bca5bdce..4f0dbb943 100644 --- a/waku/standards/application/21/fault-tolerant-store.md +++ b/waku/standards/application/fault-tolerant-store.md @@ -4,17 +4,17 @@ name: Waku v2 Fault-Tolerant Store status: draft editor: Sanaz Taheri \ contributors: -sidebar_position: 1 +sidebar_position: 21 --- - 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) diff --git a/waku/standards/application/26/payload.md b/waku/standards/application/payload.md similarity index 87% rename from waku/standards/application/26/payload.md rename to waku/standards/application/payload.md index 5e91fb5f9..5b30ba36f 100644 --- a/waku/standards/application/26/payload.md +++ b/waku/standards/application/payload.md @@ -4,13 +4,13 @@ name: Waku Message Payload Encryption status: draft editor: Oskar Thoren \ contributors: -sidebar_position: 1 +sidebar_position: 26 --- This specification describes how Waku provides confidentiality, authenticity, and integrity, as well as some form of unlinkability. -Specifically, it describes how encryption, decryption and signing works in [6/WAKU1](../../standards/core/6/waku1.md) and in [10/WAKU2 spec](../../standards/core/10/waku2.md) with [14/WAKU-MESSAGE version 1](../../standards/core/14/message.md/#version1). +Specifically, it describes how encryption, decryption and signing works in [6/WAKU1](../../legacy/6/waku1.md) and in [10/WAKU2 spec](../../core/10/waku2.md) with [14/WAKU-MESSAGE version 1](../../core/14/message.md/#version1). -This specification effectively replaces [7/WAKU-DATA](../../standards/application/7/DATA.md) as well as [6/WAKU1 Payload encryption](../../standards/core/6/waku1.md/#payload-encryption) but written in a way that is agnostic and self-contained for Waku v1 and Waku v2. +This specification effectively replaces [7/WAKU-DATA](../../legacy/7/data.md) as well as [6/WAKU1 Payload encryption](../../legacy/6/waku1.md/#payload-encryption) but written in a way that is agnostic and self-contained for Waku v1 and Waku v2. Large sections of the specification originate from [EIP-627: Whisper spec](https://eips.ethereum.org/EIPS/eip-627) as well from [RLPx Transport Protocol spec (ECIES encryption)](https://github.com/ethereum/devp2p/blob/master/rlpx.md#ecies-encryption) with some modifications. @@ -42,9 +42,9 @@ ECIES is using the following cryptosystem: ## Specification -For 6/WAKU1, the `data` field is used in the `waku envelope`, and the field MAY contain the encrypted payload. +For [6/WAKU1](../../legacy/6/waku1.md), the `data` field is used in the `waku envelope`, and the field MAY contain the encrypted payload. -For 10/WAKU2, the `payload` field is used in `WakuMessage` and MAY contain the encrypted payload. +For [10/WAKU2 spec](../../core/10/waku2.md), the `payload` field is used in `WakuMessage` and MAY contain the encrypted payload. The fields that are concatenated and encrypted as part of the `data` (Waku v1) / `payload` (Waku v2) field are: - flags @@ -142,10 +142,10 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References -1. [6/WAKU1](../../standards/core/6/waku1.md) -2. [10/WAKU2 spec](../../standards/core/10/waku2.md) -3. [14/WAKU-MESSAGE version 1](../../standards/core/14/message.md/#version1) -4. [7/WAKU-DATA](../../standards/application/7/DATA.md) +1. [6/WAKU1](../../legacy/6/waku1.md) +2. [10/WAKU2 spec](../../core/10/waku2.md) +3. [14/WAKU-MESSAGE version 1](../../core/14/message.md/#version1) +4. [7/WAKU-DATA](../../legacy/7/data.md) 5. [EIP-627: Whisper spec](https://eips.ethereum.org/EIPS/eip-627) 6. [RLPx Transport Protocol spec (ECIES encryption)](https://github.com/ethereum/devp2p/blob/master/rlpx.md#ecies-encryption) 7. [Status 5/SECURE-TRANSPORT](https://specs.status.im/spec/5) diff --git a/waku/standards/application/18/swap.md b/waku/standards/application/swap.md similarity index 98% rename from waku/standards/application/18/swap.md rename to waku/standards/application/swap.md index b132df17c..bf19c4d52 100644 --- a/waku/standards/application/18/swap.md +++ b/waku/standards/application/swap.md @@ -4,7 +4,7 @@ name: Waku SWAP Accounting status: draft editor: Oskar Thorén \ contributor: Ebube Ud \ -sidebar_position: 1 +sidebar_position: 18 --- ## Abstract @@ -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) \