overhaul concept protocols
This commit is contained in:
LordGhostX
parent
feff9de376
commit
4ce0a6549c
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
title: Different Types of Protocols in Waku
|
||||
---
|
||||
|
||||
Waku is modular: several protocols are available and applications can decide on how they want to turn the dials on the [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html). Here are the different types of protocols Waku offers:
|
||||
|
||||
## 1. Discovery Domain
|
||||
|
||||
Node discovery is the mechanism that enables a Waku node to find other nodes. Waku is a modular protocol, several discovery mechanisms are and will be included in Waku (eg: [`Discv5`](https://rfc.vac.dev/spec/33/) and [`Peer Exchange`](https://rfc.vac.dev/spec/34/) ) so that developers can select the best mechanism(s) based for their use case and the user’s environment (e.g. mobile phone, desktop browser, server, etc).
|
||||
|
||||
## 2. Gossip Domain
|
||||
|
||||
Gossipsub is named after the fact that in a pub-sub network, the peers gossip to each other about which messages they have seen and use this information to maintain a message delivery network.
|
||||
|
||||
Waku is using gossiping to disseminate messages throughout the network using [`WAKU-RELAY`](https://rfc.vac.dev/spec/11/).
|
||||
An extension of this is [`WAKU-RLN-RELAY`](https://rfc.vac.dev/spec/17/): an experimental privacy-preserving economic spam protection mechanism.
|
||||
|
||||
## 3. Request/Response Domain
|
||||
|
||||
In addition to the Gossip domain, Waku provides a set of Request/Reply protocols. They are primarily used in order to get Waku to run in resource restricted environments, such as low bandwidth or being mostly offline.
|
||||
|
||||
- [`WAKU-STORE`](https://rfc.vac.dev/spec/13/) is used to fetch historical messages for mostly offline devices.
|
||||
|
||||
:::info There is also an experimental fault-tolerant addition to the store protocol (WAKU-FT-STORE) that relaxes the high availability requirement.
|
||||
|
||||
- [`WAKU-FILTER`](https://rfc.vac.dev/spec/12/) is used to make fetching of a subset of messages more bandwidth preserving.
|
||||
- [`WAKU-LIGHTPUSH`](https://rfc.vac.dev/spec/19/) is used for nodes with short connection windows and limited bandwidth to publish messages into the Waku network.
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
---
|
||||
title: Network Interaction Domains
|
||||
---
|
||||
|
||||
Waku is a unified and cohesive entity that offers a rich ecosystem with three distinct network interaction domains. These domains serve specialized purposes and contribute to the robust functionality of Waku, forming its foundation.
|
||||
|
||||
## Discovery Domain
|
||||
|
||||
Node discovery in Waku facilitates locating other nodes within the network. As a modular protocol, Waku incorporates various discovery mechanisms, such as [`Discv5`](https://rfc.vac.dev/spec/33/) and [`Peer Exchange`](https://rfc.vac.dev/spec/34/). 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 [`WAKU-RELAY`](https://rfc.vac.dev/spec/11/) to distribute messages across the network. Additionally, Waku introduces [`WAKU-RLN-RELAY`](https://rfc.vac.dev/spec/17/), an experimental mechanism that combines privacy preservation and economic spam protection.
|
||||
|
||||
## Request/Reply Domain
|
||||
|
||||
Waku provides a set of Request/Reply protocols to optimize its performance in resource-restricted environments like low bandwidth or offline scenarios.
|
||||
|
||||
These protocols serve multiple purposes. [`WAKU-STORE`](https://rfc.vac.dev/spec/13/) enables the retrieval of historical messages, [`WAKU-FILTER`](https://rfc.vac.dev/spec/12/) efficiently retrieves a subset of messages to conserve bandwidth, and [`WAKU-LIGHTPUSH`](https://rfc.vac.dev/spec/19/) facilitates message publication for nodes with limited bandwidth and short connection windows.
|
||||
|
||||
## Overview of Protocol Interaction
|
||||
|
||||
Here's a diagram illustrating the interaction between different protocols within the Waku network.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant A as A relay
|
||||
participant B as B relay(pubtopic1)
|
||||
participant C as C relay(pubtopic1)
|
||||
participant D as D relay(pubtopic1), store(pubtopic1), filter
|
||||
participant E as E relay, store
|
||||
participant F as F relay, filter
|
||||
|
||||
A ->> A: msg1=WakuMessage(contentTopic1, data) (1)
|
||||
F ->> D: FilterRequest(pubtopic1, contentTopic1) (2)
|
||||
D ->> D: Subscribe F to filter (2)
|
||||
A ->> B: Publish msg1 on pubtopic1 (3)
|
||||
B ->> D: relay msg1 on pubtopic1 (3)
|
||||
D ->> D: store: saves msg1 (4)
|
||||
D ->> F: MessagePush(msg1) (5)
|
||||
E ->> E: E comes online (6)
|
||||
E ->> D: HistoryQuery(pubtopic1, contentTopic1) (6)
|
||||
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. In the context of Waku Store, Node D is responsible for persisting these messages.
|
||||
|
||||
1. Node A creates a WakuMessage `msg1` with a ContentTopic `contentTopic1`.
|
||||
2. Node F requests to get messages filtered by Pub/Sub topic `pubtopic1` and ContentTopic `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`, stores the message in its store for possible later retrieval by other nodes.
|
||||
5. Node D also pushes `msg1` to Node F, informing it about the arrival of a new message.
|
||||
6. At a later time, Node E comes online and requests messages matching `pubtopic1` and `contentTopic1` from Node D. Node D responds with `msg1` and potentially other messages that match the query.
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
---
|
||||
title: Protocols Overview by Example
|
||||
---
|
||||
|
||||
We have six nodes, A-F.
|
||||
|
||||
The protocols initially mounted are indicated as such.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant A as A relay(0)
|
||||
participant B as B relay(pubtopic1)(0)
|
||||
participant C as C relay(pubtopic1)(0)
|
||||
participant D as D relay(pubtopic1), store(pubtopic1), filter(0)
|
||||
participant E as E relay, store(0)
|
||||
participant F as F relay, filter(0)
|
||||
|
||||
A ->> A: msg1=WakuMessage(contentTopic1, data) [14/WAKU2-MESSAGE] (1)
|
||||
Note right of A: If version=1, encrypt data per [7/WAKU-DATA] (1)
|
||||
|
||||
F ->> D: FilterRequest(pubtopic1, contentTopic1) [12/WAKU2-FILTER] (2)
|
||||
D ->> D: Subscribe F to filter [12/WAKU2-FILTER] (2)
|
||||
|
||||
A ->> B: Publish msg1 on pubtopic1 [11/WAKU2-RELAY] (3)
|
||||
B ->> D: relay msg1 on pubtopic1 [11/WAKU2-RELAY] (3)
|
||||
|
||||
D ->> D: store: saves msg1 [13/WAKU2-STORE] (4)
|
||||
|
||||
D ->> F: MessagePush(msg1)[12/WAKU2-FILTER] (5)
|
||||
|
||||
E ->> E: E comes online (6)
|
||||
E ->> D: HistoryQuery(pubtopic1, contentTopic1) [13/WAKU2-STORE] (6)
|
||||
D ->> E: HistoryResponse(msg1, ...) [13/WAKU2-STORE] (6)
|
||||
|
||||
```
|
||||
|
||||
The PubSub topic `pubtopic1` is used for routing (the network uses a default pubsub topic) and indicates that it is subscribed to messages on that topic for relay.Ditto for Waku Store where it indicates that these messages are persisted on that node.
|
||||
|
||||
1. Node A creates a WakuMessage `msg1` with a ContentTopic `/my-dapp/0/notifications/proto`.
|
||||
|
||||
2. Node F requests to get messages filtered by PubSub topic `pubtopic1` and ContentTopic `contentTopic1`. Node D subscribes F to this filter and will in the future forward messages that match that filter.
|
||||
|
||||
3. Node A publishes `msg1` on `pubtopic1` and subscribes to that relay topic pick it up. It then gets relayed further from B to D, but not C since it doesn't subscribe to that topic.
|
||||
|
||||
4. Node D saves `msg1` for possible later retrieval by other nodes.
|
||||
|
||||
5. Node D also pushes `msg1` to F, as it has previously subscribed F to this filter.
|
||||
|
||||
6. At a later time, Node E comes online. It then requests messages matching `pubtopic1` and `contentTopic1` from Node D. Node D responds with messages meeting this (and possibly other) criteria.
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: Protocols Explained
|
||||
title: Waku Protocols
|
||||
---
|
||||
|
||||
Waku is modular: several protocols are available and applications can decide on how they want to turn the dials on the [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html). Here are the different types of protocols Waku offers:
|
||||
|
||||
Currently, the main Waku protocols are:
|
||||
|
||||
### [Waku Relay](https://rfc.vac.dev/spec/11/)
|
||||
|
|
@ -2,9 +2,7 @@
|
|||
title: Waku Use Cases
|
||||
---
|
||||
|
||||
Waku is a decentralized communication network that supports person-to-person and machine-to-machine communication, enabling secure and private operation without a central authority.
|
||||
|
||||
The following is a list of some of the use cases that have been considered and their current status.
|
||||
Waku is a decentralized communication network, facilitating secure and private person-to-person and machine-to-machine communication without a central authority. It supports various use cases, including but not limited to:
|
||||
|
||||
### Chat Messenger
|
||||
|
||||
|
|
@ -16,7 +14,7 @@ Waku can be used as the communication layer when building a private, decentraliz
|
|||
|
||||
### Polls
|
||||
|
||||
With Waku, you can create, answer, and view censorship-resistant polls.
|
||||
With Waku, you can create, answer, and view censorship-resistant polls, fostering a democratic and transparent voting environment immune to manipulation and censorship.
|
||||
|
||||
#### Demos
|
||||
|
||||
|
|
@ -32,7 +30,7 @@ Waku can be used to take NFT bids and offers off-chain, enabling gas savings. Ad
|
|||
|
||||
### State Channels
|
||||
|
||||
Waku can enable two parties to set up and maintain a state channel.
|
||||
Waku can enable two parties to establish and sustain a state channel effortlessly, facilitating message exchange and seamless updates to their shared agreement without direct blockchain involvement.
|
||||
|
||||
### Voting and Proposals
|
||||
|
||||
|
|
@ -65,7 +63,7 @@ dApp operators can use communication between a user's wallet and their dApp to n
|
|||
|
||||
### Layer 2 Coordination (Open Market, Spam Protected Mempool)
|
||||
|
||||
Waku can broadcast and aggregate layer 2 transactions, potentially enhancing privacy, anonymity, and resilience.
|
||||
Waku can broadcast and aggregate Layer 2 transactions to enhance privacy, anonymity, and resilience. Aggregating transactions reduces network load and improves scalability, ensuring a more robust Layer 2 ecosystem.
|
||||
|
||||
### Generalized Marketplace
|
||||
|
||||
|
|
|
|||
|
|
@ -17,11 +17,11 @@ Waku aims to solve the problem of ephemeral messaging between subsystems and nod
|
|||
|
||||
### Peer-to-Peer
|
||||
|
||||
Waku is suitable for applications that require a peer-to-peer approach, as it offers the following advantages:
|
||||
Waku is suitable for applications that require a peer-to-peer approach, offering the following advantages:
|
||||
|
||||
- Censorship resistance with no single point of failure.
|
||||
- Adaptive and scalable network.
|
||||
- Shared infrastructure/service network.
|
||||
- Shared infrastructure, leveraging the capabilities of Waku as a service network.
|
||||
|
||||
### Platform Agnostic
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ const config = {
|
|||
},
|
||||
announcementBar: {
|
||||
content:
|
||||
"While Waku still has progress to make, apps like <a href='/overview/who-is-using-waku'>XMTP and Railgun</a> have already implemented it in production. Join our <a href='https://discord.gg/Nrac59MfSX'>Discord Community</a> to stay updated on our progress.",
|
||||
"While Waku is still in development and needs to prepare for extensive adoption, it is already being used by <a href='/overview/who-is-using-waku'>XMTP and Railgun</a>. Join our <a href='https://discord.gg/Nrac59MfSX'>Discord Community</a> to stay updated on our progress.",
|
||||
backgroundColor: "#EBEDF0",
|
||||
textColor: "#1B1B1D",
|
||||
isCloseable: true,
|
||||
|
|
|
|||
|
|
@ -12,13 +12,12 @@ const sidebars = {
|
|||
"overview/implementations",
|
||||
{
|
||||
type: "category",
|
||||
label: "Concepts",
|
||||
label: "Waku Concepts",
|
||||
collapsed: false,
|
||||
collapsible: true,
|
||||
items: [
|
||||
"overview/concepts/different-protocols",
|
||||
"overview/concepts/protocols-explained",
|
||||
"overview/concepts/protocols-overview-by-example",
|
||||
"overview/concepts/network-interaction-domains",
|
||||
"overview/concepts/protocols",
|
||||
"overview/concepts/discovery-and-bootstrap",
|
||||
"overview/concepts/transports-in-waku",
|
||||
"overview/concepts/content-topics",
|
||||
|
|
|
|||
Loading…
Reference in New Issue