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

Merge branch 'develop' into weboko/local-nodes

Browse Source
This commit is contained in:
Sasha 2024-09-30 17:10:23 +02:00 committed by GitHub
commit fb07b6720d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 257 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/workflows/add-action-project.yml vendored
View File

@ -14,4 +14,4 @@ jobs:
- uses: actions/add-to-project@v0.5.0
with:
project-url: https://github.com/orgs/waku-org/projects/2
github-token: ${{ secrets.ADD_TO_PROJECT_PAT }}
github-token: ${{ secrets.ADD_TO_PROJECT_20240815 }}

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

@ -66,9 +66,11 @@ Here are the available node configuration options, along with their default valu
| `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 |
| `keep-alive` | `false` | Enable keep-alive for idle connections: true\|false |
| `topic` | `["/waku/2/default-waku/proto"]` | Default topic to subscribe to. Argument may be repeated. Deprecated! Please use `pubsub-topic` and/or `content-topic` instead |
| `pubsub-topic` | | Default pubsub topic to subscribe to. Argument may be repeated |
| `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 |
| `content-topic` | | Default content topic to subscribe to. Argument may be repeated |
| `reliability` | `false` | Enable experimental reliability protocol true\|false |
## Store and message store config
@ -107,7 +109,6 @@ Here are the available node configuration options, along with their default valu
| `rest-port` | `8645` | Listening port of the REST HTTP server |
| `rest-relay-cache-capacity` | `30` | Capacity of the Relay REST API message cache |
| `rest-admin` | `false` | Enable access to REST HTTP Admin API: true\|false |
| `rest-private` | `false` | Enable access to REST HTTP Private API: true\|false |
| `rest-allow-origin` | | Allow cross-origin requests from the specified origin. When using the REST API in a browser, specify the origin host to get a valid response from the node REST HTTP server. This option may be repeated and can contain wildcards (?,\*) for defining URLs and ports such as `localhost:*`, `127.0.0.1:8080`, or allow any website with `*` |
## Metrics config
@ -156,6 +157,12 @@ Here are the available node configuration options, along with their default valu
| `websocket-secure-key-path` | | Secure websocket key path: '/path/to/key.txt' |
| `websocket-secure-cert-path` | | Secure websocket Certificate path: '/path/to/cert.txt' |
## Non relay, request-response protocol DOS protection configuration
| Name | Default Value | Description |
| ---------------------------- | ------------- | ------------------------------------------------------ |
| `rate-limit` | | This is a repeatable option. Each one of them can describe spefic rate limit configuration for a particular protocol.<br />\<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 it 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 />- `100/1s` - default for all protocols if not set otherwise.<br />-`lightpush:0/0s` - lightpush protocol will be not rate limited.<br />-`store:130/1500ms` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.<br />-`px:10/1h` PeerExchange will serve only 10 requests in every hour.<br />-`filter:8/5m` - will allow 8 subs/unsubs/ping requests for each subscribers within every 5 min. |
:::tip
To configure your node using the provided configuration options, have a look at the [Node Configuration Methods](/guides/nwaku/config-methods) guide.
:::

32
docs/guides/nwaku/upgrade-instructions.md Normal file
View File

@ -0,0 +1,32 @@
---
title: Upgrade Instructions
hide_table_of_contents: true
sidebar_label: Upgrade Instructions
---
import { AccordionItem } from '@site/src/components/mdx'
If you are currently using Nwaku, running an old version and want to upgrade your node, please follow the below migration instructions for each target release newer than your current running version in ascending order.
For example, if you are interested in the version v0.32.0 and are currently running v0.30.0, follow the instructions for v0.31.0 and then the ones for v0.32.0
## Target Releases
<AccordionItem title="v0.32.0">
The `--protected-topic` CLI config was deprecated and is replaced by the new `--protected-shard` configuration. Instead of configuring `topic:public_key` you will now need to configure `shard:public_key`<br /><br />
For example, if you used to run your node with `--protected-topic="waku/2/rs/3/4:your_public_key"` you will need to replace this configuration for `--protected-shard="4:your_public_key"`
</AccordionItem>
<AccordionItem title="v0.31.0">
Named sharding was deprecated in this version. This means that pubsub topics will only be supported if they comply with the static sharding format: <code>/waku/2/rs/&lt;CLUSTER_ID&gt;/&lt;SHARD_ID&gt;</code><br /><br />
In order to migrate your existing application, you need to:
1. Make sure that your clients are sending messages to pubsub topics in the required format. Check that in your interactions with Nwaku's REST API or when using `js-waku`, the configured pubsub topics follow the static sharding format defined above.
2. When running a node with the `--pubsub-topic` CLI flag, the values provided should comply with the static sharding format.
3. If your application relies on nodes or clients that may not be updated immediately, keep your node on an older version while subscribing to both the current pubsub topic and the new pubsub topic that will comply with the static sharding format. In that case, you can keep backward compatibility for a migration period.
</AccordionItem>

6
docs/learn/faq.md
View File

@ -33,3 +33,9 @@ import { AccordionItem } from '@site/src/components/mdx'
<AccordionItem title="What are Rate Limiting Nullifiers (RLN)?">
<a href="/learn/concepts/protocols#rln-relay">Rate Limiting Nullifier</a> is a zero-knowledge (ZK) protocol enabling spam protection in a decentralized network while preserving privacy. Each message must be accompanied by a ZK proof, which <a href="/learn/concepts/protocols#relay">Relay</a> nodes verify to ensure the publishers do not send more messages than they are allowed. The ZK proof does not leak any private information about message publishers - it only proves they are members of a set of users allowed to publish a certain number of messages per given time frame.
</AccordionItem>
<AccordionItem title="How to start a Waku node?">
Follow the README instructions at <a href="https://docs.waku.org/guides/nwaku/run-node">nwaku-compose</a>.
</AccordionItem>

201
docs/migrations/js-waku/migration_v0.026_0.027.md Normal file
View File

@ -0,0 +1,201 @@
# Migrating to Waku v0.027
A migration guide for refactoring your application code from Waku v0.026 to v0.027.
## Table of Contents
- [Migrating to Waku v0.027](#migrating-to-waku-v0027)
- [Table of Contents](#table-of-contents)
- [Network Configuration](#network-configuration)
- [Default Network Configuration](#default-network-configuration)
- [Static Sharding](#static-sharding)
- [Auto Sharding](#auto-sharding)
- [Pubsub Topic Configuration](#pubsub-topic-configuration)
- [Removed APIs](#removed-apis)
- [Type Changes](#type-changes)
- [Internal/Private Utility Function Changes](#internalprivate-utility-function-changes)
## Network Configuration
The way to configure network settings for a Waku node has been simplified. The new NetworkConfig type only allows for Static Sharding or Auto Sharding.
### Default Network Configuration
If no network configuration is provided when creating a Light Node, The Waku Network configuration will be used by default.
**Before**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode();
// This would use the default pubsub topic, that was, `/waku/2/default-waku/proto`
```
**After**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode();
// This will now use The Waku Network configuration by default:
// { clusterId: 1, shards: [0,1,2,3,4,5,6,7] }
```
### Static Sharding
**Before**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
shardInfo: {
clusterId: 1,
shards: [0, 1, 2, 3]
}
});
```
**After**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
networkConfig: {
clusterId: 1,
shards: [0, 1, 2, 3]
}
});
```
### Auto Sharding
**Before**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
shardInfo: {
clusterId: 1,
contentTopics: ["/my-app/1/notifications/proto"]
}
});
```
**After**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
networkConfig: {
clusterId: 1,
contentTopics: ["/my-app/1/notifications/proto"]
}
});
```
## Pubsub Topic Configuration
Named pubsub topics are no longer supported. You must use either Static Sharding or Auto Sharding to configure pubsub topics.
**Before**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
pubsubTopics: ["/waku/2/default-waku/proto"]
});
```
**After**
Use Static Sharding:
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
networkConfig: {
clusterId: 1,
shards: [0, 1, 2, 3, 4, 5, 6, 7]
}
});
```
Or use Auto Sharding:
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
networkConfig: {
clusterId: 1,
contentTopics: ["/your-app/1/default/proto"]
}
});
```
## Removed APIs
The following APIs have been removed:
- ApplicationInfo type: Use `string` for application and version in `NetworkConfig` instead.
- `shardInfo` option in `createLightNode`: Use `networkConfig` instead.
- `pubsubTopics` option in `createLightNode`: Use `networkConfig` with Static Sharding or Auto Sharding instead.
If you were using `ApplicationInfo` before, you should now use `ContentTopicInfo` (Auto Sharding) and specify your application and version in the content topic `string`.
**Before**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
shardInfo: {
clusterId: 1,
application: "my-app",
version: "1"
}
});
```
**After**
```typescript
import { createLightNode } from "@waku/sdk";
const waku = await createLightNode({
networkConfig: {
clusterId: 1,
contentTopics: ["/my-app/1/default/proto"]
}
});
```
## Type Changes
- `ShardingParams` has been removed. Use `NetworkConfig` instead.
- `NetworkConfig` is now defined as `StaticSharding` | `AutoSharding`.
- `StaticSharding` is equivalent to the previous `ShardInfo`.
- `AutoSharding` is equivalent to the previous `ContentTopicInfo`.
## Internal/Private Utility Function Changes
Several utility functions have been updated or added:
- `ensureShardingConfigured` has been removed. Use `derivePubsubTopicsFromNetworkConfig` instead.
- New function `derivePubsubTopicsFromNetworkConfig` has been added to derive pubsub topics from the network configuration.
- `shardInfoToPubsubTopics` now accepts `Partial<NetworkConfig>` instead of `Partial<ShardingParams>`.
- New function `pubsubTopicsToShardInfo` has been added to convert pubsub topics to a ShardInfo object.
If you were using any of these utility functions directly, you'll need to update your code accordingly.
**Before**
```typescript
import { ensureShardingConfigured } from "@waku/utils";
const result = ensureShardingConfigured(shardInfo);
```
**After**
```typescript
import { derivePubsubTopicsFromNetworkConfig } from "@waku/utils";
const pubsubTopics = derivePubsubTopicsFromNetworkConfig(networkConfig);
```
Note: The default `NetworkConfig` for The Waku Network is now `{ clusterId: 1, shards: [0,1,2,3,4,5,6,7] }.`

6
docs/research/index.md
View File

@ -7,3 +7,9 @@ sidebar_position: 1
**Research and Studies**: Protocol simulations and theoretical analysis to support the design of Waku protocols. The protocol definitions are on the [Waku RFCs](https://rfc.vac.dev/waku) website.
**Benchmarks**: Results of implementations and engineering-related benchmarks for Waku clients.
Waku also has the following published research papers:
- [**WAKU-RLN-RELAY: Privacy-Preserving Peer-to-Peer Economic Spam Protection**](https://arxiv.org/abs/2207.00117)
- [**Message Latency in Waku Relay with Rate Limiting Nullifiers**](https://eprint.iacr.org/2024/1073)
- [**Waku: A Family of Modular P2P Protocols For Secure & Censorship-Resistant Communication**](https://arxiv.org/abs/2207.00038)
- [**The Waku Network as Infrastructure for dApps**](https://ieeexplore.ieee.org/document/10646404)

1
sidebars.js
View File

@ -22,6 +22,7 @@ const sidebars = {
"guides/nwaku/config-options",
"guides/nwaku/configure-nwaku",
"guides/nwaku/faq",
"guides/nwaku/upgrade-instructions",
{
type: "html",
value: