navbar reorg
This commit is contained in:
LordGhostX
parent
d115884dc1
commit
772b3465f9
|
|
@ -6,7 +6,7 @@ Get involved in Waku's open-source initiatives to improve the protocols, SDKs, d
|
|||
|
||||
- [Operating a node](/guides/sdks-and-nodes#operate-a-waku-node) within your application.
|
||||
- [Reporting bugs](#report-a-bug) and [suggesting missing features](#suggest-a-feature) to the development team.
|
||||
- Inspiring other developers to explore and use Waku for [various use cases](/getting-started/use-cases).
|
||||
- Inspiring other developers to explore and use Waku for [various use cases](/overview/use-cases).
|
||||
|
||||
Begin your journey by visiting the [SDKs and Nodes](/guides/sdks-and-nodes) guide and start building on Waku today!
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Content Topics
|
||||
---
|
||||
|
||||
`Content Topics` are metadata strings set by developers on outgoing messages to facilitate protocol-level features like selectively processing incoming messages ([Relay](/getting-started/concepts/protocols#relay) or [Filter](/getting-started/concepts/protocols#filter)) and retrieving historical messages ([Store](/getting-started/concepts/protocols#store)) that meet specific filtering criteria. Please refer to the [WAKU2-TOPICS](https://rfc.vac.dev/spec/23/#content-topics) specification to learn more.
|
||||
`Content Topics` are metadata strings set by developers on outgoing messages to facilitate protocol-level features like selectively processing incoming messages ([Relay](/overview/concepts/protocols#relay) or [Filter](/overview/concepts/protocols#filter)) and retrieving historical messages ([Store](/overview/concepts/protocols#store)) that meet specific filtering criteria. Please refer to the [WAKU2-TOPICS](https://rfc.vac.dev/spec/23/#content-topics) specification to learn more.
|
||||
|
||||
## Content Topic Format
|
||||
|
||||
|
|
@ -34,4 +34,4 @@ Waku is developing privacy-preserving features like [Anonymous Filter Subscripti
|
|||
|
||||
You can preserve the anonymity of individual identities by increasing [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/), where k is proportional to the network size (number of subscribers). This involves using a single content topic across the entire application or specific features such as notifications or private messages, allowing multiple users to share it.
|
||||
|
||||
However, maintaining functionality with a single content topic can introduce complexity. We recommend switching functionality using the Protocol Buffer message format or the [Waku Message](/getting-started/concepts/protocols#waku-message) `meta` attribute. By doing so, applications can retain a high granularity and functionality while using a single content topic, preserving user privacy.
|
||||
However, maintaining functionality with a single content topic can introduce complexity. We recommend switching functionality using the Protocol Buffer message format or the [Waku Message](/overview/concepts/protocols#waku-message) `meta` attribute. By doing so, applications can retain a high granularity and functionality while using a single content topic, preserving user privacy.
|
||||
|
|
@ -6,21 +6,21 @@ Waku is a unified and cohesive entity that offers a rich ecosystem with three di
|
|||
|
||||
## Discovery Domain
|
||||
|
||||
Peer discovery in Waku facilitates locating other nodes within the network. As a modular protocol, Waku incorporates various discovery mechanisms, such as [Discv5](/getting-started/concepts/peer-discovery#discv5) and [Peer Exchange](/getting-started/concepts/peer-discovery#peer-exchange). These mechanisms allow developers to choose the most suitable option(s) for their specific use cases and user environments, including mobile phones, desktop browsers, servers, and more.
|
||||
Peer discovery in Waku facilitates locating other nodes within the network. As a modular protocol, Waku incorporates various discovery mechanisms, such as [Discv5](/overview/concepts/peer-discovery#discv5) and [Peer Exchange](/overview/concepts/peer-discovery#peer-exchange). These mechanisms allow developers to choose the most suitable option(s) for their specific use cases and user environments, including mobile phones, desktop browsers, servers, and more.
|
||||
|
||||
## Gossip Domain
|
||||
|
||||
GossipSub derives its name from the practice within Pub/Sub networks where peers gossip about the messages they have encountered, thus establishing a message delivery network.
|
||||
|
||||
Waku employs gossiping through [Relay](/getting-started/concepts/protocols#relay) to distribute messages across the network. Additionally, Waku introduces [RLN Relay](/getting-started/concepts/protocols#rln-relay), an experimental mechanism that combines privacy preservation and economic spam protection.
|
||||
Waku employs gossiping through [Relay](/overview/concepts/protocols#relay) to distribute messages across the network. Additionally, Waku introduces [RLN Relay](/overview/concepts/protocols#rln-relay), an experimental mechanism that combines privacy preservation and economic spam protection.
|
||||
|
||||
## Request/Response Domain
|
||||
|
||||
Waku provides a set of protocols to optimize its performance in resource-limited environments like low bandwidth or mostly offline scenarios for multiple purposes.
|
||||
|
||||
- [Store](/getting-started/concepts/protocols#store) enables the retrieval of historical messages.
|
||||
- [Filter](/getting-started/concepts/protocols#filter) efficiently retrieves a subset of messages to conserve bandwidth.
|
||||
- [Light Push](/getting-started/concepts/protocols#light-push) facilitates message publication for nodes with limited bandwidth and short connection windows.
|
||||
- [Store](/overview/concepts/protocols#store) enables the retrieval of historical messages.
|
||||
- [Filter](/overview/concepts/protocols#filter) efficiently retrieves a subset of messages to conserve bandwidth.
|
||||
- [Light Push](/overview/concepts/protocols#light-push) facilitates message publication for nodes with limited bandwidth and short connection windows.
|
||||
|
||||
## Overview of Protocol Interaction
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ D ->> E: HistoryResponse(msg1, ...) (6)
|
|||
|
||||
The Pub/Sub topic `pubtopic1` serves as a means of routing messages (the network employs a default Pub/Sub topic) and indicates that it is subscribed to messages on that topic for a relay. Node D serves as a `Store` and is responsible for persisting messages.
|
||||
|
||||
1. Node A creates a WakuMessage `msg1` with [Content Topic](/getting-started/concepts/content-topics) `contentTopic1`.
|
||||
1. Node A creates a WakuMessage `msg1` with [Content Topic](/overview/concepts/content-topics) `contentTopic1`.
|
||||
2. Node F requests to get messages filtered by Pub/Sub topic `pubtopic1` and Content Topic `contentTopic1`. Node D subscribes F to this filter and will forward messages that match that filter in the future.
|
||||
3. Node A publishes `msg1` on `pubtopic1`. The message is sent from Node A to Node B and then forwarded to Node D.
|
||||
4. Node D, upon receiving `msg1` both stores the message for future retrieval by other nodes and forwards it to Node C.
|
||||
|
|
@ -6,9 +6,9 @@ When initializing a Waku node, it must connect with other peers to enable messag
|
|||
|
||||
Once a connection is established, the node must actively seek out additional peers to have:
|
||||
|
||||
- Sufficient peers in the [Relay](/getting-started/concepts/protocols#relay) mesh: The goal is to have at least 6 peers in the mesh. This ensures a robust network where messages can be efficiently relayed.
|
||||
- Sufficient peers in the [Relay](/overview/concepts/protocols#relay) mesh: The goal is to have at least 6 peers in the mesh. This ensures a robust network where messages can be efficiently relayed.
|
||||
- Reserve peers for backup: It is essential to have a surplus of peers available as reserves. These reserves are backups when the current peers become overloaded or experience unexpected disconnections.
|
||||
- Peers with specific capabilities: The node seeks out peers with specific capabilities, such as [Store](/getting-started/concepts/protocols#store), [Light Push](/getting-started/concepts/protocols#light-push), or [Filter](/getting-started/concepts/protocols#filter). This allows for targeted interactions and enhanced functionality based on the desired capabilities.
|
||||
- Peers with specific capabilities: The node seeks out peers with specific capabilities, such as [Store](/overview/concepts/protocols#store), [Light Push](/overview/concepts/protocols#light-push), or [Filter](/overview/concepts/protocols#filter). This allows for targeted interactions and enhanced functionality based on the desired capabilities.
|
||||
|
||||
## Predefined Nodes
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ Waku takes a modular approach, providing a range of protocols that enable applic
|
|||
|
||||
## [Filter](https://rfc.vac.dev/spec/12/)
|
||||
|
||||
`Filter` protocol allows light nodes to selectively subscribe to specific messages transmitted by other peers using [content topics](/getting-started/concepts/content-topics). It is designed to be a lightweight alternative for accessing the `Relay` network, particularly tailored for devices with limited bandwidth.
|
||||
`Filter` protocol allows light nodes to selectively subscribe to specific messages transmitted by other peers using [content topics](/overview/concepts/content-topics). It is designed to be a lightweight alternative for accessing the `Relay` network, particularly tailored for devices with limited bandwidth.
|
||||
|
||||
:::info
|
||||
`Filter` protocol helps optimize bandwidth usage, but it has fewer privacy guarantees as it must disclose the content topic to its peers to retrieve messages.
|
||||
|
|
@ -30,7 +30,7 @@ Using `Relay` and `Filter` protocols is recommended when a node is online, as `S
|
|||
|
||||
## [Light Push](https://rfc.vac.dev/spec/19/)
|
||||
|
||||
`Light Push` is a [Request/Response](/getting-started/concepts/network-domains#requestresponse-domain) protocol for nodes with limited bandwidth and short connection windows. It allows a client to receive an acknowledgment when sending messages, indicating that at least one peer has received them. Subsequently, the remote peer forwards these messages to the `Relay` network.
|
||||
`Light Push` is a [Request/Response](/overview/concepts/network-domains#requestresponse-domain) protocol for nodes with limited bandwidth and short connection windows. It allows a client to receive an acknowledgment when sending messages, indicating that at least one peer has received them. Subsequently, the remote peer forwards these messages to the `Relay` network.
|
||||
|
||||
:::info
|
||||
While the `Light Push` protocol acknowledges the receipt by the remote peer, it does not guarantee network-wide propagation.
|
||||
|
|
@ -40,7 +40,7 @@ While the `Light Push` protocol acknowledges the receipt by the remote peer, it
|
|||
|
||||
`Waku Message` specifies the message structure used in the Waku network. It defines the attributes and metadata fields that accompany a message, including the following:
|
||||
|
||||
- `content_topic` attribute for [content-based filtering](/getting-started/concepts/content-topics).
|
||||
- `content_topic` attribute for [content-based filtering](/overview/concepts/content-topics).
|
||||
- `payload` attribute containing the message data payload to be sent.
|
||||
- `meta` attribute for conveying additional details to various protocols for application-specific processing.
|
||||
- `timestamp` attribute signifying the time at which the message was generated by its sender.
|
||||
|
|
@ -37,7 +37,7 @@ Waku can cater to applications that require privacy guarantees, such as:
|
|||
|
||||
- Pseudonymity and not being tied to any Personally Identifiable Information (PII).
|
||||
- Metadata protection in transit.
|
||||
- Various forms of [unlinkability](/getting-started/reference/security-features#anonymityunlinkability).
|
||||
- Various forms of [unlinkability](/overview/reference/security-features#anonymityunlinkability).
|
||||
|
||||
### Modular Design
|
||||
|
||||
|
|
@ -55,13 +55,13 @@ These options are part of the [Anonymity Trilemma](https://eprint.iacr.org/2017/
|
|||
Waku provides developers with a convenient solution for building decentralized communication systems, eliminating the need to start from scratch or depend on centralized systems. Node operators can offer several services, such as:
|
||||
|
||||
- Storing messages for offline devices.
|
||||
- Enabling bandwidth-saving access to the [Relay](/getting-started/concepts/protocols#relay) network through [Light Push](/getting-started/concepts/protocols#light-push) and [Filter](/getting-started/concepts/protocols#filter) protocols.
|
||||
- Enabling bandwidth-saving access to the [Relay](/overview/concepts/protocols#relay) network through [Light Push](/overview/concepts/protocols#light-push) and [Filter](/overview/concepts/protocols#filter) protocols.
|
||||
- Implementing spam prevention and DoS mitigation features.
|
||||
- Providing a resilient and shared [Relay](/getting-started/concepts/protocols#relay) infrastructure that applications can leverage to enhance reliability and efficiency.
|
||||
- Providing a resilient and shared [Relay](/overview/concepts/protocols#relay) infrastructure that applications can leverage to enhance reliability and efficiency.
|
||||
|
||||
## How Does Waku Work?
|
||||
|
||||
The [Relay](/getting-started/concepts/protocols#relay) protocol is the foundation of the Waku network, which employs a Pub/Sub architecture built on the [libp2p GossipSub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). Additionally, various other Waku protocols have been created to facilitate specific functionalities, including but not limited to:
|
||||
The [Relay](/overview/concepts/protocols#relay) protocol is the foundation of the Waku network, which employs a Pub/Sub architecture built on the [libp2p GossipSub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). Additionally, various other Waku protocols have been created to facilitate specific functionalities, including but not limited to:
|
||||
|
||||
1. Facilitating the retrieval of historical messages for mostly offline devices.
|
||||
2. Providing solutions for encrypted communication, such as symmetric encryption, ECIES/asymmetric encryption, and noise handshake-based key turns.
|
||||
|
|
@ -10,7 +10,7 @@ Definitions and usage of the terminology used in the Waku ecosystem.
|
|||
|
||||
Bootstrapping is the initial entry point of a [node](#node) to the [Waku network](#waku). Once connected, other [peer discovery](#peer-discovery) methods can be employed to establish connections with fellow peers.
|
||||
|
||||
### [Content Topic](/getting-started/concepts/content-topics)
|
||||
### [Content Topic](/overview/concepts/content-topics)
|
||||
|
||||
A content topic is a string attached to [messages](#waku-message) to enable [protocol-level](#protocol) features like selective message processing and retrieval based on specific criteria.
|
||||
|
||||
|
|
@ -18,11 +18,11 @@ A content topic is a string attached to [messages](#waku-message) to enable [pro
|
|||
|
||||
Dappnode is an open-source platform that simplifies the hosting and management of decentralized applications and blockchain nodes, including [Waku](#waku).
|
||||
|
||||
### [Discv5](/getting-started/concepts/peer-discovery#discv5)
|
||||
### [Discv5](/overview/concepts/peer-discovery#discv5)
|
||||
|
||||
Discv5 is a [peer discovery](#peer-discovery) mechanism using a Distributed Hash Table (DHT) to store [ENR](#enr) records, providing censorship resistance, load distribution, and enhanced network resilience.
|
||||
|
||||
### [DNS Discovery](/getting-started/concepts/peer-discovery#dns-discovery)
|
||||
### [DNS Discovery](/overview/concepts/peer-discovery#dns-discovery)
|
||||
|
||||
DNS discovery is a [peer discovery](#peer-discovery) mechanism that allows the retrieval of an [ENR](#enr) tree from the TXT field of a domain name, enabling the storage of [node](#node) connection details and promoting decentralization.
|
||||
|
||||
|
|
@ -30,11 +30,11 @@ DNS discovery is a [peer discovery](#peer-discovery) mechanism that allows the r
|
|||
|
||||
Ethereum Node Record (ENR) is a specification used to represent and identify [nodes](#node), facilitating [discovery](#peer-discovery) and communication within the network. Besides connection details, `Waku ENR` also includes node configuration information like enabled protocol and shards.
|
||||
|
||||
### [Filter](/getting-started/concepts/protocols#filter)
|
||||
### [Filter](/overview/concepts/protocols#filter)
|
||||
|
||||
Filter is a [protocol](#protocol) that enables [light nodes](#light-node) to selectively subscribe to specific [messages](#waku-message) transmitted by [peers](#peer) using [content topics](#content-topic). It is designed to be a lightweight alternative for accessing the [Relay](#relay) network.
|
||||
|
||||
### [GossipSub](/getting-started/concepts/network-domains#gossip-domain)
|
||||
### [GossipSub](/overview/concepts/network-domains#gossip-domain)
|
||||
|
||||
GossipSub is a [protocol](#protocol) for efficient and scalable information dissemination in decentralized networks commonly used in blockchain systems.
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ GossipSub is a [protocol](#protocol) for efficient and scalable information diss
|
|||
|
||||
A light node is a [resource-limited](#resource-limited) device or client that leverages service nodes to access the [Relay](#relay) network.
|
||||
|
||||
### [Light Push](/getting-started/concepts/protocols#light-push)
|
||||
### [Light Push](/overview/concepts/protocols#light-push)
|
||||
|
||||
Light push is a protocol enabling [light nodes](#light-node) to send [messages](#waku-message) to the [Relay](#relay) network and receive acknowledgments confirming that a [peer](#peer) has received them.
|
||||
|
||||
|
|
@ -62,15 +62,15 @@ The payload field in a [Waku Message](#waku-message) contains the application da
|
|||
|
||||
A peer refers to other [nodes](#node) and participants of the [Waku network](#waku) with whom communication and interaction are possible.
|
||||
|
||||
### [Peer Discovery](/getting-started/concepts/peer-discovery)
|
||||
### [Peer Discovery](/overview/concepts/peer-discovery)
|
||||
|
||||
Peer discovery is the process where a [node](#node) locates and connects with [peers](#peer) to establish communication and exchange information.
|
||||
|
||||
### [Peer Exchange](/getting-started/concepts/peer-discovery#peer-exchange)
|
||||
### [Peer Exchange](/overview/concepts/peer-discovery#peer-exchange)
|
||||
|
||||
Peer exchange is a [peer discovery](#peer-discovery) mechanism that enables [light nodes](#light-node) to request and receive peers from other nodes in the network, allowing them to bootstrap and expand their connections without depending on [Discv5](#discv5).
|
||||
|
||||
### [Protocol](/getting-started/concepts/protocols)
|
||||
### [Protocol](/overview/concepts/protocols)
|
||||
|
||||
A protocol is a set of rules that enables [nodes](#node) within the [Waku network](#waku) to perform various functionalities such as message sending, relaying, filtering, storing, retrieving, and more.
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ A Pub/Sub topic is a string that serves as an identifier for the topic of intere
|
|||
|
||||
Rate Limit Nullifiers (RLN) are a construct based on zero-knowledge proofs that provide an anonymous rate-limited messaging framework, preserving message owner anonymity while preventing spam or DoS attacks.
|
||||
|
||||
### [Relay](/getting-started/concepts/protocols#relay)
|
||||
### [Relay](/overview/concepts/protocols#relay)
|
||||
|
||||
Relay is a [protocol](#protocol) that extends the [GossipSub protocol](#gossipsub) to enable secure and censorship-resistant [message](#waku-message) dissemination among [peers](#peer) while preserving privacy.
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ Relay is a [protocol](#protocol) that extends the [GossipSub protocol](#gossipsu
|
|||
|
||||
Resource-limited refers to environments or devices restricting available resources, including bandwidth, CPU, memory, disk, and battery power.
|
||||
|
||||
### [RLN Relay](/getting-started/concepts/protocols#rln-relay)
|
||||
### [RLN Relay](/overview/concepts/protocols#rln-relay)
|
||||
|
||||
RLN Relay is an extension of the [Relay protocol](#relay) that uses [Rate Limit Nullifiers (RLN)](#rate-limit-nullifiers) to prevent spam economically by enforcing bandwidth caps, imposing penalties, and facilitating network removal for spammers.
|
||||
|
||||
|
|
@ -102,11 +102,11 @@ RLN Relay is an extension of the [Relay protocol](#relay) that uses [Rate Limit
|
|||
|
||||
SDKs are tools, libraries, and resources to integrate Waku's private, secure, and censorship-free communication features into various applications.
|
||||
|
||||
### [Store](/getting-started/concepts/protocols#store)
|
||||
### [Store](/overview/concepts/protocols#store)
|
||||
|
||||
Store is a [protocol](#protocol) that enables the storage of relayed [messages](#waku-message) in the network, allowing offline peers to retrieve missed messages upon reconnecting to the network.
|
||||
|
||||
### [Transport](/getting-started/concepts/transports)
|
||||
### [Transport](/overview/concepts/transports)
|
||||
|
||||
A transport is a network mechanism that establishes connections between [peers](#peer) and enables efficient transmission, routing, and delivery of data packets.
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ A transport is a network mechanism that establishes connections between [peers](
|
|||
|
||||
Waku is a family of private, secure, decentralized, and peer-to-peer Web3 communication [protocols](#protocol) designed to operate in [resource-limited](#resource-limited) environments and suitable for [node](#node) or desktop application use. Additionally, these protocols collectively form the Waku network.
|
||||
|
||||
### [Waku Message](/getting-started/concepts/protocols#waku-message)
|
||||
### [Waku Message](/overview/concepts/protocols#waku-message)
|
||||
|
||||
Waku Message defines the structure of messages in the [Waku network](#waku), including the [content topic](#content-topic), [payload](#payload), and metadata for application-specific processing.
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ Anonymity means an adversary cannot connect an actor to their actions or data. T
|
|||
|
||||
The spam protection feature in `Relay` ensures that no adversary can flood the system with many messages, intentionally or not, regardless of the content's validity or usefulness. This protection is achieved through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) of `GossipSub v1.1`. Peers assign scores to their connections based on their behavior and remove peers with low scores.
|
||||
|
||||
Ongoing research is being conducted, including developing [Rate Limit Nullifiers (RLN)](/getting-started/concepts/protocols#rln-relay), which can be explored further at: <https://github.com/vacp2p/research/issues/148>.
|
||||
Ongoing research is being conducted, including developing [Rate Limit Nullifiers (RLN)](/overview/concepts/protocols#rln-relay), which can be explored further at: <https://github.com/vacp2p/research/issues/148>.
|
||||
|
||||
## [Data Confidentiality, Integrity, and Authenticity](https://rfc.vac.dev/spec/10/#data-confidentiality-integrity-and-authenticity)
|
||||
|
||||
|
|
@ -12,8 +12,8 @@ Waku intends to incentivize mechanisms to run nodes, but it's not part of libp2p
|
|||
|
||||
Waku includes various protocols covering the following domains: privacy preservation, censorship resistance, and platform agnosticism, allowing it to run on any platform or environment.
|
||||
|
||||
libp2p does not provide out-of-the-box protocols to enable mostly offline/resource-limited devices, [Store](/getting-started/concepts/protocols#store)/[Light Push](/getting-started/concepts/protocols#light-push)/[Filter](/getting-started/concepts/protocols#filter) caters to those use cases.
|
||||
libp2p does not provide out-of-the-box protocols to enable mostly offline/resource-limited devices, [Store](/overview/concepts/protocols#store)/[Light Push](/overview/concepts/protocols#light-push)/[Filter](/overview/concepts/protocols#filter) caters to those use cases.
|
||||
|
||||
## Economic Spam Protection
|
||||
|
||||
libp2p does not have strong spam protection guarantees, [RLN Relay](/getting-started/concepts/protocols#rln-relay) is a protocol being developed by the Waku team towards this goal.
|
||||
libp2p does not have strong spam protection guarantees, [RLN Relay](/overview/concepts/protocols#rln-relay) is a protocol being developed by the Waku team towards this goal.
|
||||
|
|
@ -55,11 +55,11 @@ const config = {
|
|||
type: "docSidebar",
|
||||
position: "right",
|
||||
sidebarId: "main",
|
||||
label: "Getting Started"
|
||||
label: "About Waku"
|
||||
},
|
||||
{
|
||||
type: "dropdown",
|
||||
label: "Guides",
|
||||
label: "Getting Started",
|
||||
position: "right",
|
||||
items: [
|
||||
{
|
||||
|
|
@ -103,7 +103,7 @@ const config = {
|
|||
footer: {
|
||||
links: [
|
||||
{
|
||||
title: "Guides",
|
||||
title: "Getting Started",
|
||||
items: [
|
||||
{
|
||||
to: "/guides/sdks-and-nodes",
|
||||
|
|
|
|||
26
sidebars.js
26
sidebars.js
|
|
@ -3,10 +3,10 @@
|
|||
/** @type {import("@docusaurus/plugin-content-docs").SidebarsConfig} */
|
||||
const sidebars = {
|
||||
main: [
|
||||
"getting-started/index",
|
||||
"getting-started/history",
|
||||
"getting-started/why-waku",
|
||||
"getting-started/use-cases",
|
||||
"overview/index",
|
||||
"overview/history",
|
||||
"overview/why-waku",
|
||||
"overview/use-cases",
|
||||
{
|
||||
type: "html",
|
||||
value: "<a href='/guides/sdks-and-nodes' target='_blank' rel='noopener noreferrer' class='menu__link external-link'>SDKs and Nodes <svg width='13.5' height='13.5' viewBox='0 0 24 24'><path fill='currentColor' d='M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z'></path></svg></a>"
|
||||
|
|
@ -21,11 +21,11 @@ const sidebars = {
|
|||
collapsed: false,
|
||||
collapsible: true,
|
||||
items: [
|
||||
"getting-started/concepts/protocols",
|
||||
"getting-started/concepts/content-topics",
|
||||
"getting-started/concepts/network-domains",
|
||||
"getting-started/concepts/peer-discovery",
|
||||
"getting-started/concepts/transports"
|
||||
"overview/concepts/protocols",
|
||||
"overview/concepts/content-topics",
|
||||
"overview/concepts/network-domains",
|
||||
"overview/concepts/peer-discovery",
|
||||
"overview/concepts/transports"
|
||||
]
|
||||
},
|
||||
{
|
||||
|
|
@ -34,10 +34,10 @@ const sidebars = {
|
|||
collapsed: false,
|
||||
collapsible: true,
|
||||
items: [
|
||||
"getting-started/reference/glossary",
|
||||
"getting-started/reference/security-features",
|
||||
"getting-started/reference/research-in-progress",
|
||||
"getting-started/reference/waku-vs-libp2p"
|
||||
"overview/reference/glossary",
|
||||
"overview/reference/security-features",
|
||||
"overview/reference/research-in-progress",
|
||||
"overview/reference/waku-vs-libp2p"
|
||||
]
|
||||
}
|
||||
],
|
||||
|
|
|
|||
Loading…
Reference in New Issue