diff --git a/docs/guides/nwaku/config-options.md b/docs/guides/nwaku/config-options.md
index 654e915..dcad83c 100644
--- a/docs/guides/nwaku/config-options.md
+++ b/docs/guides/nwaku/config-options.md
@@ -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.
\:volume/period\
- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`
-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`
-volume must be an integer value, representing number of requests over the period of time allowed.
-period\ must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`
- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.
- In case of multiple set of the same protocol limit, last one will take place.
- if config is not set it means unlimited requests are allowed.
-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.
Examples:
- `100/1s` - default for all protocols if not set otherwise.
-`lightpush:0/0s` - lightpush protocol will be not rate limited.
-`store:130/1500ms` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.
-`px:10/1h` PeerExchange will serve only 10 requests in every hour.
-`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.
:::
diff --git a/docs/guides/nwaku/upgrade-instructions.md b/docs/guides/nwaku/upgrade-instructions.md
new file mode 100644
index 0000000..3a28fda
--- /dev/null
+++ b/docs/guides/nwaku/upgrade-instructions.md
@@ -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
+
+
+
+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`
+
+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"`
+
+
+
+
+Named sharding was deprecated in this version. This means that pubsub topics will only be supported if they comply with the static sharding format: /waku/2/rs/<CLUSTER_ID>/<SHARD_ID>
+
+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.
+
+
diff --git a/docs/research/index.md b/docs/research/index.md
index 7bc6af8..fabbcfb 100644
--- a/docs/research/index.md
+++ b/docs/research/index.md
@@ -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)
diff --git a/sidebars.js b/sidebars.js
index fcb3b0b..040d1fe 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -22,6 +22,7 @@ const sidebars = {
"guides/nwaku/config-options",
"guides/nwaku/configure-nwaku",
"guides/nwaku/faq",
+ "guides/nwaku/upgrade-instructions",
{
type: "html",
value: