mirror of
https://github.com/logos-messaging/docs.waku.org.git
synced 2026-01-03 13:23:06 +00:00
update title capitalisation
This commit is contained in:
LordGhostX
parent
3164349f58
commit
0258ab60db
@ -10,7 +10,7 @@ Waku has risks and limitations as it is still developing and preparing for exten
|
||||
|
||||
Ready to integrate Waku into your application for private, secure, censorship-free communication? Explore the available SDKs and contribute by running a node.
|
||||
|
||||
## Run a Waku Node
|
||||
## Run a Waku node
|
||||
|
||||
The Waku Network is a decentralised, permissionless system where anyone can run nodes, use the network, and contribute to its support.
|
||||
|
||||
@ -19,7 +19,7 @@ The Waku Network is a decentralised, permissionless system where anyone can run
|
||||
| [nwaku](https://github.com/waku-org/nwaku) | Nim-based Waku implementation to run a standalone node and access the network (recommended) | [Run a Nwaku Node](/guides/nwaku/run-node) |
|
||||
| [go-waku](https://github.com/waku-org/go-waku) | Golang-based Waku implementation to run a standalone node and access the network | COMING SOON |
|
||||
|
||||
## Integrate Using SDKs
|
||||
## Integrate using SDKs
|
||||
|
||||
Waku is implemented in multiple SDKs, allowing it to integrate with different languages and address various use cases efficiently.
|
||||
|
||||
@ -30,7 +30,7 @@ Waku is implemented in multiple SDKs, allowing it to integrate with different la
|
||||
| [go-waku](https://github.com/waku-org/go-waku) | Golang SDK designed for integration with Golang applications, includes C bindings for usage in C/C++, C#/Unity, Swift, and Kotlin | COMING SOON |
|
||||
| [waku-rust-bindings](https://github.com/waku-org/waku-rust-bindings) | Rust wrapper using `go-waku` bindings designed for integration in Rust applications | COMING SOON |
|
||||
|
||||
## Run on Mobile Devices
|
||||
## Run on mobile devices
|
||||
|
||||
Waku provides integrations tailored for mobile applications, enabling Waku to run efficiently on mobile devices.
|
||||
|
||||
@ -39,7 +39,7 @@ Waku provides integrations tailored for mobile applications, enabling Waku to ru
|
||||
| Swift (iOS) | `go-waku` bindings for Swift applications to seamlessly integrate Waku | COMING SOON |
|
||||
| Kotlin (Android) | `go-waku` bindings for Kotlin applications to seamlessly integrate Waku | COMING SOON |
|
||||
|
||||
## More Integrations
|
||||
## More integrations
|
||||
|
||||
| | Description | Documentation |
|
||||
| - | - | - |
|
||||
|
||||
@ -9,7 +9,7 @@ This guide provides detailed steps to bootstrap your your node using [Static Pee
|
||||
Until [node incentivisation](/learn/research#prevention-of-denial-of-service-dos-and-node-incentivisation) is in place, you should [operate extra nodes](/#run-a-waku-node) alongside the ones provided by the Waku Network. When running a node, we recommend using the [DNS Discovery and Static Peers](#configure-dns-discovery-and-static-peers) configuration to connect to both the Waku Network and your node.
|
||||
:::
|
||||
|
||||
## Default Bootstrap Method
|
||||
## Default bootstrap method
|
||||
|
||||
The `@waku/sdk` package provides a built-in bootstrapping method that uses [DNS Discovery](/learn/concepts/dns-discovery) to locate peers from the `waku v2.prod` `ENR` tree.
|
||||
|
||||
@ -20,7 +20,7 @@ import { createLightNode } from "@waku/sdk";
|
||||
const node = await createLightNode({ defaultBootstrap: true });
|
||||
```
|
||||
|
||||
## Configure Static Peers
|
||||
## Configure static peers
|
||||
|
||||
To bootstrap a node using [static peers](/learn/concepts/static-peers), first install the `@libp2p/bootstrap` package:
|
||||
|
||||
@ -85,7 +85,7 @@ const node = await createLightNode({
|
||||
For local development using a `nwaku` node, use a `ws` address instead of `wss`. Remember that this setup is functional only when your web server is running locally.
|
||||
:::
|
||||
|
||||
## Configure DNS Discovery
|
||||
## Configure DNS discovery
|
||||
|
||||
To bootstrap a node using [DNS Discovery](/learn/concepts/dns-discovery), first install the `@waku/dns-discovery` package:
|
||||
|
||||
@ -153,7 +153,7 @@ const node = await createLightNode({
|
||||
});
|
||||
```
|
||||
|
||||
## Configure DNS Discovery and Static Peers
|
||||
## Configure DNS discovery and static peers
|
||||
|
||||
You can also bootstrap your node using [DNS Discovery](/learn/concepts/dns-discovery) and [Static Peers](/learn/concepts/static-peers) simultaneously:
|
||||
|
||||
|
||||
@ -5,11 +5,11 @@ hide_table_of_contents: true
|
||||
|
||||
This guide provides detailed steps to enable and use debug logs to troubleshoot your Waku DApp, whether in a NodeJS or browser environment and check your WebSocket connections in [nwaku](/guides/nwaku/run-node).
|
||||
|
||||
## Enabling Debug Logs
|
||||
## Enabling debug logs
|
||||
|
||||
When resolving issues in your Waku DApp, debug logs can be helpful. The `@waku/sdk` and `libp2p` packages use the debug tool to handle and show logs that help you debug effectively.
|
||||
|
||||
### NodeJS Environments
|
||||
### NodeJS environments
|
||||
|
||||
To enable debug logs for `@waku/sdk` on NodeJS, you must set the `DEBUG` environment variable. To only enable debug logs for `@waku/sdk`:
|
||||
|
||||
@ -29,7 +29,7 @@ To enable debug logs for all components:
|
||||
export DEBUG=*
|
||||
```
|
||||
|
||||
### Browser Environments
|
||||
### Browser environments
|
||||
|
||||
To view debug logs in your browser's console, modify the local storage and add the `debug` key. Here are guides for various modern browsers:
|
||||
|
||||
@ -43,7 +43,7 @@ To view debug logs in your browser's console, modify the local storage and add t
|
||||
| `debug` | `waku*,libp2p*` | Enables `@waku/sdk` and `libp2p` debug logs |
|
||||
| `debug` | `*` | Enables all debug logs |
|
||||
|
||||
## Checking WebSocket Setup
|
||||
## Checking WebSocket setup
|
||||
|
||||
[Nwaku](/guides/nwaku/run-node) provides native support for WebSocket (`ws`) and WebSocket Secure (`wss`) protocols. These are the only [transports](/learn/concepts/transports) supported for connecting to the Waku Network via browsers.
|
||||
|
||||
@ -55,7 +55,7 @@ It's important to note that browsers impose certain limitations on WebSocket usa
|
||||
|
||||
If you encounter difficulties when connecting to a remote node using `wss`, follow these steps:
|
||||
|
||||
### Try Websocat for Connection
|
||||
### Try Websocat for connection
|
||||
|
||||
Attempt to connect using [websocat](https://github.com/vi/websocat), a tool for WebSocket interactions. Test the WebSocket port using the command:
|
||||
|
||||
@ -73,7 +73,7 @@ $ websocat -v wss://nwakunode.com:1234
|
||||
|
||||
The connection works if the `[INFO websocat::ws_client_peer] Connected to ws` log entry appears. If not, [check that the certificate is valid](#check-certificate-validity)
|
||||
|
||||
### Check Certificate Validity
|
||||
### Check certificate validity
|
||||
|
||||
Verify the certificate's validity by passing the `-k` or `--insecure` flag to handle invalid certificates in `websocat`:
|
||||
|
||||
@ -83,7 +83,7 @@ websocat -v -k wss://nwakunode.com:1234
|
||||
|
||||
If this works, the certificate's invalidity is the problem, and you should investigate the cause of the error if not, [check if the WebSocket port is accessible](#check-websocket-port-accessibility).
|
||||
|
||||
### Check WebSocket Port Accessibility
|
||||
### Check WebSocket port accessibility
|
||||
|
||||
Use `telnet` or another networking tool to verify if the WebSocket port is open and accessible. For example, if the multiaddr is `/dns4/nwakunode.com/tcp/1234/wss/p2p/16...`, use the command:
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ You can also use the `@waku/sdk` package via a CDN without installing it on your
|
||||
import * as waku from "https://unpkg.com/@waku/sdk@latest/bundle/index.js";
|
||||
```
|
||||
|
||||
## Message Structure
|
||||
## Message structure
|
||||
|
||||
We recommend creating a message structure for your application using [Protocol Buffers](https://protobuf.dev/) for the following reasons:
|
||||
|
||||
@ -77,7 +77,7 @@ import "https://cdn.jsdelivr.net/npm/protobufjs@latest/dist/protobuf.min.js";
|
||||
<script src="https://cdn.jsdelivr.net/npm/protobufjs@latest/dist/protobuf.min.js"></script>
|
||||
```
|
||||
|
||||
## Getting Started
|
||||
## Getting started
|
||||
|
||||
Have a look at the quick start guide and comprehensive tutorials to learn how to build applications using `@waku/sdk`:
|
||||
|
||||
@ -96,7 +96,7 @@ Have a look at the quick start guide and comprehensive tutorials to learn how to
|
||||
Until [node incentivisation](/learn/research#prevention-of-denial-of-service-dos-and-node-incentivisation) is in place, you should [operate extra nodes](/#run-a-waku-node) alongside the ones provided by the Waku Network. When running a node, we recommend using the [DNS Discovery and Static Peers](/guides/js-waku/configure-discovery#configure-dns-discovery-and-static-peers) configuration to connect to both the Waku Network and your node.
|
||||
:::
|
||||
|
||||
## Get Help and Report Issues
|
||||
## Get help and report issues
|
||||
|
||||
To engage in general discussions, seek assistance, or stay updated with the latest news, visit the `#support` and `#js-waku-contribute` channels on the [Waku Discord](https://discord.waku.org).
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ hide_table_of_contents: true
|
||||
|
||||
This guide provides detailed steps to start using the `@waku/sdk` package by setting up a [Light Node](/learn/glossary#light-node) to send messages using the [Light Push protocol](/learn/concepts/protocols#light-push), and receive messages using the [Filter protocol](/learn/concepts/protocols#filter). Have a look at the [installation guide](/guides/js-waku/#installation) for steps on adding `@waku/sdk` to your project.
|
||||
|
||||
## Create a Light Node
|
||||
## Create a light node
|
||||
|
||||
Use the `createLightNode()` function to create a [Light Node](/learn/glossary#light-node) and interact with the Waku Network:
|
||||
|
||||
@ -24,7 +24,7 @@ await node.start();
|
||||
When the `defaultBootstrap` option is set to `true`, your node will be bootstrapped using the [default bootstrap method](/guides/js-waku/configure-discovery#default-bootstrap-method). Have a look at the [Bootstrap Nodes and Discover Peers](/guides/js-waku/configure-discovery) guide to learn more methods to bootstrap nodes.
|
||||
:::
|
||||
|
||||
## Connect to Remote Peers
|
||||
## Connect to remote peers
|
||||
|
||||
Use the `waitForRemotePeer()` function to wait for the node to connect with peers on the Waku Network:
|
||||
|
||||
@ -47,7 +47,7 @@ await waitForRemotePeer(node, [
|
||||
]);
|
||||
```
|
||||
|
||||
## Choose a Content Topic
|
||||
## Choose a content topic
|
||||
|
||||
[Choose a content topic](/learn/concepts/content-topics) for your application and create a message `encoder` and `decoder`:
|
||||
|
||||
@ -75,7 +75,7 @@ const encoder = createEncoder({
|
||||
In this example, users send and receive messages on a shared content topic. However, real applications may have users broadcasting messages while others listen or only have 1:1 exchanges. Waku supports all these use cases.
|
||||
:::
|
||||
|
||||
## Create a Message Structure
|
||||
## Create a message structure
|
||||
|
||||
Create your application's message structure using [Protobuf's valid message](https://github.com/protobufjs/protobuf.js#usage) fields:
|
||||
|
||||
@ -93,7 +93,7 @@ const ChatMessage = new protobuf.Type("ChatMessage")
|
||||
Have a look at the [Protobuf installation](/guides/js-waku/#message-structure) guide for adding the `protobufjs` package to your project.
|
||||
:::
|
||||
|
||||
## Send Messages Using Light Push
|
||||
## Send messages using light push
|
||||
|
||||
To send messages over the Waku Network using the `Light Push` protocol, create a new message object and use the `lightPush.send()` function:
|
||||
|
||||
@ -114,7 +114,7 @@ await node.lightPush.send(encoder, {
|
||||
});
|
||||
```
|
||||
|
||||
## Receive Messages Using Filter
|
||||
## Receive messages using filter
|
||||
|
||||
To receive messages using the `Filter` protocol, create a callback function for message processing, then use the `filter.subscribe()` function to subscribe to a `content topic`:
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ import FilterPingFlow from "@site/diagrams/_filter-ping-flow.md";
|
||||
<FilterPingFlow />
|
||||
```
|
||||
|
||||
## Pinging Filter Subscriptions
|
||||
## Pinging filter subscriptions
|
||||
|
||||
The `@waku/sdk` package provides a `Filter.ping()` function to ping subscriptions and check for an active connection. To begin, create a `Filter` subscription:
|
||||
|
||||
|
||||
@ -7,19 +7,19 @@ While the `@waku/sdk` package is primarily designed for browser environments, yo
|
||||
|
||||
## Limitations
|
||||
|
||||
### API Compatibility
|
||||
### API compatibility
|
||||
|
||||
`@waku/sdk` prioritises browser compatibility, avoiding NodeJS APIs for simpler bundling. This design choice enhances browser API compatibility but sacrifices NodeJS optimisation. While many browser APIs work in NodeJS, they might need better optimisation.
|
||||
|
||||
### Protocol Implementation
|
||||
### Protocol implementation
|
||||
|
||||
`@waku/sdk` focuses on the client side of the [Request/Response protocol](/learn/concepts/network-domains#requestresponse-domain). We'll have to replicate all the functionalities added to [nwaku](/guides/nwaku/run-node) to implement extra features.
|
||||
|
||||
### Codebase Complexity
|
||||
### Codebase complexity
|
||||
|
||||
`@waku/sdk` aims to provide optimal default for the browser, striking a balance between browser and NodeJS compatibility while ensuring simplicity will add complexity.
|
||||
|
||||
### Browser-Specific Protocols
|
||||
### Browser-specific protocols
|
||||
|
||||
Certain features in `@waku/sdk` are tailored for browsers and might not translate seamlessly to NodeJS. For example, only `WebSocket` is supported in the browser, whereas a NodeJS application can benefit from using [transport methods](/learn/concepts/transports) like `TCP`.
|
||||
|
||||
@ -29,6 +29,6 @@ Certain features in `@waku/sdk` are tailored for browsers and might not translat
|
||||
|
||||
Before using `@waku/sdk` in a NodeJS environment, take into account these limitations. For a more optimised solution, we recommend [running nwaku in a Docker container](/guides/nwaku/run-docker) and consuming its [REST API](https://waku-org.github.io/waku-rest-api/).
|
||||
|
||||
## Future Developments
|
||||
## Future developments
|
||||
|
||||
There are plans to release a NodeJS package based on [nwaku](/guides/nwaku/run-node) to streamline the process of using Waku Network features in NodeJS applications. You can track the progress and updates here: <https://github.com/waku-org/nwaku/issues/1332>.
|
||||
@ -5,7 +5,7 @@ hide_table_of_contents: true
|
||||
|
||||
This guide provides detailed steps to create a Light Node for retrieving and filtering historical messages using the [Store protocol](/learn/concepts/protocols#store).
|
||||
|
||||
## Create a Light Node
|
||||
## Create a light node
|
||||
|
||||
Use the `createLightNode()` function to create a Light Node and interact with the Waku Network:
|
||||
|
||||
@ -17,7 +17,7 @@ const node = await createLightNode({ defaultBootstrap: true });
|
||||
await node.start();
|
||||
```
|
||||
|
||||
## Connect to Store Peers
|
||||
## Connect to store peers
|
||||
|
||||
Use the `waitForRemotePeer()` function to wait for the node to connect with Store peers:
|
||||
|
||||
@ -28,7 +28,7 @@ import { waitForRemotePeer, Protocols } from "@waku/sdk";
|
||||
await waitForRemotePeer(node, [Protocols.Store]);
|
||||
```
|
||||
|
||||
## Choose a Content Topic
|
||||
## Choose a content topic
|
||||
|
||||
[Choose a content topic](/learn/concepts/content-topics) for filtering the messages to retrieve and create a message `decoder`:
|
||||
|
||||
@ -42,7 +42,7 @@ const contentTopic = "/store-guide/1/message/proto";
|
||||
const decoder = createDecoder(contentTopic);
|
||||
```
|
||||
|
||||
## Retrieve Messages
|
||||
## Retrieve messages
|
||||
|
||||
`@waku/sdk` provides the `queryWithOrderedCallback()` and `queryGenerator()` functions for querying `Store` nodes and retrieving historical or missed messages. The responses from `Store` nodes are paginated and require you to process each page sequentially.
|
||||
|
||||
@ -100,7 +100,7 @@ for await (const messagesPromises of storeQuery) {
|
||||
The `queryGenerator()` function always returns the oldest messages in a page first.
|
||||
:::
|
||||
|
||||
## Store Query Options
|
||||
## Store query options
|
||||
|
||||
### `pageDirection`
|
||||
|
||||
|
||||
@ -39,7 +39,7 @@ Next, select a template to initialise your app from:
|
||||
If you have previously installed `@waku/create-app` globally, we recommend uninstalling the package to ensure that `npx` always uses the latest version.
|
||||
:::
|
||||
|
||||
## Contributing New Templates
|
||||
## Contributing new templates
|
||||
|
||||
We welcome and appreciate the contributions of templates for the `@waku/create-app` package. To contribute a template, please follow these steps:
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ hide_table_of_contents: true
|
||||
|
||||
The [@waku/react](https://www.npmjs.com/package/@waku/react) package provides components and UI adapters to integrate `@waku/sdk` into React applications effortlessly. This guide provides detailed steps for using `@waku/react` in your project.
|
||||
|
||||
## Install the Dependencies
|
||||
## Install the dependencies
|
||||
|
||||
First, set up a project using any [production-grade React framework](https://react.dev/learn/start-a-new-react-project) or an existing React application. For this guide, we will create a boilerplate using [ViteJS](https://vitejs.dev/guide/):
|
||||
|
||||
@ -50,7 +50,7 @@ yarn add @waku/react @waku/sdk protobufjs
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Initialise the Waku Provider
|
||||
## Initialise the Waku provider
|
||||
|
||||
In the `main.jsx` file, which serves as the entry point for a React app, we will set up the `LightNodeProvider` [context provider](https://react.dev/reference/react/createContext#provider) to wrap the entire application within the Waku provider. Import the following on top of your file:
|
||||
|
||||
@ -85,7 +85,7 @@ function App() {
|
||||
}
|
||||
```
|
||||
|
||||
## Build the Application Interface
|
||||
## Build the application interface
|
||||
|
||||
Let's build a user interface for sending messages and viewing past messages, modify the `App.jsx` file with the following code block:
|
||||
|
||||
@ -202,7 +202,7 @@ Next, modify the `App.css` file with the following code block:
|
||||
}
|
||||
```
|
||||
|
||||
## Send Messages Using Light Push
|
||||
## Send messages using light push
|
||||
|
||||
To send messages in our application, we need to modify the `sendMessage()` function to serialize user input into our Protobuf structure and [push it to the network](/guides/js-waku/light-send-receive#send-messages-using-light-push) using the `useLightPush()` function:
|
||||
|
||||
@ -239,7 +239,7 @@ function App() {
|
||||
}
|
||||
```
|
||||
|
||||
## Receive Messages Using Filter
|
||||
## Receive messages using filter
|
||||
|
||||
To display messages in our application, we need to use the `useFilterMessages()` function to create a [Filter subscription](/guides/js-waku/light-send-receive/#receive-messages-using-filter), receive incoming messages, and render them in our interface:
|
||||
|
||||
@ -260,7 +260,7 @@ function App() {
|
||||
}
|
||||
```
|
||||
|
||||
## Retrieve Messages Using Store
|
||||
## Retrieve messages using store
|
||||
|
||||
To display messages from the past, we need to retrieve them from the [Store protocol](/guides/js-waku/store-retrieve-messages) using the `useStoreMessages()` function when our application initialises and then render them alongside newly received messages:
|
||||
|
||||
|
||||
@ -57,7 +57,7 @@ sudo ln -s /opt/homebrew/opt/postgresql@15/lib/libpq.5.dylib /usr/local/lib/libp
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Clone the Repository
|
||||
## Clone the repository
|
||||
|
||||
Get the source code from the GitHub repository. The default branch is `master`, the release candidate for major updates.
|
||||
|
||||
@ -70,7 +70,7 @@ cd nwaku
|
||||
You can use `git tag -l` to check specific version tags.
|
||||
:::
|
||||
|
||||
## Build the Binary
|
||||
## Build the binary
|
||||
|
||||
Build the `nwaku` binary:
|
||||
|
||||
@ -84,7 +84,7 @@ The first `make` invocation updates to all Git submodules. After each `git pull`
|
||||
make update
|
||||
```
|
||||
|
||||
## Run the Binary
|
||||
## Run the binary
|
||||
|
||||
Nwaku will create the `wakunode2` binary in the `./build/` directory.
|
||||
|
||||
@ -103,7 +103,7 @@ To learn more about running nwaku, have a look at these guides:
|
||||
- [Run Nwaku with Docker Compose](/guides/nwaku/run-docker-compose)
|
||||
- [Node Configuration Methods](/guides/nwaku/config-methods)
|
||||
|
||||
## Run Test Suite
|
||||
## Run test suite
|
||||
|
||||
Run the tests for Waku:
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ Waku nodes can be configured using a combination of the following methods:
|
||||
Take note of the precedence order: Each configuration method overrides the one below it (e.g., command line options override environment variables and configuration files).
|
||||
:::
|
||||
|
||||
## Command Line Options
|
||||
## Command line options
|
||||
|
||||
Node configuration is primarily done using command line options, which override other methods. Specify [configuration options](/guides/nwaku/config-options) by providing them in this format after the binary name:
|
||||
|
||||
@ -28,7 +28,7 @@ When running your node with Docker, provide the command line options after the i
|
||||
docker run statusteam/nim-waku --tcp-port=65000
|
||||
```
|
||||
|
||||
## Environment Variables
|
||||
## Environment variables
|
||||
|
||||
Nodes can be configured using environment variables by prefixing the variable name with `WAKUNODE2_` and using the configuration option in [SCREAMING_SNAKE_CASE](https://en.wiktionary.org/wiki/screaming_snake_case) format.
|
||||
|
||||
@ -48,7 +48,7 @@ docker run -e "WAKUNODE2_TCP_PORT=65000" statusteam/nim-waku
|
||||
This is the second configuration method in order of precedence. [Command Line Options](#command-line-options) override environment variables.
|
||||
:::
|
||||
|
||||
## Configuration Files
|
||||
## Configuration files
|
||||
|
||||
Nodes can be configured using a configuration file following the [TOML](https://toml.io/en/) format:
|
||||
|
||||
@ -79,7 +79,7 @@ docker run -e "WAKUNODE2_CONFIG_FILE=[TOML CONFIGURATION FILE]" statusteam/nim-w
|
||||
This is the third configuration method in order of precedence. [Command Line Options](#command-line-options) and [Environment Variables](#environment-variables) override configuration files.
|
||||
:::
|
||||
|
||||
## Default Configuration Values
|
||||
## Default configuration values
|
||||
|
||||
The default configuration is used when no other options are specified. By default, a `nwaku` node does the following:
|
||||
|
||||
|
||||
@ -5,21 +5,21 @@ hide_table_of_contents: true
|
||||
|
||||
Here are the available node configuration options, along with their default values and descriptions:
|
||||
|
||||
## Application-Level Config
|
||||
## Application-level config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
| `config-file` | | Loads configuration from a TOML file (cmd-line parameters take precedence) |
|
||||
| `protected-topic` | `newSeq[ProtectedTopic](0)` | Topics and its public key to be used for message validation, topic:pubkey. Argument may be repeated |
|
||||
|
||||
## Log Config
|
||||
## Log config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
| `log-level` | `logging.LogLevel.INFO` | Sets the log level for process. Supported levels: TRACE, DEBUG, INFO, NOTICE, WARN, ERROR or FATAL |
|
||||
| `log-format` | `logging.LogFormat.TEXT` | Specifies what kind of logs should be written to stdout. Supported formats: TEXT, JSON |
|
||||
|
||||
## General Node Config
|
||||
## General node config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -37,7 +37,7 @@ Here are the available node configuration options, along with their default valu
|
||||
| `peer-store-capacity` | | Maximum stored peers in the peerstore |
|
||||
| `peer-persistence` | `false` | Enable peer persistence |
|
||||
|
||||
## DNS Addrs Config
|
||||
## DNS addrs config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -45,7 +45,7 @@ Here are the available node configuration options, along with their default valu
|
||||
| `dns-addrs-name-server` | `["1.1.1.1", "1.0.0.1"]` | DNS name server IPs to query for DNS multiaddrs resolution. Argument may be repeated |
|
||||
| `dns4-domain-name` | | The domain name resolving to the node's public IPv4 address |
|
||||
|
||||
## Relay Config
|
||||
## Relay config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -70,7 +70,7 @@ Here are the available node configuration options, along with their default valu
|
||||
| `pubsub-topic` | | Default pubsub topic to subscribe to. Argument may be repeated |
|
||||
| `content-topic` | | Default content topic to subscribe to. Argument may be repeated |
|
||||
|
||||
## Store and Message Store Config
|
||||
## Store and message store config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -81,7 +81,7 @@ Here are the available node configuration options, along with their default valu
|
||||
| `store-message-db-vacuum` | `false` | Enable database vacuuming at start. Only supported by SQLite database engine |
|
||||
| `store-message-db-migration` | `true` | Enable database migration at start |
|
||||
|
||||
## Filter Config
|
||||
## Filter config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -89,14 +89,14 @@ Here are the available node configuration options, along with their default valu
|
||||
| `filternode` | | Peer multiaddr to request content filtering of messages |
|
||||
| `filter-timeout` | `14400 # 4 hours` | Timeout for filter node in seconds |
|
||||
|
||||
## Light Push Config
|
||||
## Light push config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
| `lightpush` | `false` | Enable lightpush protocol: true\|false |
|
||||
| `lightpushnode` | | Peer multiaddr to request lightpush of published messages |
|
||||
|
||||
## JSON-RPC Config
|
||||
## JSON-RPC config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -106,7 +106,7 @@ Here are the available node configuration options, along with their default valu
|
||||
| `rpc-admin` | `false` | Enable access to JSON-RPC Admin API: true\|false |
|
||||
| `rpc-private` | `false` | Enable access to JSON-RPC Private API: true\|false |
|
||||
|
||||
## REST HTTP Config
|
||||
## REST HTTP config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -117,7 +117,7 @@ Here are the available node configuration options, along with their default valu
|
||||
| `rest-admin` | `false` | Enable access to REST HTTP Admin API: true\|false |
|
||||
| `rest-private` | `false` | Enable access to REST HTTP Private API: true\|false |
|
||||
|
||||
## Metrics Config
|
||||
## Metrics config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -126,7 +126,7 @@ Here are the available node configuration options, along with their default valu
|
||||
| `metrics-server-port` | `8008` | Listening HTTP port of the metrics server |
|
||||
| `metrics-logging` | `true` | Enable metrics logging: true\|false |
|
||||
|
||||
## DNS Discovery Config
|
||||
## DNS discovery config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -134,7 +134,7 @@ Here are the available node configuration options, along with their default valu
|
||||
| `dns-discovery-url` | | URL for DNS node list in format 'enrtree://<key\>@<fqdn\>' |
|
||||
| `dns-discovery-name-server` | `["1.1.1.1", "1.0.0.1"]` | DNS name server IPs to query. Argument may be repeated |
|
||||
|
||||
## Discv5 Config
|
||||
## Discv5 config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
@ -146,14 +146,14 @@ Here are the available node configuration options, along with their default valu
|
||||
| `discv5-bucket-ip-limit` | `2` | Maximum amount of nodes with the same IP in discv5 routing table buckets |
|
||||
| `discv5-bits-per-hop` | `1` | Kademlia's b variable, increase for less hops per lookup |
|
||||
|
||||
## Waku Peer Exchange Config
|
||||
## Waku peer exchange config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
| `peer-exchange` | `false` | Enable waku peer exchange protocol (responder side): true\|false |
|
||||
| `peer-exchange-node` | | Peer multiaddr to send peer exchange requests to. (enables peer exchange protocol requester side) |
|
||||
|
||||
## WebSocket Config
|
||||
## WebSocket config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| - | - | - |
|
||||
|
||||
@ -9,7 +9,7 @@ This guide provides detailed steps to configure a `nwaku` node to discover and c
|
||||
You can configure a `nwaku` node to use multiple peer discovery mechanisms simultaneously.
|
||||
:::
|
||||
|
||||
## Configure Static Peers
|
||||
## Configure static peers
|
||||
|
||||
You can provide [static peers](/learn/concepts/static-peers) to a `nwaku` node during startup using the `staticnode` configuration option. To connect to multiple peers on startup, repeat the `staticnode` option:
|
||||
|
||||
@ -27,7 +27,7 @@ For example, consider a `nwaku` node that connects to two static peers on the sa
|
||||
--staticnode=/ip4/0.0.0.0/tcp/60003/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ
|
||||
```
|
||||
|
||||
## Configure DNS Discovery
|
||||
## Configure DNS discovery
|
||||
|
||||
To enable [DNS Discovery](/learn/concepts/dns-discovery) in a `nwaku` node, use the following configuration options:
|
||||
|
||||
@ -82,7 +82,7 @@ For example, consider a `nwaku` node that enables `Discv5` and bootstraps its ro
|
||||
When Discv5 is enabled and used with [DNS Discovery](#configure-dns-discovery), the `nwaku` node will attempt to bootstrap the Discv5 routing table by extracting `ENRs` from peers discovered through DNS.
|
||||
:::
|
||||
|
||||
## Configure Peer Exchange
|
||||
## Configure peer exchange
|
||||
|
||||
To enable [Peer Exchange](/learn/concepts/peer-exchange) in a `nwaku` node, use the following configuration options:
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ hide_table_of_contents: true
|
||||
|
||||
This guide provides detailed steps to configure a `nwaku` node for different use cases.
|
||||
|
||||
## Connect to Other Peers
|
||||
## Connect to other peers
|
||||
|
||||
To join the Waku Network, nodes must [bootstrap](/learn/glossary#bootstrapping) for an entry point before discovering more peers. Nwaku provides multiple [peer discovery](/learn/concepts/peer-discovery) mechanisms:
|
||||
|
||||
@ -14,7 +14,7 @@ To join the Waku Network, nodes must [bootstrap](/learn/glossary#bootstrapping)
|
||||
- [Configure Discv5](/guides/nwaku/configure-discovery#configure-discv5)
|
||||
- [Configure Peer Exchange](/guides/nwaku/configure-discovery#configure-peer-exchange)
|
||||
|
||||
## Configure a Domain Name
|
||||
## Configure a domain name
|
||||
|
||||
You can set up an IPv4 DNS domain name that resolves to the public IPv4 address of a node using the `dns4-domain-name` option. This allows the node's publicly announced multiaddrs to use the `/dns4` scheme.
|
||||
|
||||
@ -34,7 +34,7 @@ Browser nodes can only connect to nodes with a domain name and secure WebSocket
|
||||
This example describes configuring a domain name that resolves to your node's IP address and is unrelated to [DNS Discovery](/learn/concepts/dns-discovery).
|
||||
:::
|
||||
|
||||
## Configure Store Protocol and Message Store
|
||||
## Configure store protocol and message store
|
||||
|
||||
To enable message caching and serve them to network peers, enable the [Store protocol](/learn/concepts/protocols#store) using the following configuration options:
|
||||
|
||||
@ -74,7 +74,7 @@ For example, consider a `nwaku` node that does not persist messages but can quer
|
||||
./build/wakunode2 --storenode=/dns4/node-01.ac-cn-hongkong-c.wakuv2.prod.statusim.net/tcp/30303/p2p/16Uiu2HAm4v86W3bmT1BiH6oSPzcsSr24iDQpSN5Qa992BCjjwgrD
|
||||
```
|
||||
|
||||
## Generate and Configure a Node Key
|
||||
## Generate and configure a node key
|
||||
|
||||
Nodes generate [new random key pairs](/learn/glossary#node-key) at each boot, leading to different `multiaddrs`. To maintain consistency, you can use a pre-generated private key with the `nodekey` option:
|
||||
|
||||
@ -110,7 +110,7 @@ You can use the output `286cae9f2990bfc49dafdd3a9e737f56ddba3656e5e427108cef456f
|
||||
./build/wakunode2 --nodekey=286cae9f2990bfc49dafdd3a9e737f56ddba3656e5e427108cef456fb67680e8
|
||||
```
|
||||
|
||||
## Configure WebSocket Transport
|
||||
## Configure WebSocket transport
|
||||
|
||||
WebSocket is the only [transport method](/learn/concepts/transports) browser nodes support using [@waku/sdk](/guides/js-waku/). To enable WebSocket in `nwaku` to serve browser peers, use the following configuration options:
|
||||
|
||||
@ -155,7 +155,7 @@ sudo letsencrypt -d <your.domain.name>
|
||||
```
|
||||
:::
|
||||
|
||||
## Configure REST API Server
|
||||
## Configure REST API server
|
||||
|
||||
Nwaku provides a REST API to interact with the node and Waku Network. To enable the REST API, use the following configuration options:
|
||||
|
||||
@ -195,7 +195,7 @@ Consider a `nwaku` node that enabled the REST `admin` and `private` API with a m
|
||||
--rest-relay-cache-capacity=100
|
||||
```
|
||||
|
||||
## Configure Filter Protocol
|
||||
## Configure filter protocol
|
||||
|
||||
To enable `nwaku` to serve light clients, enable the [Filter protocol](/learn/concepts/protocols#filter) using `filter` option:
|
||||
|
||||
@ -223,7 +223,7 @@ For example, consider a `nwaku` node that requests content filtering of messages
|
||||
If you omit the `filter-timeout` option, it will default to `14400` seconds (4 hours).
|
||||
:::
|
||||
|
||||
## Configure Light Push Protocol
|
||||
## Configure light push protocol
|
||||
|
||||
To enable `nwaku` to serve light clients, enable the [Light Push protocol](/learn/concepts/protocols#light-push) using the `lightpush` option:
|
||||
|
||||
@ -243,7 +243,7 @@ For example, consider a `nwaku` node that requests lightpush of published messag
|
||||
./build/wakunode2 --lightpushnode=/dns4/node-01.ac-cn-hongkong-c.wakuv2.prod.statusim.net/tcp/30303/p2p/16Uiu2HAm4v86W3bmT1BiH6oSPzcsSr24iDQpSN5Qa992BCjjwgrD
|
||||
```
|
||||
|
||||
## Run Nwaku Behind a Reverse Proxy
|
||||
## Run nwaku behind a reverse proxy
|
||||
|
||||
When using a reverse proxy server for SSL/TLS encryption, you only want to announce the proxy server's IP or domain. Nwaku provides the `ext-multiaddr-only` and `ext-multiaddr` options for specifying published multiaddr:
|
||||
|
||||
|
||||
@ -19,14 +19,14 @@ This guide provides detailed steps to configure, run, monitor, and interact with
|
||||
- [Wallet with Sepolia Ethereum](https://github.com/waku-org/nwaku/blob/master/docs/tutorial/pre-requisites-of-running-on-chain-spam-protected-chat2.md#2-obtain-sepolia-eth-from-faucet) (less than 0.1 Sepolia ETH)
|
||||
- A password to protect your RLN membership
|
||||
|
||||
## Clone the Repository
|
||||
## Clone the repository
|
||||
|
||||
```bash
|
||||
git clone https://github.com/waku-org/nwaku-compose
|
||||
cd nwaku-compose
|
||||
```
|
||||
|
||||
## Configure the Setup
|
||||
## Configure the setup
|
||||
|
||||
Modify the `run_node.sh` file to customise your [node's configuration](/guides/nwaku/config-options) and `docker-compose.yml` to specify particular [Docker image](https://hub.docker.com/r/statusteam/nim-waku/tags) tag. Next, export your Ethereum Sepolia configuration and membership password:
|
||||
|
||||
@ -36,7 +36,7 @@ export ETH_TESTNET_KEY=[INFURA API KEY]
|
||||
export KEYSTORE_PASSWORD=[RLN MEMBERSHIP PASSWORD]
|
||||
```
|
||||
|
||||
## Register RLN Membership
|
||||
## Register RLN membership
|
||||
|
||||
The RLN membership is your access key to The Waku Network. Its registration is done on-chain and allows your `nwaku` node to send messages decentralised and privately, respecting some rate limits. Other peers won't relay messages exceeding the rate limit:
|
||||
|
||||
@ -48,7 +48,7 @@ The RLN membership is your access key to The Waku Network. Its registration is d
|
||||
If you only want to relay traffic without sending messages to the network, you don't need to register for RLN membership.
|
||||
:::
|
||||
|
||||
## Run Docker Compose
|
||||
## Run the node
|
||||
|
||||
Start all processes: `nwaku` node, database and Grafana for metrics. Your RLN membership is loaded into nwaku under the hood:
|
||||
|
||||
@ -56,7 +56,7 @@ Start all processes: `nwaku` node, database and Grafana for metrics. Your RLN me
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
## Interact with the Node
|
||||
## Interact with the node
|
||||
|
||||
Visit <http://localhost:3000/d/yns_4vFVk/nwaku-monitoring> to view your node metrics in real-time.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ This guide provides detailed steps to build and run a `nwaku` node in a Docker c
|
||||
|
||||
Ensure [Docker](https://www.docker.com/) is installed on your system using the appropriate instructions provided in the [Docker documentation](https://docs.docker.com/engine/install/).
|
||||
|
||||
## Get Docker Image
|
||||
## Get Docker image
|
||||
|
||||
The Nwaku Docker images are available on the Docker Hub public registry under the [statusteam/nim-waku](https://hub.docker.com/r/statusteam/nim-waku) repository. Please visit [statusteam/nim-waku/tags](https://hub.docker.com/r/statusteam/nim-waku/tags) for images of specific releases.
|
||||
|
||||
@ -24,7 +24,7 @@ cd nwaku
|
||||
make docker-image
|
||||
```
|
||||
|
||||
## Run Docker Container
|
||||
## Run Docker container
|
||||
|
||||
Run `nwaku` in a new Docker container:
|
||||
|
||||
|
||||
@ -11,22 +11,22 @@ This guide provides detailed steps to download, build, configure, and connect a
|
||||
We recommend running a `nwaku` node with at least 2GB of RAM, especially if you have `WSS` enabled. If running just a `Relay` node, 0.5GB of RAM is sufficient.
|
||||
:::
|
||||
|
||||
## Get the Node Binary
|
||||
## Get the node binary
|
||||
|
||||
To run a node, you must have the `nwaku` binary. Nwaku provides multiple options for acquiring the node binary:
|
||||
|
||||
#### Download the Binary
|
||||
#### Download the binary
|
||||
|
||||
| | Description | Documentation |
|
||||
| - | - | - |
|
||||
| Precompiled Binary | Download a precompiled binary of the `nwaku` node | [Download Nwaku Binary](https://github.com/waku-org/nwaku/tags) |
|
||||
| Nightly Release | Try the latest `nwaku` updates without compiling the binaries | [Download Nightly Release](https://github.com/waku-org/nwaku/releases/tag/nightly) |
|
||||
|
||||
#### Build the Binary
|
||||
#### Build the binary
|
||||
|
||||
You can build the node binary directly from the [nwaku source code](https://github.com/waku-org/nwaku). Have a look at the [Build Nwaku from Source](/guides/nwaku/build-source) guide to learn more.
|
||||
|
||||
#### Run Nwaku in Docker
|
||||
#### Run nwaku in Docker
|
||||
|
||||
| | Description | Documentation |
|
||||
| - | - | - |
|
||||
@ -37,7 +37,7 @@ You can build the node binary directly from the [nwaku source code](https://gith
|
||||
You can run the `nwaku` binaries and Docker images on cloud service providers like [Google Cloud](https://cloud.google.com/), [Microsoft Azure](https://azure.microsoft.com/), [Amazon Web Services](https://aws.amazon.com/), and [DigitalOcean](https://www.digitalocean.com/).
|
||||
:::
|
||||
|
||||
## Run the Node
|
||||
## Run the node
|
||||
|
||||
Once you have gotten the `nwaku` binary, run it using the [default configuration](/guides/nwaku/config-methods#default-configuration-values):
|
||||
|
||||
@ -53,7 +53,7 @@ Once you have gotten the `nwaku` binary, run it using the [default configuration
|
||||
To learn how to customise the configuration of a `nwaku` node, have a look at the [Node Configuration Methods](/guides/nwaku/config-methods) and [Node Configuration Options](/guides/nwaku/config-options) guides.
|
||||
:::
|
||||
|
||||
## Bootstrap the Node
|
||||
## Bootstrap the node
|
||||
|
||||
To join the Waku Network, nodes must [bootstrap](/learn/glossary#bootstrapping) for an entry point before discovering more peers. Nwaku provides multiple [peer discovery](/learn/concepts/peer-discovery) mechanisms:
|
||||
|
||||
@ -68,7 +68,7 @@ To join the Waku Network, nodes must [bootstrap](/learn/glossary#bootstrapping)
|
||||
You can configure a `nwaku` node to use multiple peer discovery mechanisms simultaneously.
|
||||
:::
|
||||
|
||||
## Interact with the Node
|
||||
## Interact with the node
|
||||
|
||||
You can interact with a running `nwaku` node through the [REST API](https://waku-org.github.io/waku-rest-api/), such as querying the node information using the [Get node info](https://waku-org.github.io/waku-rest-api/#get-/debug/v1/info) endpoint:
|
||||
|
||||
@ -104,7 +104,7 @@ curl --location 'http://127.0.0.1:8645/debug/v1/info' \
|
||||
The `listenAddresses` field stores the node's listening addresses, while the `enrUri` field stores the discoverable `ENR` URI for peer discovery.
|
||||
:::
|
||||
|
||||
## Find the Node Addresses
|
||||
## Find the node addresses
|
||||
|
||||
You can find the addresses of a running node through its logs or by calling the [Get node info](https://waku-org.github.io/waku-rest-api/#get-/debug/v1/info) endpoint of the [REST API](https://waku-org.github.io/waku-rest-api/).
|
||||
|
||||
@ -112,7 +112,7 @@ You can find the addresses of a running node through its logs or by calling the
|
||||
When starting the node, `nwaku` will display all the public listening and discovery addresses at the `INFO` log level.
|
||||
:::
|
||||
|
||||
### Listening Addresses
|
||||
### Listening addresses
|
||||
|
||||
Look for the log entry that begins with `Listening on`, for example:
|
||||
|
||||
@ -128,7 +128,7 @@ INF 2023-06-15 16:09:54.448+01:00 Listening on top
|
||||
/ip4/0.0.0.0/tcp/8000/ws/p2p/16Uiu2HAmQCsH9V81xoqTwGuT3qwkZWbwY1TtTQwpr3DjHU2TSwMn
|
||||
```
|
||||
|
||||
### Discoverable ENR Addresses
|
||||
### Discoverable ENR addresses
|
||||
|
||||
A `nwaku` node can encode its addressing information in an [Ethereum Node Record (ENR)](https://eips.ethereum.org/EIPS/eip-778) following the [WAKU2-ENR](https://rfc.vac.dev/spec/31/) specification, primarily for peer discovery.
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ hide_table_of_contents: true
|
||||
|
||||
`Content Topics` are metadata strings set by developers on outgoing messages to facilitate protocol-level features like selectively processing incoming messages ([Relay](/learn/concepts/protocols#relay) or [Filter](/learn/concepts/protocols#filter)) and retrieving historical messages ([Store](/learn/concepts/protocols#store)) that meet specific filtering criteria. Have a look at the [WAKU2-TOPICS](https://rfc.vac.dev/spec/23/#content-topics) specification to learn more.
|
||||
|
||||
## Naming Format
|
||||
## Naming format
|
||||
|
||||
Here is the recommended format for content topics:
|
||||
|
||||
@ -25,7 +25,7 @@ For example, if your DApp is called `SuperCrypto` and it allows users to receive
|
||||
While you can choose any encoding format for your `Content Topic`, we highly recommend using Protocol Buffers (`proto`) because of its efficiency. Choosing a lightweight format ensures optimal performance of your DApp.
|
||||
:::
|
||||
|
||||
## Naming Considerations
|
||||
## Naming considerations
|
||||
|
||||
When choosing a content topic, it is crucial to consider privacy implications. The `Filter`, `Store`, and `Light Push` protocols disclose content topics to peers, enabling said peer to link IP and content topic interests. `Relay` provides recipient anonymity thanks to `GossipSub`, but this may be lost if the content topic reveals information about the user.
|
||||
|
||||
|
||||
@ -5,17 +5,17 @@ hide_table_of_contents: true
|
||||
|
||||
Waku is a unified and cohesive entity that offers a rich ecosystem with three distinct network interaction domains. These domains serve specialised purposes and contribute to the robust functionality of Waku, forming its foundation.
|
||||
|
||||
## Discovery Domain
|
||||
## 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](/learn/concepts/discv5) and [Peer Exchange](/learn/concepts/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
|
||||
## 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](/learn/concepts/protocols#relay) to distribute messages across the network. Additionally, Waku introduces [RLN Relay](/learn/concepts/protocols#rln-relay), an experimental mechanism that combines privacy preservation and economic spam protection.
|
||||
|
||||
## Request/Response Domain
|
||||
## Request/response domain
|
||||
|
||||
Waku provides a set of protocols to optimise its performance in resource-limited environments like low bandwidth or mostly offline scenarios for multiple purposes.
|
||||
|
||||
@ -23,7 +23,7 @@ Waku provides a set of protocols to optimise its performance in resource-limited
|
||||
- [Filter](/learn/concepts/protocols#filter) efficiently retrieves a subset of messages to conserve bandwidth.
|
||||
- [Light Push](/learn/concepts/protocols#light-push) facilitates message publication for nodes with limited bandwidth and short connection windows.
|
||||
|
||||
## Overview of Protocol Interaction
|
||||
## Overview of protocol interaction
|
||||
|
||||
Here is a diagram illustrating the interaction between different protocols within the Waku Network.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ Waku takes a modular approach, providing a range of protocols that enable applic
|
||||
|
||||
`Relay` protocol employs a Pub/Sub architecture to facilitate the sending and receiving of messages among peers. It extends the [libp2p GossipSub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) to create a privacy-focused peer-to-peer messaging protocol that enables secure communication channels, encryption, and protection against censorship. It also scales the Waku Network to accommodate many nodes efficiently.
|
||||
|
||||
## [RLN Relay](https://rfc.vac.dev/spec/17/)
|
||||
## [RLN relay](https://rfc.vac.dev/spec/17/)
|
||||
|
||||
`RLN Relay` protocol extends the `Relay` protocol by using [Rate Limit Nullifiers (RLN)](https://rfc.vac.dev/spec/32/) to provide efficient and economic spam-prevention. It enforces a rate limit on messages over time for all peers in the network, economically preventing spam, and imposes financial penalties and network removal for spammers. You can find more details in the [RLN Relay blog post](https://vac.dev/rln-relay).
|
||||
|
||||
@ -29,7 +29,7 @@ Waku takes a modular approach, providing a range of protocols that enable applic
|
||||
Using `Relay` and `Filter` protocols is recommended when a node is online, as `Store` does not guarantee data availability. The `Store` protocol is suitable for retrieving messages when connecting to the network, like when a DApp starts.
|
||||
:::
|
||||
|
||||
## [Light Push](https://rfc.vac.dev/spec/19/)
|
||||
## [Light push](https://rfc.vac.dev/spec/19/)
|
||||
|
||||
`Light Push` is a [Request/Response](/learn/concepts/network-domains#requestresponse-domain) protocol for nodes with limited bandwidth and short connection windows. It allows a client to receive an acknowledgement when sending messages, indicating that at least one peer has received them. Subsequently, the remote peer forwards these messages to the `Relay` network.
|
||||
|
||||
@ -37,7 +37,7 @@ Using `Relay` and `Filter` protocols is recommended when a node is online, as `S
|
||||
While the `Light Push` protocol acknowledges the receipt by the remote peer, it does not guarantee network-wide propagation.
|
||||
:::
|
||||
|
||||
## [Waku Message](https://rfc.vac.dev/spec/14)
|
||||
## [Waku message](https://rfc.vac.dev/spec/14)
|
||||
|
||||
`Waku Message` specifies the structure and format of messages in the Waku Network. It includes the following attributes:
|
||||
|
||||
|
||||
@ -7,8 +7,8 @@ Transports help move data packets across a network by establishing connections b
|
||||
|
||||
Waku is a transport-agnostic framework that allows developers to choose and support multiple protocols according to their requirements. For Waku nodes, the following transports are recommended:
|
||||
|
||||
- **TCP:** By default, Waku nodes use TCP for communication. Service nodes should employ TCP for listening to and connecting with other nodes.
|
||||
- **Secure WebSocket:** In browser environments, secure WebSocket is used. Service nodes are encouraged to set up SSL certificates to enable incoming connections from browsers and serve them securely.
|
||||
- **TCP**: By default, Waku nodes use TCP for communication. Service nodes should employ TCP for listening to and connecting with other nodes.
|
||||
- **Secure WebSocket**: In browser environments, secure WebSocket is used. Service nodes are encouraged to set up SSL certificates to enable incoming connections from browsers and serve them securely.
|
||||
- Other protocols like [WebRTC](https://github.com/waku-org/js-waku/issues/20), [WebTransport](https://github.com/waku-org/js-waku/issues/697), and QUIC have been researched and studied for potential integration.
|
||||
|
||||
:::info
|
||||
|
||||
@ -11,7 +11,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-network). Once connected, other [peer discovery](#peer-discovery) methods can be employed to locate other [peers](#peer) in the network.
|
||||
|
||||
### [Content Topic](/learn/concepts/content-topics)
|
||||
### [Content topic](/learn/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.
|
||||
|
||||
@ -23,7 +23,7 @@ Dappnode is an open-source platform that simplifies the hosting and management o
|
||||
|
||||
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](/learn/concepts/dns-discovery)
|
||||
### [DNS discovery](/learn/concepts/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 decentralisation.
|
||||
|
||||
@ -43,15 +43,15 @@ GossipSub is a [protocol](#protocol) for efficient and scalable information diss
|
||||
|
||||
Libp2p is a modular network stack and protocol suite that allows developers to build decentralised, peer-to-peer applications across various network protocols.
|
||||
|
||||
### Light Node
|
||||
### Light node
|
||||
|
||||
A light node is a [resource-limited](#resource-limited) device or client that leverages service nodes to access the [Relay](#relay) network.
|
||||
|
||||
### [Light Push](/learn/concepts/protocols#light-push)
|
||||
### [Light push](/learn/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 acknowledgements confirming that a [peer](#peer) has received them.
|
||||
|
||||
### Mostly Offline
|
||||
### Mostly offline
|
||||
|
||||
Mostly offline devices are clients who spend most of their time offline or disconnected from the internet and only occasionally to the internet and [Waku Network](#waku-network). Examples include browsers and mobile phones.
|
||||
|
||||
@ -59,7 +59,7 @@ Mostly offline devices are clients who spend most of their time offline or disco
|
||||
|
||||
A node is a device or client that implements Waku [protocols](#protocol) and leverages the [Waku Network](#waku-network) to enable secure and private peer-to-peer web3 communication.
|
||||
|
||||
### Node Key
|
||||
### Node key
|
||||
|
||||
A node key is a [Secp256k1](https://en.bitcoin.it/wiki/Secp256k1) (64-char hex string) private key for generating the [PeerID](#peer-id), [listening](#transport) addresses, and [discovery](#peer-discovery) addresses of a Waku node.
|
||||
|
||||
@ -71,11 +71,11 @@ 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-network) with whom communication and interaction are possible.
|
||||
|
||||
### [Peer Discovery](/learn/concepts/peer-discovery)
|
||||
### [Peer discovery](/learn/concepts/peer-discovery)
|
||||
|
||||
Peer discovery is when a [node](#node) locates and gets information about other [peers](#peer) in the [Waku Network](#waku-network).
|
||||
|
||||
### [Peer Exchange](/learn/concepts/peer-exchange)
|
||||
### [Peer exchange](/learn/concepts/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).
|
||||
|
||||
@ -91,11 +91,11 @@ A protocol is a set of rules that enables [nodes](#node) within the [Waku Networ
|
||||
|
||||
Publish/Subscribe (Pub/Sub) is an asynchronous messaging pattern where publishers send messages to topics, and subscribers receive messages from topics of interest, allowing efficient one-to-many communication.
|
||||
|
||||
### Pub/Sub Topic
|
||||
### Pub/Sub topic
|
||||
|
||||
A Pub/Sub topic is a string that serves as an identifier for the topic of interest among [GossipSub](#gossipsub) peers. Peers interested in the same topic are likely to maintain a connection and forward messages received on that topic.
|
||||
|
||||
### [Rate Limit Nullifiers](https://rfc.vac.dev/spec/64/#rln-rate-limiting)
|
||||
### [Rate limit nullifiers](https://rfc.vac.dev/spec/64/#rln-rate-limiting)
|
||||
|
||||
Rate Limit Nullifiers (RLN) are a construct based on zero-knowledge proofs that enables rate limiting functionality while preserving the users's anonymity.
|
||||
|
||||
@ -103,11 +103,11 @@ Rate Limit Nullifiers (RLN) are a construct based on zero-knowledge proofs that
|
||||
|
||||
Relay is a [protocol](#protocol) that extends the [GossipSub protocol](#gossipsub) to enable secure and censorship resistant [message](#waku-message) sending and receiving among [peers](#peer) while preserving privacy. It also scales the [Waku Network](#waku-network) to accommodate many nodes efficiently.
|
||||
|
||||
### Resource-Limited
|
||||
### Resource-limited
|
||||
|
||||
Resource-limited refers to environments or devices restricting available resources, including bandwidth, CPU, memory, disk, and battery power.
|
||||
|
||||
### [RLN Relay](/learn/concepts/protocols#rln-relay)
|
||||
### [RLN relay](/learn/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 a rate limit on messages over time, imposing penalties, and facilitating network removal for spammers.
|
||||
|
||||
@ -127,18 +127,18 @@ A transport is a network mechanism that establishes connections between [peers](
|
||||
|
||||
Waku is a family of private, secure, decentralised, 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-network).
|
||||
|
||||
### [Waku Message](/learn/concepts/protocols#waku-message)
|
||||
### [Waku message](/learn/concepts/protocols#waku-message)
|
||||
|
||||
Waku Message defines the structure of messages in the [Waku Network](#waku-network), including the [content topic](#content-topic), [payload](#payload), and metadata for application-specific processing.
|
||||
|
||||
### [Waku Message Payload Encryption](https://rfc.vac.dev/spec/26/)
|
||||
### [Waku message payload encryption](https://rfc.vac.dev/spec/26/)
|
||||
|
||||
Waku Message Payload Encryption provides guidelines for implementing secure and private communication in the [Waku Network](#waku-network). It covers encryption, decryption, and signing methods for message [payloads](#payload), focusing on confidentiality, authenticity, integrity, and unlinkability.
|
||||
|
||||
### [Waku Network](/learn/waku-network)
|
||||
### [Waku network](/learn/waku-network)
|
||||
|
||||
The Waku Network is an open-access, scalable peer-to-peer messaging network emphasizing privacy protection and accessibility to [resource limited](#resource-limited) devices.
|
||||
|
||||
### [Waku Noise](https://rfc.vac.dev/spec/35/)
|
||||
### [Waku noise](https://rfc.vac.dev/spec/35/)
|
||||
|
||||
Waku Noise is a specified way to use the [Noise Protocol Framework](http://noiseprotocol.org/) to build protocols that enable secure key-exchange mechanisms for encrypted communication with confidentiality, authenticity, integrity, strong forward secrecy, and identity-hiding properties.
|
||||
@ -5,13 +5,13 @@ hide_table_of_contents: true
|
||||
|
||||
The following features are currently experimental and under research and initial implementation:
|
||||
|
||||
## Economic Spam Resistance
|
||||
## Economic spam resistance
|
||||
|
||||
We aim to enable an incentivised spam protection technique to enhance `Relay` by using [Rate Limit Nullifiers (RLN)](https://rfc.vac.dev/spec/32/). In this advanced method, peers are limited to a certain messaging rate per epoch, and an immediate financial penalty is enforced for spammers who break this rate. You can find more details in the [RLN Relay blog post](https://vac.dev/rln-relay).
|
||||
|
||||
We have prepared a PoC implementation of this method in JS: <https://examples.waku.org/rln-js/>
|
||||
|
||||
## Prevention of Denial of Service (DoS) and Node Incentivisation
|
||||
## Prevention of denial of service (DoS) and node incentivisation
|
||||
|
||||
Denial of service signifies the case where an adversarial peer exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system. RnD on DoS attack mitigation can tracked from here: <https://github.com/vacp2p/research/issues/148>.
|
||||
|
||||
|
||||
@ -11,23 +11,23 @@ Some of the Waku's security features include the following:
|
||||
|
||||
Waku ensures pseudonymity across its protocol layers, using libp2p `PeerID` as identifiers instead of disclosing true identities. However, it is important to note that pseudonymity does not provide complete anonymity. Actions performed under the same pseudonym (`PeerID`) can be linked, leading to the potential re-identification of the actual actor.
|
||||
|
||||
## [Anonymity/Unlinkability](https://rfc.vac.dev/spec/10/#anonymity--unlinkability)
|
||||
## [Anonymity/unlinkability](https://rfc.vac.dev/spec/10/#anonymity--unlinkability)
|
||||
|
||||
Anonymity means an adversary cannot connect an actor to their actions or data. To achieve anonymity, avoiding linking activities with actors or their Personally Identifiable Information (PII) is crucial. In Waku, the following anonymity features are provided:
|
||||
|
||||
- [Publisher-Message Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the publisher of messages in the `Relay` protocol cannot be linked to their published messages.
|
||||
- [Subscriber-Topic Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the subscriber of topics in the `Relay` protocol cannot be linked to the topics they have subscribed to.
|
||||
- [Publisher-message unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the publisher of messages in the `Relay` protocol cannot be linked to their published messages.
|
||||
- [Subscriber-topic unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the subscriber of topics in the `Relay` protocol cannot be linked to the topics they have subscribed to.
|
||||
|
||||
## [Spam Protection](https://rfc.vac.dev/spec/10/#spam-protection)
|
||||
## [Spam protection](https://rfc.vac.dev/spec/10/#spam-protection)
|
||||
|
||||
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 behaviour and remove peers with low scores.
|
||||
|
||||
Ongoing research is being conducted, including developing [Rate Limit Nullifiers (RLN)](/learn/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)
|
||||
## [Data confidentiality, integrity, and authenticity](https://rfc.vac.dev/spec/10/#data-confidentiality-integrity-and-authenticity)
|
||||
|
||||
Confidentiality in Waku is ensured through data encryption, while integrity and authenticity are achieved through digital signatures. These security measures are available in [Waku Message (version 1)](https://rfc.vac.dev/spec/14#version-1) and [Noise](https://rfc.vac.dev/spec/35/) protocols, which offer payload encryption and encrypted signatures. [Noise](https://rfc.vac.dev/spec/35/) protocols also facilitate secure channel negotiation within the Waku Network.
|
||||
|
||||
## [Security Considerations](https://rfc.vac.dev/spec/10/#security-considerations)
|
||||
## [Security considerations](https://rfc.vac.dev/spec/10/#security-considerations)
|
||||
|
||||
In protocols like `Store` and `Filter`, where direct connections are required for the designated service, anonymity or unlinkability is not guaranteed. This is because nodes use their `PeerID` to identify each other during direct connections, making the service obtained in these protocols linkable to the beneficiary's `PeerID`, considered Personally Identifiable Information (PII). In `Store`, the queried node can link the querying node's `PeerID` to the topics being queried. Similarly, in `Filter`, a node can link the `PeerID` of a light node to its content filter.
|
||||
@ -16,7 +16,7 @@ The Waku Network is a shared p2p messaging network that is open-access, useful f
|
||||
|
||||
If you want to learn more about the Waku Network, the [WAKU2-NETWORK RFC](https://rfc.vac.dev/spec/64/) provides an in-depth look under the hood.
|
||||
|
||||
## Why Join the Waku Network?
|
||||
## Why join the Waku network?
|
||||
|
||||
1. Applications or projects can build decentralized communication components on this network, gaining from the fault-tolerance of shared infrastructure, the out-of-the-box censorship resistance of a p2p network and the privacy-preservation of Waku protocols.
|
||||
2. Supporters of public goods and decentralized infrastructure can run their nodes to support the network.
|
||||
@ -24,9 +24,9 @@ If you want to learn more about the Waku Network, the [WAKU2-NETWORK RFC](https:
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. **Ethereum Sepolia WebSocket Endpoint**, which can be yours or from a third party. Have a look at the [Access a Sepolia Node Using Infura](https://github.com/waku-org/nwaku/blob/master/docs/tutorial/pre-requisites-of-running-on-chain-spam-protected-chat2.md#3-access-a-node-on-the-sepolia-testnet-using-infura) guide for a free Infura option. This node is used to interact with the [on-chain RLN membership contract](https://rfc.vac.dev/spec/17/).
|
||||
1. **Ethereum Sepolia WebSocket endpoint**, which can be yours or from a third party. Have a look at the [Access a Sepolia Node Using Infura](https://github.com/waku-org/nwaku/blob/master/docs/tutorial/pre-requisites-of-running-on-chain-spam-protected-chat2.md#3-access-a-node-on-the-sepolia-testnet-using-infura) guide for a free Infura option. This node is used to interact with the [on-chain RLN membership contract](https://rfc.vac.dev/spec/17/).
|
||||
2. **Wallet with Sepolia Ethereum** (less than 0.1 Sepolia ETH). Have a look at the [Create a Sepolia Ethereum Wallet](https://github.com/waku-org/nwaku/blob/master/docs/tutorial/pre-requisites-of-running-on-chain-spam-protected-chat2.md#1-create-a-sepolia-ethereum-account-and-obtain-its-private-key) and [Obtain Sepolia Ethereum from Faucet](https://github.com/waku-org/nwaku/blob/master/docs/tutorial/pre-requisites-of-running-on-chain-spam-protected-chat2.md#2-obtain-sepolia-eth-from-faucet) guides to get a Sepolia wallet and fund it with some Sepolia Ethereum. This wallet is required to register [RLN membership](https://rfc.vac.dev/spec/17/#setup-and-registration), which is essential for publishing on the network.
|
||||
|
||||
## Running a Waku Network Node
|
||||
## Running a Waku network node
|
||||
|
||||
Have a look at the [Run Nwaku with Docker Compose](/guides/nwaku/run-docker-compose) guide for instructions on running a [nwaku](https://github.com/waku-org/nwaku) node in the Waku Network. Use the Sepolia node and wallet you obtained above.
|
||||
@ -5,16 +5,16 @@ hide_table_of_contents: true
|
||||
|
||||
Since Waku is built on top of libp2p, they share a lot of concepts and terminologies between them. However, there are key differences between them that are worth noting.
|
||||
|
||||
## Waku as a Service Network
|
||||
## Waku as a service network
|
||||
|
||||
Waku intends to incentivise mechanisms to run nodes, but it is not part of libp2p's scope. Additionally, users or developers do not have to deploy their infrastructure as a prerequisite to use Waku. It is a service network. However, you are encouraged to [run a node](/#run-a-waku-node) to support and decentralise the network.
|
||||
|
||||
## Waku as a Turnkey Solution
|
||||
## Waku as a turnkey solution
|
||||
|
||||
Waku includes various protocols covering the following domains: privacy preservation, censorship resistance, and platform agnosticism, allowing it to run on any platform or environment.
|
||||
|
||||
Waku provides out-of-the-box protocols to enable mostly offline/resource-limited devices, [Store](/learn/concepts/protocols#store)/[Light Push](/learn/concepts/protocols#light-push)/[Filter](/learn/concepts/protocols#filter) caters to those use cases.
|
||||
|
||||
## Economic Spam Protection
|
||||
## Economic spam protection
|
||||
|
||||
libp2p does not have strong spam protection guarantees, [RLN Relay](/learn/concepts/protocols#rln-relay) is a protocol being developed by the Waku team towards this goal.
|
||||
|
||||
@ -79,5 +79,4 @@ These Website Terms of Use cover the entire agreement between you and us regardi
|
||||
|
||||
The captions and headings identifying sections and subsections of these Website Terms of Use are for reference only and do not define, modify, expand, limit, or affect the interpretation of any provisions of these Website Terms of Use.
|
||||
|
||||
If any part of these Website Terms of Use is held invalid or unenforceable, that part will be severable from these Website Terms of Use, and the remaining portions will remain in full force and effect. If we fail to enforce any of these Website Terms of Use, that does not mean that we have waived our right to enforce them.
|
||||
|
||||
If any part of these Website Terms of Use is held invalid or unenforceable, that part will be severable from these Website Terms of Use, and the remaining portions will remain in full force and effect. If we fail to enforce any of these Website Terms of Use, that does not mean that we have waived our right to enforce them.
|
||||
@ -153,7 +153,7 @@ const config = {
|
||||
items: [
|
||||
{
|
||||
href: "/terms",
|
||||
label: "Terms & Conditions",
|
||||
label: "Terms of Use",
|
||||
},
|
||||
],
|
||||
},
|
||||
|
||||
@ -20,7 +20,7 @@ def parse_table_heading(line: str) -> Tuple[str, bool]:
|
||||
r'(Discovery V5)', r'(Websocket)'
|
||||
]))
|
||||
word_replace_dict = {
|
||||
'Configuration': 'Config', 'And': 'and', 'Lightpush': 'Light Push',
|
||||
'Configuration': 'config', 'And': 'and', 'Lightpush': 'Light push',
|
||||
'Json-Rpc': 'JSON-RPC', 'Rest Http': 'REST HTTP', 'Dns': 'DNS',
|
||||
'Discovery V5': 'Discv5', 'Websocket': 'WebSocket'
|
||||
}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user