logos-messaging/docs.waku.org
1
0
Fork 0
mirror of https://github.com/logos-messaging/docs.waku.org.git synced 2026-01-02 12:53:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Upgrade docusaurus and preset version (#244)

Browse Source 
* feat: upgrade docusaurus and preset version

* feat: add node fetch-content.js to build script
This commit is contained in:
Jinho Jang 2025-08-13 12:22:04 +09:00 committed by GitHub
parent 1bebfcb396
commit 1572d6cb30
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
17 changed files with 7145 additions and 5499 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.cspell.json
View File

@ -83,7 +83,7 @@
"IPFS", "IPFS",
"cheatsheet", "cheatsheet",
"hacken", "hacken",
"statusteam", "statusteam"
], ],
"flagWords": [], "flagWords": [],
"ignorePaths": [ "ignorePaths": [

7
README.md
View File

@ -2,7 +2,7 @@
[![Waku Documentation Portal](https://img.shields.io/badge/docs.waku.org-black)](https://docs.waku.org/) [![Waku Documentation Portal](https://img.shields.io/badge/docs.waku.org-black)](https://docs.waku.org/)
The Waku Documentation Portal can be accessed at <https://docs.waku.org/> and was built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator. The Waku Documentation Portal can be accessed at [https://docs.waku.org/](https://docs.waku.org/) and was built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
## Prerequisites ## Prerequisites
@ -88,8 +88,8 @@ yarn clear
## CI/CD ## CI/CD
- [CI builds](https://ci.infra.status.im/job/website/job/docs.waku.org/) `master` and pushes to `deploy-master` branch, which is hosted at <https://docs.waku.org/>. - [CI builds](https://ci.infra.status.im/job/website/job/docs.waku.org/) `master` and pushes to `deploy-master` branch, which is hosted at [https://docs.waku.org/](https://docs.waku.org/).
- [CI builds](https://ci.infra.status.im/job/website/job/dev-docs.waku.org/) `develop` and pushes to `deploy-develop` branch, which is hosted at <https://dev-docs.waku.org/>. - [CI builds](https://ci.infra.status.im/job/website/job/dev-docs.waku.org/) `develop` and pushes to `deploy-develop` branch, which is hosted at [https://dev-docs.waku.org/](https://dev-docs.waku.org/).
The hosting is done using [Caddy server with Git plugin for handling GitHub webhooks](https://github.com/status-im/infra-misc/blob/master/ansible/roles/caddy-git). The hosting is done using [Caddy server with Git plugin for handling GitHub webhooks](https://github.com/status-im/infra-misc/blob/master/ansible/roles/caddy-git).
@ -101,4 +101,3 @@ Information about deployed build can be also found in `/build.json` available on
2. Make your changes, push them to the origin, and open a Pull Request against the develop branch. 2. Make your changes, push them to the origin, and open a Pull Request against the develop branch.
3. After approval, merge the pull request, and verify the changes on the staging server (e.g., https://dev.vac.dev). 3. After approval, merge the pull request, and verify the changes on the staging server (e.g., https://dev.vac.dev).
4. When ready to promote changes to the live website, rebase the master branch on the staging changes: git checkout master; git pull origin master; git rebase origin/develop; git push. 4. When ready to promote changes to the live website, rebase the master branch on the staging changes: git checkout master; git pull origin master; git rebase origin/develop; git push.

4
docs/guides/getting-started.md
View File

@ -42,7 +42,7 @@ Check out our [Learn section](/learn/waku-network), [YouTube channel](https://ww
8. **Social Media Platforms**: Beyond chat messengers, use Waku for decentralised, censorship-resistant social media platforms like news feeds and multimedia sharing. 8. **Social Media Platforms**: Beyond chat messengers, use Waku for decentralised, censorship-resistant social media platforms like news feeds and multimedia sharing.
:::tip :::tip
Looking for what to build with Waku? Discover a collection of sample ideas and use cases for inspiration, curated by our community at: https://ideas.waku.org/ and [Awesome Waku](https://github.com/waku-org/awesome-waku/). Looking for what to build with Waku? Discover a collection of sample ideas and use cases for inspiration, curated by our community at: [https://ideas.waku.org/](https://ideas.waku.org/) and [Awesome Waku](https://github.com/waku-org/awesome-waku/).
::: :::
## Case studies ## Case studies
@ -89,5 +89,5 @@ Waku is implemented in multiple SDKs, allowing it to integrate with different la
| [@waku/create-app](https://www.npmjs.com/package/@waku/create-app) | Starter kit to bootstrap your next `@waku/sdk` project from various example templates | [Scaffold DApps Using @waku/create-app](/guides/js-waku/use-waku-create-app) | | [@waku/create-app](https://www.npmjs.com/package/@waku/create-app) | Starter kit to bootstrap your next `@waku/sdk` project from various example templates | [Scaffold DApps Using @waku/create-app](/guides/js-waku/use-waku-create-app) |
:::tip :::tip
Explore some example apps built using Waku at https://examples.waku.org/ and view a list of projects and workshops from previous hackathons at [Awesome Waku](https://github.com/waku-org/awesome-waku/). Explore some example apps built using Waku at [https://examples.waku.org/](https://examples.waku.org/) and view a list of projects and workshops from previous hackathons at [Awesome Waku](https://github.com/waku-org/awesome-waku/).
::: :::

75
docs/guides/js-waku/configure-discovery.md → docs/guides/js-waku/configure-discovery.mdx
View File

@ -3,6 +3,9 @@ title: Bootstrap Nodes and Discover Peers
hide_table_of_contents: true hide_table_of_contents: true
--- ---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This guide provides detailed steps to bootstrap your your node using [Static Peers](/learn/concepts/static-peers) and discover peers in the Waku Network using [DNS Discovery](/learn/concepts/dns-discovery). This guide provides detailed steps to bootstrap your your node using [Static Peers](/learn/concepts/static-peers) and discover peers in the Waku Network using [DNS Discovery](/learn/concepts/dns-discovery).
:::info :::info
@ -33,7 +36,7 @@ import { createLightNode } from "@waku/sdk";
// Bootstrap node using static peers // Bootstrap node using static peers
const node = await createLightNode({ const node = await createLightNode({
bootstrapPeers: ["[PEER MULTIADDR]"], bootstrapPeers: ["[PEER MULTIADDR]"],
}); });
``` ```
@ -42,26 +45,25 @@ For example, consider a node that connects to two static peers on the same local
```js ```js
// Define the list of static peers to bootstrap // Define the list of static peers to bootstrap
const peers = [ const peers = [
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H", "/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ", "/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
]; ];
// Bootstrap node using the static peers // Bootstrap node using the static peers
const node = await createLightNode({ const node = await createLightNode({
bootstrapPeers: peers, bootstrapPeers: peers,
}); });
``` ```
Alternatively, you can dial a particular node like this: Alternatively, you can dial a particular node like this:
```js ```js
// Define the list of static peers to bootstrap // Define the list of static peers to bootstrap
const peers = [ const peers = [
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H", "/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ", "/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
]; ];
const node = await createLightNode(); const node = await createLightNode();
// In case nodes are using IP address and / or `ws` protocol - additional configuration is needed: // In case nodes are using IP address and / or `ws` protocol - additional configuration is needed:
@ -73,7 +75,7 @@ const node = await createLightNode({
}); });
*/ */
const promises = peers.map(multiaddr => node.dial(multiaddr)); const promises = peers.map((multiaddr) => node.dial(multiaddr));
await Promise.all(promises); await Promise.all(promises);
``` ```
@ -114,21 +116,16 @@ const enrTree = "enrtree://[PUBLIC KEY]@[DOMAIN NAME]";
// Define node requirements // Define node requirements
const NODE_REQUIREMENTS = { const NODE_REQUIREMENTS = {
store: 3, store: 3,
lightPush: 3, lightPush: 3,
filter: 3, filter: 3,
}; };
// Bootstrap node using DNS Discovery // Bootstrap node using DNS Discovery
const node = await createLightNode({ const node = await createLightNode({
libp2p: { libp2p: {
peerDiscovery: [ peerDiscovery: [wakuDnsDiscovery([enrTree], NODE_REQUIREMENTS)],
wakuDnsDiscovery( },
[enrTree],
NODE_REQUIREMENTS,
),
],
},
}); });
``` ```
@ -139,14 +136,11 @@ import { enrTree } from "@waku/dns-discovery";
// Bootstrap node using DNS Discovery // Bootstrap node using DNS Discovery
const node = await createLightNode({ const node = await createLightNode({
libp2p: { libp2p: {
peerDiscovery: [ peerDiscovery: [
wakuDnsDiscovery( wakuDnsDiscovery([enrTree["PROD"], enrTree["TEST"]], NODE_REQUIREMENTS),
[enrTree["PROD"], enrTree["TEST"]], ],
NODE_REQUIREMENTS, },
),
],
},
}); });
``` ```
@ -161,28 +155,23 @@ import { enrTree, wakuDnsDiscovery } from "@waku/dns-discovery";
// Define the list of static peers to bootstrap // Define the list of static peers to bootstrap
const peers = [ const peers = [
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H", "/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ", "/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
]; ];
// Define node requirements // Define node requirements
const NODE_REQUIREMENTS = { const NODE_REQUIREMENTS = {
store: 3, store: 3,
lightPush: 3, lightPush: 3,
filter: 3, filter: 3,
}; };
// Bootstrap node using DNS Discovery and static peers // Bootstrap node using DNS Discovery and static peers
const node = await createLightNode({ const node = await createLightNode({
libp2p: { libp2p: {
bootstrapPeers: peers, bootstrapPeers: peers,
peerDiscovery: [ peerDiscovery: [wakuDnsDiscovery([enrTree["PROD"]], NODE_REQUIREMENTS)],
wakuDnsDiscovery( },
[enrTree["PROD"]],
NODE_REQUIREMENTS,
),
],
},
}); });
``` ```
@ -198,4 +187,4 @@ await node.waitForPeers();
// Retrieve array of peers connected to the node // Retrieve array of peers connected to the node
console.log(node.libp2p.getPeers()); console.log(node.libp2p.getPeers());
``` ```

50
docs/guides/js-waku/message-encryption.md → docs/guides/js-waku/message-encryption.mdx
View File

@ -53,8 +53,8 @@ import { createEncoder } from "@waku/message-encryption/symmetric";
// Create a symmetric message encoder // Create a symmetric message encoder
const encoder = createEncoder({ const encoder = createEncoder({
contentTopic: contentTopic, // message content topic contentTopic: contentTopic, // message content topic
symKey: symmetricKey, // symmetric key for encrypting messages symKey: symmetricKey, // symmetric key for encrypting messages
}); });
// Send the message using Light Push // Send the message using Light Push
@ -101,8 +101,8 @@ import { createEncoder } from "@waku/message-encryption/ecies";
// Create an ECIES message encoder // Create an ECIES message encoder
const encoder = createEncoder({ const encoder = createEncoder({
contentTopic: contentTopic, // message content topic contentTopic: contentTopic, // message content topic
publicKey: publicKey, // ECIES public key for encrypting messages publicKey: publicKey, // ECIES public key for encrypting messages
}); });
// Send the message using Light Push // Send the message using Light Push
@ -151,16 +151,16 @@ const alicePublicKey = getPublicKey(alicePrivateKey);
// Create a symmetric encoder that signs messages // Create a symmetric encoder that signs messages
const symmetricEncoder = createSymmetricEncoder({ const symmetricEncoder = createSymmetricEncoder({
contentTopic: contentTopic, // message content topic contentTopic: contentTopic, // message content topic
symKey: symmetricKey, // symmetric key for encrypting messages symKey: symmetricKey, // symmetric key for encrypting messages
sigPrivKey: alicePrivateKey, // private key for signing messages before encryption sigPrivKey: alicePrivateKey, // private key for signing messages before encryption
}); });
// Create an ECIES encoder that signs messages // Create an ECIES encoder that signs messages
const ECIESEncoder = createECIESEncoder({ const ECIESEncoder = createECIESEncoder({
contentTopic: contentTopic, // message content topic contentTopic: contentTopic, // message content topic
publicKey: publicKey, // ECIES public key for encrypting messages publicKey: publicKey, // ECIES public key for encrypting messages
sigPrivKey: alicePrivateKey, // private key for signing messages before encryption sigPrivKey: alicePrivateKey, // private key for signing messages before encryption
}); });
// Send and receive your messages as usual with Light Push and Filter // Send and receive your messages as usual with Light Push and Filter
@ -183,25 +183,25 @@ const bobPrivateKey = generatePrivateKey();
// Create an encoder that signs messages // Create an encoder that signs messages
const encoder = createEncoder({ const encoder = createEncoder({
contentTopic: contentTopic, contentTopic: contentTopic,
symKey: symmetricKey, symKey: symmetricKey,
sigPrivKey: bobPrivateKey, sigPrivKey: bobPrivateKey,
}); });
// Modify the callback function to verify message signature // Modify the callback function to verify message signature
const callback = (wakuMessage) => { const callback = (wakuMessage) => {
// Extract the message signature and public key of the signature // Extract the message signature and public key of the signature
// You can compare the signaturePublicKey with Alice public key // You can compare the signaturePublicKey with Alice public key
const signature = wakuMessage.signature; const signature = wakuMessage.signature;
const signaturePublicKey = wakuMessage.signaturePublicKey; const signaturePublicKey = wakuMessage.signaturePublicKey;
// Verify the message was actually signed and sent by Alice // Verify the message was actually signed and sent by Alice
// Alice's public key can be gotten from broadcasting or out-of-band methods // Alice's public key can be gotten from broadcasting or out-of-band methods
if (wakuMessage.verifySignature(alicePublicKey)) { if (wakuMessage.verifySignature(alicePublicKey)) {
console.log("This message was signed by Alice"); console.log("This message was signed by Alice");
} else { } else {
console.log("This message was NOT signed by Alice"); console.log("This message was NOT signed by Alice");
} }
}; };
await subscription.subscribe([encoder], callback); await subscription.subscribe([encoder], callback);
@ -233,4 +233,4 @@ const restoredPrivateKey = hexToBytes(privateKeyHex);
You have successfully encrypted, decrypted, and signed your messages using `Symmetric` and `ECIES` encryption methods. Have a look at the [eth-pm](https://github.com/waku-org/js-waku-examples/tree/master/examples/eth-pm) example for a working demo. You have successfully encrypted, decrypted, and signed your messages using `Symmetric` and `ECIES` encryption methods. Have a look at the [eth-pm](https://github.com/waku-org/js-waku-examples/tree/master/examples/eth-pm) example for a working demo.
::: :::
<!-- [flush-notes](https://github.com/waku-org/js-waku-examples/tree/master/examples/flush-notes) and --> <!-- [flush-notes](https://github.com/waku-org/js-waku-examples/tree/master/examples/flush-notes) and -->

2
docs/guides/js-waku/run-waku-nodejs.md
View File

@ -31,4 +31,4 @@ Before using `@waku/sdk` in a NodeJS environment, take into account these limita
## 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>. 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](https://github.com/waku-org/nwaku/issues/1332).

2
docs/guides/js-waku/use-waku-create-app.md
View File

@ -49,4 +49,4 @@ We welcome and appreciate the contributions of templates for the `@waku/create-a
4. Finally, submit a pull request to the [js-waku-examples](https://github.com/waku-org/js-waku-examples) repository. 4. Finally, submit a pull request to the [js-waku-examples](https://github.com/waku-org/js-waku-examples) repository.
5. Our team will carefully review and merge your submission upon approval. 5. Our team will carefully review and merge your submission upon approval.
Waku also provides bounties to encourage community members to contribute to the network and earn rewards. To participate in the bounty program, head to <https://github.com/waku-org/bounties>. Waku also provides bounties to encourage community members to contribute to the network and earn rewards. To participate in the bounty program, head to [https://github.com/waku-org/bounties](https://github.com/waku-org/bounties).

117
docs/guides/nwaku/config-options.md
View File

@ -7,9 +7,9 @@ Here are the available node configuration options, along with their default valu
## Application-level config ## Application-level config
| Name | Default Value | Description | | Name | Default Value | Description |
| ----------------- | --------------------------- | --------------------------------------------------------------------------------------------------- | | ----------------- | --------------------------- | ---------------------------------------------------------------------------------------------------- |
| `config-file` | | Loads configuration from a TOML file (cmd-line parameters take precedence) | | `config-file` | | Loads configuration from a TOML file (cmd-line parameters take precedence) |
| `protected-shard` | `newSeq[ProtectedShard](0)` | Shards and its public keys to be used for message validation, shard:pubkey. Argument may be repeated | | `protected-shard` | `newSeq[ProtectedShard](0)` | Shards and its public keys to be used for message validation, shard:pubkey. Argument may be repeated |
## Log config ## Log config
@ -21,21 +21,21 @@ Here are the available node configuration options, along with their default valu
## General node config ## General node config
| Name | Default Value | Description | | Name | Default Value | Description |
| --------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- | | --------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cluster-id` | `0` | Cluster id that the node is running in. Node in a different cluster id is disconnected | | `cluster-id` | `0` | Cluster id that the node is running in. Node in a different cluster id is disconnected |
| `agent-string` | `nwaku` | Node agent string which is used as identifier in network | | `agent-string` | `nwaku` | Node agent string which is used as identifier in network |
| `nodekey` | | P2P node private key as 64-char hex string | | `nodekey` | | P2P node private key as 64-char hex string |
| `listen-address` | `defaultListenAddress()` | Listening address for LibP2P (and Discovery v5, if enabled) traffic | | `listen-address` | `defaultListenAddress()` | Listening address for LibP2P (and Discovery v5, if enabled) traffic |
| `tcp-port` | `60000` | TCP listening port | | `tcp-port` | `60000` | TCP listening port |
| `ports-shift` | `0` | Add a shift to all port numbers | | `ports-shift` | `0` | Add a shift to all port numbers |
| `nat` | any | Specify method to use for determining public address. Must be one of: any, none, upnp, pmp, extip:<IP\> | | `nat` | any | Specify method to use for determining public address. Must be one of: any, none, upnp, pmp, extip:IP |
| `ext-multiaddr` | | External multiaddresses to advertise to the network. Argument may be repeated | | `ext-multiaddr` | | External multiaddresses to advertise to the network. Argument may be repeated |
| `ext-multiaddr-only` | `false` | Only announce external multiaddresses | | `ext-multiaddr-only` | `false` | Only announce external multiaddresses |
| `max-connections` | `50` | Maximum allowed number of libp2p connections | | `max-connections` | `50` | Maximum allowed number of libp2p connections |
| `relay-service-ratio` | `"60:40"` | This percentage ratio represents the relay peers to service peers. For example, 60:40, tells that 60% of the max-connections will be used for relay protocol and the other 40% of max-connections will be reserved for other service protocols (e.g., filter, lightpush, store, metadata, etc.) | | `relay-service-ratio` | `"60:40"` | This percentage ratio represents the relay peers to service peers. For example, 60:40, tells that 60% of the max-connections will be used for relay protocol and the other 40% of max-connections will be reserved for other service protocols (e.g., filter, lightpush, store, metadata, etc.) |
| `peer-store-capacity` | | Maximum stored peers in the peerstore | | `peer-store-capacity` | | Maximum stored peers in the peerstore |
| `peer-persistence` | `false` | Enable peer persistence | | `peer-persistence` | `false` | Enable peer persistence |
## DNS addrs config ## DNS addrs config
@ -47,31 +47,30 @@ Here are the available node configuration options, along with their default valu
## Relay config ## Relay config
| Name | Default Value | Description | | Name | Default Value | Description |
| -------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | -------------------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `relay` | `true` | Enable relay protocol: true\|false | | `relay` | `true` | Enable relay protocol: true\|false |
| `relay-peer-exchange` | `false` | Enable gossipsub peer exchange in relay protocol: true\|false | | `relay-peer-exchange` | `false` | Enable gossipsub peer exchange in relay protocol: true\|false |
| `rln-relay` | `false` | Enable spam protection through rln-relay: true\|false | | `rln-relay` | `false` | Enable spam protection through rln-relay: true\|false |
| `rln-relay-cred-path` | | The path for persisting rln-relay credential | | `rln-relay-cred-path` | | The path for persisting rln-relay credential |
| `rln-relay-membership-index` | | The index of the onchain commitment to use | | `rln-relay-membership-index` | | The index of the onchain commitment to use |
| `rln-relay-dynamic` | `false` | Enable waku-rln-relay with on-chain dynamic group management: true\|false | | `rln-relay-dynamic` | `false` | Enable waku-rln-relay with on-chain dynamic group management: true\|false |
| `rln-relay-id-key` | | Rln relay identity secret key as a Hex string | | `rln-relay-id-key` | | Rln relay identity secret key as a Hex string |
| `rln-relay-id-commitment-key` | | Rln relay identity commitment key as a Hex string | | `rln-relay-id-commitment-key` | | Rln relay identity commitment key as a Hex string |
| `rln-relay-eth-client-address` | `ws://localhost:8540/` | WebSocket address of an Ethereum testnet client e.g., `ws://localhost:8540/` | | `rln-relay-eth-client-address` | `ws://localhost:8540/` | WebSocket address of an Ethereum testnet client e.g., `ws://localhost:8540/` |
| `rln-relay-eth-contract-address` | | Address of membership contract on an Ethereum testnet | | `rln-relay-eth-contract-address` | | Address of membership contract on an Ethereum testnet |
| `rln-relay-eth-private-key` | | Private key for broadcasting transactions | | `rln-relay-eth-private-key` | | Private key for broadcasting transactions |
| `execute` | `false` | Runs the registration function on-chain. By default, a dry-run will occur | | `execute` | `false` | Runs the registration function on-chain. By default, a dry-run will occur |
| `rln-relay-cred-password` | | Password for encrypting RLN credentials | | `rln-relay-cred-password` | | Password for encrypting RLN credentials |
| `rln-relay-tree-path` | | Path to the RLN merkle tree sled db (https://github.com/spacejam/sled) | | `rln-relay-tree-path` | | Path to the RLN merkle tree sled db (https://github.com/spacejam/sled) |
| `rln-relay-bandwidth-threshold` | `0 # to maintain backwards compatibility` | Message rate in bytes/sec after which verification of proofs should happen | | `rln-relay-bandwidth-threshold` | `0 # to maintain backwards compatibility` | Message rate in bytes/sec after which verification of proofs should happen |
| `staticnode` | | Peer multiaddr to directly connect with. Argument may be repeated | | `staticnode` | | Peer multiaddr to directly connect with. Argument may be repeated |
| `keep-alive` | `false` | Enable keep-alive for idle connections: true\|false | | `keep-alive` | `false` | Enable keep-alive for idle connections: true\|false |
| `pubsub-topic` | | Default pubsub topic to subscribe to. Argument may be repeated. **Deprecated!** Please use `shard` and/or `content-topic` instead | | `pubsub-topic` | | Default pubsub topic to subscribe to. Argument may be repeated. **Deprecated!** Please use `shard` and/or `content-topic` instead |
| `shard` | | Shard to subscribe to. Argument may be repeated | | `shard` | | Shard to subscribe to. Argument may be repeated |
| `num-shards-in-network` | | Number of shards in the network. Used to map content topics to shards when using autosharding | | `num-shards-in-network` | | Number of shards in the network. Used to map content topics to shards when using autosharding |
| `content-topic` | | Default content topic to subscribe to. Argument may be repeated | | `content-topic` | | Default content topic to subscribe to. Argument may be repeated |
| `reliability` | `false` | Enable experimental reliability protocol true\|false | | `reliability` | `false` | Enable experimental reliability protocol true\|false |
## Store and message store config ## Store and message store config
@ -86,12 +85,12 @@ Here are the available node configuration options, along with their default valu
## Store Sync ## Store Sync
| Name | Default Value | Description | | Name | Default Value | Description |
| -------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ------------------------- | --------------- | ------------------------------------------------------------------- |
| `store-sync` | `false` | Enable/disable waku store sync protocol | | `store-sync` | `false` | Enable/disable waku store sync protocol |
| `store-sync-interval` | `300` 5 minutes | Interval between store synchronization attempts | | `store-sync-interval` | `300` 5 minutes | Interval between store synchronization attempts |
| `store-sync-range` | `3600` 1 hour | Amount of time to sync | | `store-sync-range` | `3600` 1 hour | Amount of time to sync |
| `store-sync-relay-jitter` | `20` seconds | Sync range offset to account for relay's message propagation jitter | | `store-sync-relay-jitter` | `20` seconds | Sync range offset to account for relay's message propagation jitter |
## Filter config ## Filter config
@ -106,8 +105,8 @@ Here are the available node configuration options, along with their default valu
## Light push config ## Light push config
| Name | Default Value | Description | | Name | Default Value | Description |
| --------------- | ------------- | --------------------------------------------------------- | | --------------- | ------------- | --------------------------------------------------------- | ----- |
| `lightpush` | `false` | Enable lightpush protocol: true\|false | | `lightpush` | `false` | Enable lightpush protocol: true | false |
| `lightpushnode` | | Peer multiaddr to request lightpush of published messages | | `lightpushnode` | | Peer multiaddr to request lightpush of published messages |
## REST HTTP config ## REST HTTP config
@ -132,12 +131,12 @@ Here are the available node configuration options, along with their default valu
## DNS discovery config ## DNS discovery config
| Name | Default Value | Description | | Name | Default Value | Description |
| --------------------------- | ------------------------ | ---------------------------------------------------------- | | --------------------------- | ------------------------ | ------------------------------------------------------------ |
| `dns-discovery` | `false` | Enable discovering nodes via DNS | | `dns-discovery` | `false` | Enable discovering nodes via DNS |
| `dns-discovery-url` | | URL for DNS node list in format 'enrtree://<key\>@<fqdn\>' | | `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 | | `dns-discovery-name-server` | `["1.1.1.1", "1.0.0.1"]` | DNS name server IPs to query. Argument may be repeated |
| `rendezvous` | `true` | Enable waku rendezvous discovery server | | `rendezvous` | `true` | Enable waku rendezvous discovery server |
## Discv5 config ## Discv5 config
@ -170,9 +169,9 @@ Here are the available node configuration options, along with their default valu
## Non-relay, request-response protocol DOS protection configuration ## Non-relay, request-response protocol DOS protection configuration
| Name | Default Value | Description | | Name | Default Value | Description |
| ---------------------------- | ------------- | ------------------------------------------------------ | | ------------ | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `rate-limit` | | This is a repeatable option. Each can describe a specific rate limit configuration for a particular protocol.<br />Formatted as:`<protocol>:volume/period<time-unit>`<br />- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`<br />-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`<br />-volume must be an integer value, representing number of requests over the period of time allowed.<br />-period\<time-unit\> must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`<br />- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.<br />- In case of multiple set of the same protocol limit, last one will take place.<br />- if config is not set, - which is the default - means unlimited requests are allowed.<br />-filter has a bit different approach. It has a default setting applied if not overridden. Rate limit setting for filter will be applied per subscriber-peers, not globally - it must be considered when changing the setting.<br /><br />Examples:<br />`--rate-limit="100/1s"` - default for all protocols if not set otherwise.<br />`--rate-limit="lightpush:0/0s"` - lightpush protocol will not be rate-limited.<br />`--rate-limit="store:130/1500ms"` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.<br />`--rate-limit="px:10/1h"` PeerExchange will serve only 10 requests every hour.<br />`--rate-limit="filter:8/5m"` - will allow 8 subs/unsubs/ping requests for each subscriber within every 5 min. | | `rate-limit` | | This is a repeatable option. Each can describe a specific rate limit configuration for a particular protocol.<br />Formatted as:`<protocol>:volume/period<time-unit>`<br />- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`<br />-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`<br />-volume must be an integer value, representing number of requests over the period of time allowed.<br />-period\<time-unit\> must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`<br />- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.<br />- In case of multiple set of the same protocol limit, last one will take place.<br />- if config is not set, - which is the default - means unlimited requests are allowed.<br />-filter has a bit different approach. It has a default setting applied if not overridden. Rate limit setting for filter will be applied per subscriber-peers, not globally - it must be considered when changing the setting.<br /><br />Examples:<br />`--rate-limit="100/1s"` - default for all protocols if not set otherwise.<br />`--rate-limit="lightpush:0/0s"` - lightpush protocol will not be rate-limited.<br />`--rate-limit="store:130/1500ms"` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.<br />`--rate-limit="px:10/1h"` PeerExchange will serve only 10 requests every hour.<br />`--rate-limit="filter:8/5m"` - will allow 8 subs/unsubs/ping requests for each subscriber within every 5 min. |
:::tip :::tip
To configure your node using the provided configuration options, have a look at the [Node Configuration Methods](/guides/nwaku/config-methods) guide. To configure your node using the provided configuration options, have a look at the [Node Configuration Methods](/guides/nwaku/config-methods) guide.

2
docs/guides/nwaku/run-docker-compose.md
View File

@ -81,7 +81,7 @@ docker-compose logs -f nwaku
## Monitor the node ## Monitor the node
Visit <http://localhost:3000/d/yns_4vFVk/nwaku-monitoring> to view your node metrics in real time. Visit [http://localhost:3000/d/yns_4vFVk/nwaku-monitoring](http://localhost:3000/d/yns_4vFVk/nwaku-monitoring) to view your node metrics in real time.
![nwaku compose dashboard](/img/nwaku-compose-dashboard.png) ![nwaku compose dashboard](/img/nwaku-compose-dashboard.png)

8
docs/learn/research.md
View File

@ -9,14 +9,14 @@ The following features are currently experimental and under research and initial
We aim to enable an incentivised spam protection technique to enhance `Relay` by using [Rate Limit Nullifiers (RLN)](https://rfc.vac.dev/vac/32/rln-v1/). 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 aim to enable an incentivised spam protection technique to enhance `Relay` by using [Rate Limit Nullifiers (RLN)](https://rfc.vac.dev/vac/32/rln-v1/). 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/> We have prepared a PoC implementation of this method in JS: [https://examples.waku.org/rln-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 be tracked from here: <https://github.com/vacp2p/research/issues/148>. 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 be tracked from here: [https://github.com/vacp2p/research/issues/148](https://github.com/vacp2p/research/issues/148).
In a nutshell, peers have to pay for the service they obtain from each other. In addition to incentivising the service provider, accounting also makes DoS attacks costly for malicious peers. The accounting model can be used in `Store` and `Filter` to protect against DoS attacks. In a nutshell, peers have to pay for the service they obtain from each other. In addition to incentivising the service provider, accounting also makes DoS attacks costly for malicious peers. The accounting model can be used in `Store` and `Filter` to protect against DoS attacks.
Additionally, along with RLN, this gives node operators who provide a useful service to the network an incentive to perform that service. Read more here: <https://vac.dev/building-privacy-protecting-infrastructure> Additionally, along with RLN, this gives node operators who provide a useful service to the network an incentive to perform that service. Read more here: [https://vac.dev/building-privacy-protecting-infrastructure](https://vac.dev/building-privacy-protecting-infrastructure)
You can also read more about the ongoing challenges the Waku team is working on here: <https://github.com/waku-org/research> You can also read more about the ongoing challenges the Waku team is working on here: [https://github.com/waku-org/research](https://github.com/waku-org/research)

2
docs/learn/security-features.md
View File

@ -22,7 +22,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 behaviour and remove peers with low scores. 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>. 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](https://github.com/vacp2p/research/issues/148).
## [Data confidentiality, integrity, and authenticity](https://rfc.vac.dev/waku/standards/core/10/waku2/#data-confidentiality-integrity-and-authenticity) ## [Data confidentiality, integrity, and authenticity](https://rfc.vac.dev/waku/standards/core/10/waku2/#data-confidentiality-integrity-and-authenticity)

9
docs/research/research-and-studies/rln-key-benchmarks.md
View File

@ -5,12 +5,14 @@ title: RLN Key Benchmarks
## Introduction ## Introduction
Since RLN has been chosen as the spamming protection mechanism for waku, we must understand the practical implications of using it. This issue explains the main differences between `relay` and `rln-relay` and gives some benchmarks after running simulations using `waku-simulator`, in a network with the following characteristics: Since RLN has been chosen as the spamming protection mechanism for waku, we must understand the practical implications of using it. This issue explains the main differences between `relay` and `rln-relay` and gives some benchmarks after running simulations using `waku-simulator`, in a network with the following characteristics:
- 100 nwaku nodes, each one with a valid rln membership and publishing a message every 10 seconds to a common topic. - 100 nwaku nodes, each one with a valid rln membership and publishing a message every 10 seconds to a common topic.
- rln contract deployed in Ethereum Sepolia - rln contract deployed in Ethereum Sepolia
- 10.000 memberships registered in the contract - 10.000 memberships registered in the contract
- pure relay (store and light protocols disabled) - pure relay (store and light protocols disabled)
The main deltas `rln` vs `rln-relay` are: The main deltas `rln` vs `rln-relay` are:
- New `proof ` field in `WakuMessage` containing 384 extra bytes. This field must be generated and attached to each message. - New `proof ` field in `WakuMessage` containing 384 extra bytes. This field must be generated and attached to each message.
- New validator, that uses `proof` to `Accept` or `Reject` the message. The proof has to be verified. - New validator, that uses `proof` to `Accept` or `Reject` the message. The proof has to be verified.
- New dependency on a blockchain, Ethereum, or any EVM chain, to keep track of the members allowed to publish. - New dependency on a blockchain, Ethereum, or any EVM chain, to keep track of the members allowed to publish.
@ -18,6 +20,7 @@ The main deltas `rln` vs `rln-relay` are:
But what are the practical implications of these? But what are the practical implications of these?
## TLDR: ## TLDR:
- Proof generation is constant-ish. 0.15 second for each proof - Proof generation is constant-ish. 0.15 second for each proof
- Proof verification is constant-ish, 0.012 seconds. In a network with 10k nodes and D=6 this would add an overhead delay of 0.06 seconds. - Proof verification is constant-ish, 0.012 seconds. In a network with 10k nodes and D=6 this would add an overhead delay of 0.06 seconds.
- Gossipsub scoring drops connections from spammer peers, which acts as the punishment (instead of slashing). Validated in the simulation. - Gossipsub scoring drops connections from spammer peers, which acts as the punishment (instead of slashing). Validated in the simulation.
@ -33,7 +36,7 @@ Seems that proof generation times stay constant no matter the size of the messag
On the other hand, rln also adds an overhead in the gossipsub validation process. On average it takes `0.012 seconds` to verify the proof. It seems that when we increase the message size, validation time seems to increase a bit, which can be for any other reason besides rln itself (eg deserializing the message might take longer). On the other hand, rln also adds an overhead in the gossipsub validation process. On average it takes `0.012 seconds` to verify the proof. It seems that when we increase the message size, validation time seems to increase a bit, which can be for any other reason besides rln itself (eg deserializing the message might take longer).
This number seems reasonable and shouldn't affect that much the average delay of a message. Assuming a d-regular graph, with `10k` nodes and `D=6`, we can have up to `log(total_nodes)/log(D)=5` hops. So in the worst case, rln will add a network latency of `0.012*5 = 0.06 seconds` This number seems reasonable and shouldn't affect that much the average delay of a message. Assuming a d-regular graph, with `10k` nodes and `D=6`, we can have up to `log(total_nodes)/log(D)=5` hops. So in the worst case, rln will add a network latency of `0.012*5 = 0.06 seconds`
![proof-verification-times](imgs/proof-verification-times.png) ![proof-verification-times](imgs/proof-verification-times.png)
@ -48,13 +51,15 @@ In the following simulation, we can see `100` nwaku interconnected nodes, where
## RLN tree sync ## RLN tree sync
Using RLN implies that waku should now piggyback on a blockchain (the case study uses Ethereum Sepolia) and has to stay up to date with the latest events emitted by the rln smart contract. These events are used to locally construct a tree that contains all members allowed to create valid proofs to send messages. Some numbers: Using RLN implies that waku should now piggyback on a blockchain (the case study uses Ethereum Sepolia) and has to stay up to date with the latest events emitted by the rln smart contract. These events are used to locally construct a tree that contains all members allowed to create valid proofs to send messages. Some numbers:
- A tree with 10k members takes `2Mbytes` of space. Negligible. - A tree with 10k members takes `2Mbytes` of space. Negligible.
- A tree with 10k members takes `<4 minutes to synchronize. Assumable since it's done just once. - A tree with 10k members takes `<4` minutes to synchronize. Assumable since it's done just once.
- With a block range of 5000 blocks for each request, we would need `520 requests` to synchronize 1 year of historical data from the tree. Assumable since most of the free endpoints out there allow 100k/day. - With a block range of 5000 blocks for each request, we would need `520 requests` to synchronize 1 year of historical data from the tree. Assumable since most of the free endpoints out there allow 100k/day.
## Performance relay vs. rln-relay ## Performance relay vs. rln-relay
Same simulation with 100 nodes was executed `with rln` and `without rln`: Same simulation with 100 nodes was executed `with rln` and `without rln`:
- Memory consumption is almost identical - Memory consumption is almost identical
**with rln** **with rln**

1
docs/rules-of-engagement.md
View File

@ -1,5 +1,4 @@
--- ---
displayed_sidebar: null
sidebar_class_name: hidden sidebar_class_name: hidden
pagination_prev: null pagination_prev: null
pagination_next: null pagination_next: null

12
docusaurus.config.js
View File

@ -68,22 +68,22 @@ const config = {
type: "search", type: "search",
}, },
{ {
type: "docSidebar",
position: "left", position: "left",
sidebarId: "guides",
label: "Guides", label: "Guides",
to: "/",
activeBaseRegex: "^/$|^/guides/",
}, },
{ {
type: "docSidebar",
position: "left", position: "left",
sidebarId: "learn",
label: "Learn", label: "Learn",
to: "/learn/waku-network",
activeBaseRegex: "^/learn/",
}, },
{ {
type: "docSidebar",
position: "left", position: "left",
sidebarId: "research",
label: "Research", label: "Research",
to: "/research",
activeBaseRegex: "^/research/",
}, },
{ {
href: "https://discord.waku.org", href: "https://discord.waku.org",

20
package.json
View File

@ -16,22 +16,22 @@
"check:spell": "cspell \"**/*.{md,mdx}\"" "check:spell": "cspell \"**/*.{md,mdx}\""
}, },
"dependencies": { "dependencies": {
"@acid-info/docusaurus-fathom": "^1.0.0-alpha.111", "@acid-info/docusaurus-fathom": "^1.0.3-beta.2",
"@acid-info/logos-docusaurus-preset": "^1.0.0-alpha.143", "@acid-info/logos-docusaurus-preset": "^1.0.3-beta.11",
"@docusaurus/core": "^2.4.1", "@docusaurus/core": "3.8.1",
"@docusaurus/preset-classic": "^2.4.1", "@docusaurus/preset-classic": "3.8.1",
"@docusaurus/theme-mermaid": "^2.4.1", "@docusaurus/theme-mermaid": "3.8.1",
"@emotion/react": "^11.11.0", "@emotion/react": "^11.11.0",
"@emotion/styled": "^11.11.0", "@emotion/styled": "^11.11.0",
"@mdx-js/react": "^1.6.22", "@mdx-js/react": "^3.0.0",
"add": "^2.0.6", "add": "^2.0.6",
"dotenv": "^16.0.3", "dotenv": "^16.0.3",
"prism-react-renderer": "^1.3.5", "prism-react-renderer": "^2.3.0",
"react": "^17.0.2", "react": "^19.0.0",
"react-dom": "^17.0.2" "react-dom": "^19.0.0"
}, },
"devDependencies": { "devDependencies": {
"@docusaurus/module-type-aliases": "^2.4.1", "@docusaurus/module-type-aliases": "3.8.1",
"@tsconfig/docusaurus": "^1.0.5", "@tsconfig/docusaurus": "^1.0.5",
"cspell": "^6.16.0", "cspell": "^6.16.0",
"docusaurus-plugin-sass": "^0.2.2", "docusaurus-plugin-sass": "^0.2.2",

28
src/css/custom.scss
View File

@ -44,27 +44,27 @@ html[data-theme="dark"] .header-github-link:before {
} }
.case-study-container a { .case-study-container a {
display: block; display: block;
width: 100%; width: 100%;
margin-bottom: 20px; margin-bottom: 20px;
} }
.case-study-container a img { .case-study-container a img {
width: 100%; width: 100%;
height: auto; height: auto;
} }
@media (min-width: 768px) { @media (min-width: 768px) {
.case-study-container a { .case-study-container a {
display: inline-block; display: inline-block;
width: 48%; width: 48%;
margin-bottom: 20px; margin-bottom: 20px;
margin-right: 2%; margin-right: 2%;
} }
.case-study-container a:nth-child(2n) { .case-study-container a:nth-child(2n) {
margin-right: 0; margin-right: 0;
} }
} }
.external-link { .external-link {

12303
yarn.lock
View File

File diff suppressed because it is too large Load Diff