chore: switch wakuv2 to waku fleet (#2519)
See https://github.com/status-im/infra-nim-waku/issues/91
This commit is contained in:
Anton Iakimov
parent
2173fe2243
commit
18a053591d
|
|
@ -12,7 +12,7 @@ Add appropriate release number to title!
|
|||
|
||||
For detailed info on the release process refer to https://github.com/waku-org/nwaku/blob/master/docs/contributors/release-process.md
|
||||
-->
|
||||
|
||||
|
||||
### Items to complete
|
||||
- [ ] create release branch
|
||||
- [ ] assign release candidate tag
|
||||
|
|
@ -23,5 +23,5 @@ For detailed info on the release process refer to https://github.com/waku-org/nw
|
|||
- [ ] assign release tag to the cherry-picked release notes commit
|
||||
- [ ] create GitHub release
|
||||
- [ ] deploy the release to DockerHub
|
||||
- [ ] deploy release to `wakuv2.prod` fleet
|
||||
- [ ] [deploy release to `waku.sandbox` fleet](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox)
|
||||
- [ ] announce the release
|
||||
|
|
|
|||
|
|
@ -420,12 +420,12 @@ proc processInput(rfd: AsyncFD, rng: ref HmacDrbgContext) {.async.} =
|
|||
|
||||
if conf.fleet == Fleet.test:
|
||||
dnsDiscoveryUrl = some(
|
||||
"enrtree://AO47IDOLBKH72HIZZOXQP6NMRESAN7CHYWIBNXDXWRJRZWLODKII6@test.wakuv2.nodes.status.im"
|
||||
"enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im"
|
||||
)
|
||||
else:
|
||||
# Connect to prod by default
|
||||
# Connect to sandbox by default
|
||||
dnsDiscoveryUrl = some(
|
||||
"enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im"
|
||||
"enrtree://AIRVQ5DDA4FFWLRBCHJWUWOO6X6S4ZTZ5B667LQ6AJU6PEYDLRD5O@sandbox.waku.nodes.status.im"
|
||||
)
|
||||
elif conf.dnsDiscovery and conf.dnsDiscoveryUrl != "":
|
||||
# No pre-selected fleet. Discover nodes via DNS using user config
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ The following options are available:
|
|||
Connect to the network through a given bootstrap node, with default parameters. See metrics section for the data that it exposes.
|
||||
|
||||
```console
|
||||
./build/networkmonitor --log-level=INFO --b="enr:-Nm4QOdTOKZJKTUUZ4O_W932CXIET-M9NamewDnL78P5u9DOGnZlK0JFZ4k0inkfe6iY-0JAaJVovZXc575VV3njeiABgmlkgnY0gmlwhAjS3ueKbXVsdGlhZGRyc7g6ADg2MW5vZGUtMDEuYWMtY24taG9uZ2tvbmctYy53YWt1djIucHJvZC5zdGF0dXNpbS5uZXQGH0DeA4lzZWNwMjU2azGhAo0C-VvfgHiXrxZi3umDiooXMGY9FvYj5_d1Q4EeS7eyg3RjcIJ2X4N1ZHCCIyiFd2FrdTIP"
|
||||
./build/networkmonitor --log-level=INFO --b="enr:-QEkuEB3WHNS-xA3RDpfu9A2Qycr3bN3u7VoArMEiDIFZJ66F1EB3d4wxZN1hcdcOX-RfuXB-MQauhJGQbpz3qUofOtLAYJpZIJ2NIJpcIQI2SVcim11bHRpYWRkcnO4bgA0Ni9ub2RlLTAxLmFjLWNuLWhvbmdrb25nLWMud2FrdS5zYW5kYm94LnN0YXR1cy5pbQZ2XwA2Ni9ub2RlLTAxLmFjLWNuLWhvbmdrb25nLWMud2FrdS5zYW5kYm94LnN0YXR1cy5pbQYfQN4DgnJzkwABCAAAAAEAAgADAAQABQAGAAeJc2VjcDI1NmsxoQPK35Nnz0cWUtSAhBp7zvHEhyU_AqeQUlqzLiLxfP2L4oN0Y3CCdl-DdWRwgiMohXdha3UyDw"
|
||||
```
|
||||
|
||||
```console
|
||||
|
|
|
|||
|
|
@ -30,14 +30,14 @@ $ make wakucanary
|
|||
And used as follows. A reachable node that supports both `store` and `filter` protocols.
|
||||
|
||||
```console
|
||||
$ ./build/wakucanary --address=/ip4/8.210.222.231/tcp/30303/p2p/16Uiu2HAm4v86W3bmT1BiH6oSPzcsSr24iDQpSN5Qa992BCjjwgrD --protocol=store --protocol=filter
|
||||
$ ./build/wakucanary --address=/dns4/node-01.ac-cn-hongkong-c.waku.sandbox.status.im/tcp/30303/p2p/16Uiu2HAmSJvSJphxRdbnigUV5bjRRZFBhTtWFTSyiKaQByCjwmpV --protocol=store --protocol=filter
|
||||
$ echo $?
|
||||
0
|
||||
```
|
||||
|
||||
A node that can't be reached.
|
||||
```console
|
||||
$ ./build/wakucanary --address=/ip4/8.210.222.231/tcp/1000/p2p/16Uiu2HAm4v86W3bmT1BiH6oSPzcsSr24iDQpSN5Qa992BCjjwgrD --protocol=store --protocol=filter
|
||||
$ ./build/wakucanary --address=/dns4/node-01.ac-cn-hongkong-c.waku.sandbox.status.im/tcp/1000/p2p/16Uiu2HAmSJvSJphxRdbnigUV5bjRRZFBhTtWFTSyiKaQByCjwmpV --protocol=store --protocol=filter
|
||||
$ echo $?
|
||||
1
|
||||
```
|
||||
|
|
@ -53,4 +53,4 @@ Websockets are also supported. The websocket port openned by waku canary is calc
|
|||
```console
|
||||
$ ./build/wakucanary --address=/ip4/127.0.0.1/tcp/7777/ws/p2p/16Uiu2HAm4ng2DaLPniRoZtMQbLdjYYWnXjrrJkGoXWCoBWAdn1tu --protocol=store --protocol=filter
|
||||
$ ./build/wakucanary --address=/ip4/127.0.0.1/tcp/7777/wss/p2p/16Uiu2HAmB6JQpewXScGoQ2syqmimbe4GviLxRwfsR8dCpwaGBPSE --protocol=store --websocket-secure-key-path=MyKey.key --websocket-secure-cert-path=MyCertificate.crt
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -11,9 +11,8 @@ https://ci.infra.status.im/job/nim-waku/
|
|||
It currently consists of four jobs:
|
||||
|
||||
* [manual](https://ci.infra.status.im/job/nim-waku/job/manual/) - For manually executing builds using parameters.
|
||||
* [deploy-wakuv1-test](https://ci.infra.status.im/job/nim-waku/job/deploy-wakuv1-test/) - Builds every new commit in `master` and deploys to `wakuv1.test` fleet.
|
||||
* [deploy-wakuv2-test](https://ci.infra.status.im/job/nim-waku/job/deploy-wakuv2-test/) - Builds every new commit in `master` and deploys to `wakuv2.test` fleet.
|
||||
* [deploy-wakuv2-prod](https://ci.infra.status.im/job/nim-waku/job/deploy-wakuv2-prod/) - Currently has no automatic trigger, and deploys to `wakuv2.prod` fleet.
|
||||
* [deploy-waku-test](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/) - Builds every new commit in `master` and deploys to `waku.test` fleet.
|
||||
* [deploy-waku-sandbox](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/) - Currently has no automatic trigger, and deploys to `waku.sandbox` fleet.
|
||||
|
||||
# Configuration
|
||||
|
||||
|
|
@ -29,5 +28,5 @@ Key part is the definition of five `parameters`:
|
|||
|
||||
The use of `?:` [Elvis operator](http://groovy-lang.org/operators.html#_elvis_operator) plays a key role in allowing parameters to be changed for each defined job in Jenkins without it being overridden by the `Jenkinsfile` defaults after every job run.
|
||||
```groovy
|
||||
defaultValue: params.IMAGE_TAG ?: 'deploy-wakuv2-test',
|
||||
defaultValue: params.IMAGE_TAG ?: 'deploy-waku-test',
|
||||
```
|
||||
|
|
|
|||
|
|
@ -86,13 +86,13 @@ Ensure all items in this list are ticked:
|
|||
> It should be enough to inform clients on the `#nwaku` and `#announce` channels on Discord.
|
||||
> Informal conversations with specific repo maintainers are often part of this process.
|
||||
- Check if nwaku configuration parameters changed. If so [update fleet configuration](https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741?pvs=4#d2d2f0fe4b3c429fbd860a1d64f89a64) in [infra-nim-waku](https://github.com/status-im/infra-nim-waku)
|
||||
- Deploy release to the `wakuv2.prod` fleet from [Jenkins](https://ci.infra.status.im/job/nim-waku/job/deploy-wakuv2-prod/).
|
||||
- Deploy release to the `waku.sandbox` fleet from [Jenkins](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/).
|
||||
- Ensure that nodes successfully start up and monitor health using [Grafana](https://grafana.infra.status.im/d/qrp_ZCTGz/nim-waku-v2?orgId=1) and [Kibana](https://kibana.infra.status.im/goto/a7728e70-eb26-11ec-81d1-210eb3022c76).
|
||||
- If necessary, revert by deploying the previous release. Download logs and open a bug report issue.
|
||||
|
||||
### Performing a patch release
|
||||
|
||||
1. Cherry-pick the relevant commits from master to the release branch
|
||||
1. Cherry-pick the relevant commits from master to the release branch
|
||||
|
||||
```
|
||||
git cherry-pick <commit-hash>
|
||||
|
|
|
|||
|
|
@ -1,43 +1,43 @@
|
|||
# Waku v2 fleet: management & monitoring
|
||||
# Waku fleet: management & monitoring
|
||||
|
||||
## Background
|
||||
|
||||
Status currently maintains two fleets for `nwaku` v2 nodes,
|
||||
the `wakuv2.test` fleet and the `wakuv2.prod` (production) fleet.
|
||||
They'll be referred to as `test` and `prod` in this document.
|
||||
Status currently maintains two fleets for `nwaku` nodes,
|
||||
the `waku.test` fleet and the `waku.sandbox` (sandbox) fleet.
|
||||
They'll be referred to as `test` and `sandbox` in this document.
|
||||
Status fleet nodes and addresses can be viewed [here](https://fleets.status.im/).
|
||||
|
||||
### Fleet overview
|
||||
|
||||
At the time of writing this, each fleet consists of three waku v2 nodes,
|
||||
At the time of writing this, each fleet consists of three waku nodes,
|
||||
with a [websockify](https://github.com/novnc/websockify) WebSocket-to-TCP bridge for each node.
|
||||
Waku v2 peers can choose to connect either directly to a node's TCP endpoint
|
||||
Waku peers can choose to connect either directly to a node's TCP endpoint
|
||||
or the bridged WebSocket depending on their own supported transports.
|
||||
The `prod` fleet also has a deployed [`chat2bridge`](https://github.com/waku-org/nwaku/blob/master/docs/tutorial/chat2.md#bridge-messages-between-chat2-and-matterbridge),
|
||||
which serves as a bridge between the [Waku v2 toy-chat](https://rfc.vac.dev/spec/22/) and Matterbridge.
|
||||
The `sandbox` fleet also has a deployed [`chat2bridge`](https://github.com/waku-org/nwaku/blob/master/docs/tutorial/chat2.md#bridge-messages-between-chat2-and-matterbridge),
|
||||
which serves as a bridge between the [Waku toy-chat](https://rfc.vac.dev/spec/22/) and Matterbridge.
|
||||
The `chat2bridge` is currently deployed to the `node-01.do-ams3` datacentre
|
||||
and configured to bridge toy-chat messages to the `#waku channel` on the Vac Discord Server.
|
||||
|
||||
### Fleet deployment rationale
|
||||
|
||||
The `test` fleet is automatically updated after every commit to the `nwaku` repository `master` branch and is therefore the most up to date representation of Waku v2 development.
|
||||
It is suitable for testing new features before they're rolled out to the (more) stable `prod` fleet.
|
||||
The `test` fleet is automatically updated after every commit to the `nwaku` repository `master` branch and is therefore the most up to date representation of Waku development.
|
||||
It is suitable for testing new features before they're rolled out to the (more) stable `sandbox` fleet.
|
||||
|
||||
In general only the latest release of `nwaku` is deployed to the `prod` fleet.
|
||||
In general only the latest release of `nwaku` is deployed to the `sandbox` fleet.
|
||||
It requires manual updating and should therefore be more stable than `test`.
|
||||
See the [section on Jenkins](#jenkins-for-deployment) below for more on the deployment process.
|
||||
|
||||
### Related repos
|
||||
|
||||
The [`infra-docs` repo](https://github.com/status-im/infra-docs) contains the most comprehensive overview of Status infrastructure.
|
||||
This is a private repository.
|
||||
This is a private repository.
|
||||
Feel free to contact someone in the team to request access.
|
||||
|
||||
The [`infra-nim-waku` repo](https://github.com/status-im/infra-nim-waku) contains the infrastructure definitions for Waku nodes implemented in Nim.
|
||||
|
||||
## Monitoring and management
|
||||
|
||||
The rest of this document highlights some infra services of specific interest to Waku v2 fleet monitoring and management:
|
||||
The rest of this document highlights some infra services of specific interest to Waku fleet monitoring and management:
|
||||
|
||||
1. [Consul](https://consul.infra.status.im/ui/do-ams3/services?filter=nim-waku) to view the health status of Waku nodes.
|
||||
2. [Kibana](https://kibana.infra.status.im/app/discover#/) to view and filter logs.
|
||||
|
|
@ -54,13 +54,13 @@ The datacentre can be changed in the upper left-hand corner.
|
|||
### 2. [Kibana](https://kibana.infra.status.im/app/discover#/) for logs
|
||||
|
||||
Kibana is a powerful visualisation tool for Elasticsearch data.
|
||||
For Waku v2 fleets it can be used to retrieve, filter and view the logs for all deployed services.
|
||||
For example, to view the latest logs for `prod`,
|
||||
Kibana can be opened in "Discover" mode with an [active filter for `fleet: wakuv2.prod`](https://kibana.infra.status.im/goto/87fde8e4bba7246ce3780a0c8344f4f0).
|
||||
For Waku fleets it can be used to retrieve, filter and view the logs for all deployed services.
|
||||
For example, to view the latest logs for `sandbox`,
|
||||
Kibana can be opened in "Discover" mode with an [active filter for `fleet: waku.sandbox`](https://kibana.infra.status.im/goto/c0434f60-ca82-11ee-aaa4-85391103106b).
|
||||
|
||||
### 3. [Grafana](https://grafana.infra.status.im/d/qrp_ZCTGz/nim-waku-v2?orgId=1&refresh=5m) for metrics
|
||||
|
||||
The `Nim-Waku V2` Grafana dashboard displays live and historical metrics for Waku v2 nodes.
|
||||
The `Nim-Waku` Grafana dashboard displays live and historical metrics for Waku nodes.
|
||||
The default view includes metrics from both fleets,
|
||||
though it's possible to filter by `Hostname`, `Fleet name` or `Data Center`.
|
||||
The time range can also be configured -
|
||||
|
|
@ -71,7 +71,7 @@ with an overview of the latest connected peers, total messages, CPU usage, repor
|
|||
The _"General"_ collection contains a more in-depth look at node, libp2p and performance-related metrics.
|
||||
This is followed by separate panel collections showing _per-protocol_ metrics.
|
||||
|
||||
A copy of the `Nim-Waku V2` fleets dashboard is maintained in the [`nwaku` repo](https://github.com/waku-org/nwaku/blob/master/metrics/waku-fleet-dashboard.json).
|
||||
A copy of the `Nim-Waku` fleets dashboard is maintained in the [`nwaku` repo](https://github.com/waku-org/nwaku/blob/master/metrics/waku-fleet-dashboard.json).
|
||||
From time to time certain Prometheus queries may fail,
|
||||
often when the underlying metrics are renamed.
|
||||
Please report any broken panels via our Discord channels or by [creating an issue in `nwaku`](https://github.com/waku-org/nwaku/issues/new).
|
||||
|
|
@ -79,8 +79,8 @@ Please report any broken panels via our Discord channels or by [creating an issu
|
|||
### 4. [Jenkins](https://ci.status.im/job/nim-waku/) for deployment
|
||||
|
||||
The [`nim-waku` jobs](https://ci.infra.status.im/job/nim-waku/) on Jenkins are configured to deploy `nwaku` builds to the fleets.
|
||||
1. [`deploy-wakuv2-test`](https://ci.infra.status.im/job/nim-waku/job/deploy-wakuv2-test/) is triggered automatically after every commit to the `nwaku` `master` branch.
|
||||
2. [`deploy-wakuv2-prod`](https://ci.infra.status.im/job/nim-waku/job/deploy-wakuv2-prod/) must be triggered manually. Usually this job is only built after a tagged release in `nwaku`.
|
||||
1. [`deploy-waku-test`](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/) is triggered automatically after every commit to the `nwaku` `master` branch.
|
||||
2. [`deploy-waku-sandbox`](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/) must be triggered manually. Usually this job is only built after a tagged release in `nwaku`.
|
||||
|
||||
Each job can be manually triggered using the _"Build with Parameters"_ option.
|
||||
Options under _"Configure"_ include the build triggers, build target and branches to build.
|
||||
|
|
@ -94,13 +94,14 @@ See [Continuous Integration docs](https://github.com/waku-org/nwaku/blob/master/
|
|||
2. [Consul for do-ams3](https://consul.infra.status.im/ui/do-ams3/services?filter=nim-waku)
|
||||
3. [Consul for ac-cn-hongkong-c](https://consul.infra.status.im/ui/ac-cn-hongkong-c/services?filter=nim-waku)
|
||||
4. [Consul for gc-us-central1-a](https://consul.infra.status.im/ui/gc-us-central1-a/services?filter=nim-waku)
|
||||
5. [Grafana Nim-Waku V2 dashboard](https://grafana.infra.status.im/d/qrp_ZCTGz/nim-waku-v2?orgId=1&refresh=5m)
|
||||
5. [Grafana Nim-Waku dashboard](https://grafana.infra.status.im/d/qrp_ZCTGz/nim-waku-v2?orgId=1&refresh=5m)
|
||||
6. [`infra-docs` repo](https://github.com/status-im/infra-docs)
|
||||
7. [`infra-nim-waku` repo](https://github.com/status-im/infra-nim-waku)
|
||||
7. [`infra-waku` repo](https://github.com/status-im/infra-waku)
|
||||
8. [Jenkins jobs for `nim-waku`](https://ci.infra.status.im/job/nim-waku/)
|
||||
9. [Jenkins deploy-wakuv2-prod manual trigger](https://ci.infra.status.im/job/nim-waku/job/deploy-wakuv2-prod/build)
|
||||
10. [Jenkins deploy-wakuv2-test manual trigger](https://ci.infra.status.im/job/nim-waku/job/deploy-wakuv2-test/build)
|
||||
11. [Kibana logs for `prod`](https://kibana.infra.status.im/goto/87fde8e4bba7246ce3780a0c8344f4f0)
|
||||
12. [Kibana logs for `test`](https://kibana.infra.status.im/goto/fc23759670fd08e9d32e81bb4e58733d)
|
||||
9. [Jenkins deploy-waku-sandbox manual trigger](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/build)
|
||||
10. [Jenkins deploy-waku-test manual trigger](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/build)
|
||||
11. [Kibana logs for `sandbox`](https://kibana.infra.status.im/goto/c0434f60-ca82-11ee-aaa4-85391103106b)
|
||||
12. [Kibana logs for `test`](https://kibana.infra.status.im/goto/7cd22f20-ca83-11ee-aaa4-85391103106b)
|
||||
13. [Status fleets](https://fleets.status.im/)
|
||||
14. [Websockify](https://github.com/novnc/websockify)
|
||||
14. [Status fleets - Table](https://fleets.waku.org)
|
||||
15. [Websockify](https://github.com/novnc/websockify)
|
||||
|
|
|
|||
22
docs/faq.md
22
docs/faq.md
|
|
@ -4,21 +4,31 @@
|
|||
|
||||
Grep for "Listening on". It should be printed at INFO level at the beginning. E.g. from Kibana:
|
||||
|
||||
`Oct 7, 2020 @ 23:17:00.383INF 2020-10-07 23:17:00.375+00:00 Listening on topics="wakunode" tid=1 file=wakunode2.nim:140 full=/ip4/0.0.0.0/tcp/60000/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS`
|
||||
`Oct 7, 2020 @ 23:17:00.383INF 2020-10-07 23:17:00.375+00:00 Listening on topics="wakunode" tid=1 file=wakunode2.nim:140 full=/ip4/0.0.0.0/tcp/60000/p2p/16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp`
|
||||
|
||||
## How do I find out node addresses at the test cluster?
|
||||
|
||||
The easiest way is to use `jq` and query the fleets registry that Status operates:
|
||||
|
||||
```
|
||||
curl -s https://fleets.status.im | jq '.fleets["wakuv2.test"]'
|
||||
curl -s https://fleets.status.im | jq '.fleets["waku.test"]'
|
||||
|
||||
# Output
|
||||
{
|
||||
"waku": {
|
||||
"node-01.ac-cn-hongkong-c.wakuv2.test": "/ip4/0.0.0.0/tcp/30303/p2p/16Uiu2HAmSyrYVycqBCWcHyNVQS6zYQcdQbwyov1CDijboVRsQS37",
|
||||
"node-01.do-ams3.wakuv2.test": "/ip4/0.0.0.0/tcp/30303/p2p/16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ",
|
||||
"node-01.gc-us-central1-a.wakuv2.test": "/ip4/0.0.0.0/tcp/30303/p2p/16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ"
|
||||
"tcp/p2p/waku": {
|
||||
"node-01.do-ams3.waku.test": "/dns4/node-01.do-ams3.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W",
|
||||
"node-01.gc-us-central1-a.waku.test": "/dns4/node-01.gc-us-central1-a.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAmDCp8XJ9z1ev18zuv8NHekAsjNyezAvmMfFEJkiharitG",
|
||||
"node-01.ac-cn-hongkong-c.waku.test": "/dns4/node-01.ac-cn-hongkong-c.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp"
|
||||
},
|
||||
"enr/p2p/waku": {
|
||||
"node-01.do-ams3.waku.test": "enr:-QESuEC1p_s3xJzAC_XlOuuNrhVUETmfhbm1wxRGis0f7DlqGSw2FM-p2Ugl_r25UHQJ3f1rIRrpzxJXSMaJe4yk1XFSAYJpZIJ2NIJpcISygI2rim11bHRpYWRkcnO4XAArNiZub2RlLTAxLmRvLWFtczMud2FrdS50ZXN0LnN0YXR1c2ltLm5ldAZ2XwAtNiZub2RlLTAxLmRvLWFtczMud2FrdS50ZXN0LnN0YXR1c2ltLm5ldAYfQN4DgnJzkwABCAAAAAEAAgADAAQABQAGAAeJc2VjcDI1NmsxoQJATXRSRSUyTw_QLB6H_U3oziVQgNRgrXpK7wp2AMyNxYN0Y3CCdl-DdWRwgiMohXdha3UyDw",
|
||||
"node-01.gc-us-central1-a.waku.test": "enr:-QEkuECnZ3IbVAgkOzv-QLnKC4dRKAPRY80m1-R7G8jZ7yfT3ipEfBrhKN7ARcQgQ-vg-h40AQzyvAkPYlHPaFKk6u9uAYJpZIJ2NIJpcIQiEAFDim11bHRpYWRkcnO4bgA0Ni9ub2RlLTAxLmdjLXVzLWNlbnRyYWwxLWEud2FrdS50ZXN0LnN0YXR1c2ltLm5ldAZ2XwA2Ni9ub2RlLTAxLmdjLXVzLWNlbnRyYWwxLWEud2FrdS50ZXN0LnN0YXR1c2ltLm5ldAYfQN4DgnJzkwABCAAAAAEAAgADAAQABQAGAAeJc2VjcDI1NmsxoQMIJwesBVgUiBCi8yiXGx7RWylBQkYm1U9dvEy-neLG2YN0Y3CCdl-DdWRwgiMohXdha3UyDw",
|
||||
"node-01.ac-cn-hongkong-c.waku.test": "enr:-QEkuEDzQyIAhs-CgBHIrJqtBv3EY1uP1Psrc-y8yJKsmxW7dh3DNcq2ergMUWSFVcJNlfcgBeVsFPkgd_QopRIiCV2pAYJpZIJ2NIJpcIQI2ttrim11bHRpYWRkcnO4bgA0Ni9ub2RlLTAxLmFjLWNuLWhvbmdrb25nLWMud2FrdS50ZXN0LnN0YXR1c2ltLm5ldAZ2XwA2Ni9ub2RlLTAxLmFjLWNuLWhvbmdrb25nLWMud2FrdS50ZXN0LnN0YXR1c2ltLm5ldAYfQN4DgnJzkwABCAAAAAEAAgADAAQABQAGAAeJc2VjcDI1NmsxoQJIN4qwz3v4r2Q8Bv8zZD0eqBcKw6bdLvdkV7-JLjqIj4N0Y3CCdl-DdWRwgiMohXdha3UyDw"
|
||||
},
|
||||
"wss/p2p/waku": {
|
||||
"node-01.do-ams3.waku.test": "/dns4/node-01.do-ams3.waku.test.statusim.net/tcp/8000/wss/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W",
|
||||
"node-01.gc-us-central1-a.waku.test": "/dns4/node-01.gc-us-central1-a.waku.test.statusim.net/tcp/8000/wss/p2p/16Uiu2HAmDCp8XJ9z1ev18zuv8NHekAsjNyezAvmMfFEJkiharitG",
|
||||
"node-01.ac-cn-hongkong-c.waku.test": "/dns4/node-01.ac-cn-hongkong-c.waku.test.statusim.net/tcp/8000/wss/p2p/16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -58,13 +58,13 @@ As an example, consider the following command to run nwaku in a Docker container
|
|||
```bash
|
||||
docker run -i -t -p 60000:60000 -p 9000:9000/udp wakuorg/nwaku:v0.20.0 \
|
||||
--dns-discovery:true \
|
||||
--dns-discovery-url:enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im \
|
||||
--dns-discovery-url:enrtree://AIRVQ5DDA4FFWLRBCHJWUWOO6X6S4ZTZ5B667LQ6AJU6PEYDLRD5O@sandbox.waku.nodes.status.im \
|
||||
--discv5-discovery \
|
||||
--nat:extip:[yourpublicip] # or, if you are behind a nat: --nat=any
|
||||
```
|
||||
|
||||
This runs nwaku in a new container from the `wakuorg/nwaku:v0.20.0` image,
|
||||
connects to `wakuv2.prod` as bootstrap fleet and
|
||||
connects to `wakuv.sandbox` as bootstrap fleet and
|
||||
enables [Waku Discovery v5](https://rfc.vac.dev/spec/33/) for ambient peer discovery,
|
||||
while mapping the default libp2p listening port (`60000`)
|
||||
and default discv5 UDP port (`9000`) to the host.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Quickstart for running nwaku on a DigitalOcean Droplet
|
||||
|
||||
This guide explains how to run a nwaku node on a
|
||||
This guide explains how to run a nwaku node on a
|
||||
DigitalOcean Droplet. We enable the following protocols -
|
||||
|
||||
1. Relay
|
||||
|
|
@ -10,9 +10,9 @@ DigitalOcean Droplet. We enable the following protocols -
|
|||
|
||||
A Droplet is a simple virtual machine that runs in DigitalOcean's datacenters.
|
||||
|
||||
Note that Droplets do cost money, the size described in the guide costs approximately $12 a month.
|
||||
Note that Droplets do cost money, the size described in the guide costs approximately $12 a month.
|
||||
|
||||
The guide makes heavy use of the `doctl` cli to make it as UI agnostic as possible.
|
||||
The guide makes heavy use of the `doctl` cli to make it as UI agnostic as possible.
|
||||
There are similar steps to accomplish the same through DigitalOcean's cloud console, accessible [here](https://cloud.digitalocean.com/)
|
||||
|
||||
## Prerequisites
|
||||
|
|
@ -238,7 +238,7 @@ Run the following command to run `nwaku` -
|
|||
|
||||
*Note the path to the wakunode2 binary*
|
||||
|
||||
a. Add the parent directory of the wakunode2 binary to your environment:
|
||||
a. Add the parent directory of the wakunode2 binary to your environment:
|
||||
|
||||
If you built it locally and copied it via scp -
|
||||
|
||||
|
|
@ -255,8 +255,8 @@ a. Add the parent directory of the wakunode2 binary to your environment:
|
|||
```
|
||||
|
||||
b. Choose the fleet you wish to connect your node to:
|
||||
- waku prod: enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im
|
||||
- waku test: enrtree://AO47IDOLBKH72HIZZOXQP6NMRESAN7CHYWIBNXDXWRJRZWLODKII6@test.wakuv2.nodes.status.im
|
||||
- waku sandbox: enrtree://AIRVQ5DDA4FFWLRBCHJWUWOO6X6S4ZTZ5B667LQ6AJU6PEYDLRD5O@sandbox.waku.nodes.status.im
|
||||
- waku test: enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im
|
||||
|
||||
```bash
|
||||
export WAKU_FLEET=<fleet>
|
||||
|
|
@ -293,7 +293,7 @@ c. Run `nwaku`:
|
|||
|
||||
You now have nwaku running! You can verify this by observing the logs. The logs should show that the node completed 7 steps of setup, and is actively discovering other nodes.
|
||||
|
||||
You may now detach from stdout, by following instructions according to the terminal multiplexer chosen previously -
|
||||
You may now detach from stdout, by following instructions according to the terminal multiplexer chosen previously -
|
||||
1. [screen](https://linuxize.com/post/how-to-use-linux-screen/#detach-from-linux-screen-session)
|
||||
2. [tmux](https://linuxize.com/post/getting-started-with-tmux/#starting-your-first-tmux-session)
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ A node will attempt connection to all discovered nodes.
|
|||
|
||||
This can be used, for example, to connect to one of the existing fleets.
|
||||
Current URLs for the published fleet lists:
|
||||
- production fleet: `enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im`
|
||||
- test fleet: `enrtree://AO47IDOLBKH72HIZZOXQP6NMRESAN7CHYWIBNXDXWRJRZWLODKII6@test.wakuv2.nodes.status.im`
|
||||
- production fleet: `enrtree://AIRVQ5DDA4FFWLRBCHJWUWOO6X6S4ZTZ5B667LQ6AJU6PEYDLRD5O@sandbox.waku.nodes.status.im`
|
||||
- test fleet: `enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im`
|
||||
|
||||
See the [separate tutorial](../../tutorial/dns-disc.md) for a complete guide to DNS discovery.
|
||||
See the [separate tutorial](../../tutorial/dns-disc.md) for a complete guide to DNS discovery.
|
||||
|
|
|
|||
|
|
@ -17,12 +17,12 @@ or store and serve historical messages itself.
|
|||
|
||||
Ensure that `store` is enabled (this is `true` by default) and provide at least one store service node address with the `--storenode` CLI option.
|
||||
|
||||
See the following example, using the peer at `/dns4/node-01.ac-cn-hongkong-c.wakuv2.test.statusim.net/tcp/30303/p2p/16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm` as store service node.
|
||||
See the following example, using the peer at `/dns4/node-01.ac-cn-hongkong-c.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp` as store service node.
|
||||
|
||||
```sh
|
||||
./build/wakunode2 \
|
||||
--store:true \
|
||||
--storenode:/dns4/node-01.ac-cn-hongkong-c.wakuv2.test.statusim.net/tcp/30303/p2p/16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm
|
||||
--storenode:/dns4/node-01.ac-cn-hongkong-c.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp
|
||||
```
|
||||
|
||||
Your node can now send queries to retrieve historical messages
|
||||
|
|
@ -53,4 +53,4 @@ implying a minimum memory requirement of at least ~250MB
|
|||
for a medium capacity store of 100k messages.
|
||||
Note, however, that the allowable maximum size for Waku messages is up to 1MB.
|
||||
We are working on a disk-only and hybrid store to lower the memory requirement.
|
||||
It will soon also be possible to configure store capacity on maximum store size or number of days' history to keep.
|
||||
It will soon also be possible to configure store capacity on maximum store size or number of days' history to keep.
|
||||
|
|
|
|||
|
|
@ -15,11 +15,11 @@ This option controls the mounting of the Waku Store protocol, meaning that your
|
|||
|
||||
Provide at least one store service node address with the `--storenode` option. This option is independent of the `--store` option i.e., one node can act as a waku store client without mounting the Waku Store protocol.
|
||||
|
||||
For example, to use the peer at `/dns4/node-01.ac-cn-hongkong-c.wakuv2.test.statusim.net/tcp/30303/p2p/16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm` as the waku store service node:
|
||||
For example, to use the peer at `/dns4/node-01.ac-cn-hongkong-c.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp` as the waku store service node:
|
||||
|
||||
```shell
|
||||
wakunode2 \
|
||||
--storenode=/dns4/node-01.ac-cn-hongkong-c.wakuv2.test.statusim.net/tcp/30303/p2p/16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm
|
||||
--storenode=/dns4/node-01.ac-cn-hongkong-c.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp
|
||||
```
|
||||
|
||||
Your node can now send queries to retrieve historical messages
|
||||
|
|
@ -41,7 +41,7 @@ There is a set of configuration options to customize the waku store protocol's m
|
|||
+ SQLite engine: The only database engine supported by the nwaku node. The database URL has this shape: `sqlite://<database-file-path>`. If the `<database-file-path>` is not an absolute path (preceded by a `/` character), the file will be created in the current working directory. The SQLite engine also supports to select a non-persistent in-memory database by setting the `<database-file-path>` to `:memory:`.
|
||||
+ In the case you don't want to use a persistent message store; set the `--store-message-db-url` to an empty string, `""`. This will instruct the node to use the fallback in-memory message store.
|
||||
|
||||
By default the node message store will be configured with a time retention policy set to `14400` seconds (4 hours). Additionally, by default, the node message store will use the SQLite database engine to store historical messages in order to persist these between restarts.
|
||||
By default the node message store will be configured with a time retention policy set to `14400` seconds (4 hours). Additionally, by default, the node message store will use the SQLite database engine to store historical messages in order to persist these between restarts.
|
||||
|
||||
> :warning: Note the 3 slashes, `///`, after the SQLite database URL schema. The third slash indicates that it is an absolute path: `/mnt/nwaku/data/db1/store.sqlite3`
|
||||
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ We include an example below.
|
|||
This is another useful option when running several nwaku instances on a single machine
|
||||
and would like to avoid port clashes without manually configuring each port.
|
||||
|
||||
### Connecting to the `wakuv2.prod` network
|
||||
### Connecting to the `waku.sandbox` network
|
||||
|
||||
*See [this explainer](https://github.com/status-im/nwaku/blob/6ebe26ad0587d56a87a879d89b7328f67f048911/docs/contributors/waku-fleets.md) on the different networks and Waku v2 fleets.*
|
||||
|
||||
|
|
@ -150,11 +150,11 @@ Discovery v5 will attempt to extract the ENRs of the discovered nodes as bootstr
|
|||
./build/wakunode2 \
|
||||
--ports-shift:1 \
|
||||
--dns-discovery:true \
|
||||
--dns-discovery-url:enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im \
|
||||
--dns-discovery-url:enrtree://AIRVQ5DDA4FFWLRBCHJWUWOO6X6S4ZTZ5B667LQ6AJU6PEYDLRD5O@sandbox.waku.nodes.status.im \
|
||||
--discv5-discovery:true
|
||||
```
|
||||
|
||||
### Connecting to the `wakuv2.test` network
|
||||
### Connecting to the `waku.test` network
|
||||
|
||||
*See [this explainer](https://github.com/status-im/nwaku/blob/6ebe26ad0587d56a87a879d89b7328f67f048911/docs/contributors/waku-fleets.md) on the different networks and Waku v2 fleets.*
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ Discovery v5 will attempt to extract the ENRs of the discovered nodes as bootstr
|
|||
./build/wakunode2 \
|
||||
--ports-shift:1 \
|
||||
--dns-discovery:true \
|
||||
--dns-discovery-url:enrtree://AO47IDOLBKH72HIZZOXQP6NMRESAN7CHYWIBNXDXWRJRZWLODKII6@test.wakuv2.nodes.status.im \
|
||||
--dns-discovery-url:enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im \
|
||||
--discv5-discovery:true
|
||||
```
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ Discovery v5 will attempt to extract the ENRs of the discovered nodes as bootstr
|
|||
Often nwaku nodes choose to also store historical messages
|
||||
from where it can be queried by other peers who may have been temporarily offline.
|
||||
For example, a typical configuration for such a store service node,
|
||||
[connecting to the `wakuv2.test`](#connecting-to-the-wakuv2test-fleet) fleet on startup,
|
||||
[connecting to the `waku.test`](#connecting-to-the-wakutest-network) fleet on startup,
|
||||
appears below.
|
||||
|
||||
```sh
|
||||
|
|
@ -185,7 +185,7 @@ appears below.
|
|||
--db-path:/mnt/nwaku/data/db1/ \
|
||||
--store-capacity:150000 \
|
||||
--dns-discovery:true \
|
||||
--dns-discovery-url:enrtree://AO47IDOLBKH72HIZZOXQP6NMRESAN7CHYWIBNXDXWRJRZWLODKII6@test.wakuv2.nodes.status.im \
|
||||
--dns-discovery-url:enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im \
|
||||
--discv5-discovery:true
|
||||
```
|
||||
|
||||
|
|
@ -193,4 +193,4 @@ See our [store configuration tutorial](./configure-store.md) for more.
|
|||
|
||||
## Interact with a running nwaku node
|
||||
|
||||
A running nwaku node can be interacted with using the [REST API](https://github.com/waku-org/nwaku/blob/master/docs/api/rest-api.md).
|
||||
A running nwaku node can be interacted with using the [REST API](https://github.com/waku-org/nwaku/blob/master/docs/api/rest-api.md).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Quickstart: running a nwaku node
|
||||
|
||||
This guide helps you run a nwaku node with typical configuration.
|
||||
It connects your node to the `wakuv2.prod` fleet for bootstrapping
|
||||
It connects your node to the `waku.sandbox` fleet for bootstrapping
|
||||
and enables discovery v5 for continuous peer discovery.
|
||||
Only [`relay`](https://rfc.vac.dev/spec/11/) protocol is enabled.
|
||||
For a more comprehensive overview,
|
||||
|
|
@ -18,7 +18,7 @@ cd nwaku
|
|||
make wakunode2
|
||||
./build/wakunode2 \
|
||||
--dns-discovery:true \
|
||||
--dns-discovery-url:enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im \
|
||||
--dns-discovery-url:enrtree://AIRVQ5DDA4FFWLRBCHJWUWOO6X6S4ZTZ5B667LQ6AJU6PEYDLRD5O@sandbox.waku.nodes.status.im \
|
||||
--discv5-discovery \
|
||||
--nat=extip:[yourpublicip] # or, if you are behind a nat: --nat=any
|
||||
```
|
||||
|
|
@ -31,7 +31,7 @@ make wakunode2
|
|||
docker run -i -t -p 60000:60000 -p 9000:9000/udp \
|
||||
wakuorg/nwaku:v0.20.0 \ # or, the image:tag of your choice
|
||||
--dns-discovery:true \
|
||||
--dns-discovery-url:enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im \
|
||||
--dns-discovery-url:enrtree://AIRVQ5DDA4FFWLRBCHJWUWOO6X6S4ZTZ5B667LQ6AJU6PEYDLRD5O@sandbox.waku.nodes.status.im \
|
||||
--discv5-discovery \
|
||||
--nat:extip:[yourpublicip] # or, if you are behind a nat: --nat=any
|
||||
```
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
The `chat2` application is a basic command-line chat app using the [Waku v2 suite of protocols](https://rfc.vac.dev/).
|
||||
It optionally connects to a [fleet of nodes](fleets.status.im) to provide end-to-end p2p chat capabilities.
|
||||
Each fleet is a publicly accessible network of Waku v2 peers, providing a bootstrap connection point for new peers, historical message storage, etc.
|
||||
The Waku team is currently using this application on the _production_ fleet for internal testing.
|
||||
The Waku team is currently using this application on the _sandbox_ fleet for internal testing.
|
||||
For more information on the available fleets, see [`Connecting to a Waku v2 fleet`](#connecting-to-a-waku-v2-fleet).
|
||||
If you want to try our protocols, or join the dogfooding fun, follow the instructions below.
|
||||
|
||||
|
|
@ -33,16 +33,16 @@ You should be prompted to provide a nickname for the chat session.
|
|||
Choose a nickname >>
|
||||
```
|
||||
|
||||
After entering a nickname, the app will randomly select and connect to a peer from the `prod` fleet.
|
||||
After entering a nickname, the app will randomly select and connect to a peer from the `sandbox` fleet.
|
||||
|
||||
```
|
||||
No static peers configured. Choosing one at random from prod fleet...
|
||||
No static peers configured. Choosing one at random from sandbox fleet...
|
||||
```
|
||||
|
||||
It will then attempt to download historical messages from a random peer in the `prod` fleet.
|
||||
It will then attempt to download historical messages from a random peer in the `sandbox` fleet.
|
||||
|
||||
```
|
||||
Store enabled, but no store nodes configured. Choosing one at random from prod fleet...
|
||||
Store enabled, but no store nodes configured. Choosing one at random from sandbox fleet...
|
||||
```
|
||||
|
||||
Wait for the chat prompt (`>>`) and chat away!
|
||||
|
|
@ -60,10 +60,10 @@ The `chat2` application can retrieve historical chat messages from a node suppor
|
|||
It's possible to query a *specific* store node by configuring its `multiaddr` as `storenode` when starting the app:
|
||||
|
||||
```
|
||||
./build/chat2 --storenode:/ip4/134.209.139.210/tcp/30303/p2p/16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ
|
||||
./build/chat2 --storenode:/dns4/node-01.do-ams3.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W
|
||||
```
|
||||
|
||||
Alternatively, the `chat2` application will select a random `storenode` for you from the configured fleet (`prod` by default) if `storenode` is left unspecified.
|
||||
Alternatively, the `chat2` application will select a random `storenode` for you from the configured fleet (`sandbox` by default) if `storenode` is left unspecified.
|
||||
|
||||
```
|
||||
./build/chat2
|
||||
|
|
@ -80,7 +80,7 @@ To disable historical message retrieval, use the `--store:false` option:
|
|||
In order to connect to a *specific* node as [`relay`](https://rfc.vac.dev/spec/11/) peer, define that node's `multiaddr` as a `staticnode` when starting the app:
|
||||
|
||||
```
|
||||
./build/chat2 --staticnode:/ip4/134.209.139.210/tcp/30303/p2p/16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ
|
||||
./build/chat2 --staticnode:/dns4/node-01.do-ams3.waku.test.statusim.net/tcp/30303/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W
|
||||
```
|
||||
|
||||
This will bypass the random peer selection process and connect to the specified node.
|
||||
|
|
@ -93,11 +93,11 @@ It is possible to specify a specific Waku v2 fleet to connect to when starting t
|
|||
./build/chat2 --fleet:test
|
||||
```
|
||||
|
||||
There are currently two fleets to select from, namely _production_ (`wakuv2.prod`) and _test_ (`wakuv2.test`).
|
||||
There are currently two fleets to select from, namely _sandbox_ (`waku.sandbox`) and _test_ (`waku.test`).
|
||||
The `test` fleet is updated with each incremental change to the `nim-waku` codebase.
|
||||
As a result it may have more advanced and experimental features, but will be less stable than `prod`.
|
||||
The `prod` fleet is a deployed network of the latest released Waku v2 nodes.
|
||||
If no `fleet` is specified, `chat2` will connect to the `prod` fleet by default.
|
||||
As a result it may have more advanced and experimental features, but will be less stable than `sandbox`.
|
||||
The `sandbox` fleet is a deployed network of the latest released Waku v2 nodes.
|
||||
If no `fleet` is specified, `chat2` will connect to the `sandbox` fleet by default.
|
||||
To start `chat2` without connecting to a fleet, use the `--fleet:none` option _or_ [specify a static peer](#specifying-a-static-peer).
|
||||
|
||||
## Specifying a content topic
|
||||
|
|
@ -108,7 +108,7 @@ To publish chat messages on a specific [content topic](https://rfc.vac.dev/spec/
|
|||
./build/chat2 --content-topic:/waku/2/my-content-topic/proto
|
||||
```
|
||||
|
||||
> **NOTE:** Currently (2021/05/26) the content topic defaults to `/waku/2/huilong/proto` if left unspecified, where `huilong` is the name of our latest testnet.
|
||||
> **NOTE:** Currently (2021/05/26) the content topic defaults to `/waku/2/huilong/proto` if left unspecified, where `huilong` is the name of our latest testnet.
|
||||
|
||||
## In-chat options
|
||||
|
||||
|
|
@ -153,7 +153,7 @@ Follow the matterbridge [Discord instructions](https://github.com/42wim/matterbr
|
|||
|
||||
# You can get your token by following the instructions on
|
||||
# https://github.com/42wim/matterbridge/wiki/Discord-bot-setup.
|
||||
# If you want roles/groups mentions to be shown with names instead of ID,
|
||||
# If you want roles/groups mentions to be shown with names instead of ID,
|
||||
# you'll need to give your bot the "Manage Roles" permission.
|
||||
Token="MTk4NjIyNDgzNDcdOTI1MjQ4.Cl2FMZ.ZnCjm1XVW7vRze4b7Cq4se7kKWs-abD"
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
> TODO (2023-05-24): Deprecate or fix
|
||||
|
||||
*NOTE: Some of these addresses might change. To get the latest, please see `curl -s https://fleets.status.im | jq '.fleets["wakuv2.test"]'`*
|
||||
*NOTE: Some of these addresses might change. To get the latest, please see `curl -s https://fleets.status.im | jq '.fleets["waku.test"]'`*
|
||||
|
||||
## Basic chat usage
|
||||
|
||||
|
|
@ -11,8 +11,8 @@
|
|||
Start two chat apps:
|
||||
|
||||
```
|
||||
./build/chat2 --ports-shift:0 --storenode:/ip4/134.209.139.210/tcp/60000/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS --staticnode:/ip4/134.209.139.210/tcp/60000/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS
|
||||
./build/chat2 --ports-shift:1 --storenode:/ip4/134.209.139.210/tcp/60000/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS --staticnode:/ip4/134.209.139.210/tcp/60000/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS
|
||||
./build/chat2 --ports-shift:0 --storenode:/ip4/178.128.141.171/tcp/60000/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W --staticnode:/ip4/178.128.141.171/tcp/60000/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W
|
||||
./build/chat2 --ports-shift:1 --storenode:/ip4/178.128.141.171/tcp/60000/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W --staticnode:/ip4/178.128.141.171/tcp/60000/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W
|
||||
```
|
||||
|
||||
By specifying `staticnode` it connects to that node subscribes to the `waku` topic. This ensures messages are relayed properly.
|
||||
|
|
@ -25,9 +25,7 @@ There is also an interactive mode. Type `/connect` then paste address of other n
|
|||
|
||||
## Dingpu cluster node
|
||||
|
||||
```
|
||||
/ip4/134.209.139.210/tcp/60000/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS
|
||||
```
|
||||
> TODO (2024-03-11): Fix node multiaddr
|
||||
|
||||
## Run a node
|
||||
|
||||
|
|
|
|||
|
|
@ -42,30 +42,30 @@ The following command line options are available for both `wakunode2` or `chat2`
|
|||
|
||||
A node will attempt connection to all discovered nodes.
|
||||
|
||||
## Example for `wakuv2.test` fleet
|
||||
## Example for `waku.test` fleet
|
||||
|
||||
To illustrate the above and prove the concept,
|
||||
a list of `wakuv2.test` fleet nodes was encoded according to EIP-1459 and deployed to `test.nodes.vac.dev`.
|
||||
The list was signed by the public key `AOFTICU2XWDULNLZGRMQS4RIZPAZEHYMV4FYHAPW563HNRAOERP7C`.
|
||||
The complete URL for DNS discovery is therefore: `enrtree://AOFTICU2XWDULNLZGRMQS4RIZPAZEHYMV4FYHAPW563HNRAOERP7C@test.nodes.vac.dev`.
|
||||
a list of `waku.test` fleet nodes was encoded according to EIP-1459 and deployed to `test.waku.nodes.status.im`.
|
||||
The list was signed by the public key `AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI`.
|
||||
The complete URL for DNS discovery is therefore: `enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im`.
|
||||
|
||||
To run a `wakunode2` with DNS-based discovery of `wakuv2.test` nodes:
|
||||
To run a `wakunode2` with DNS-based discovery of `waku.test` nodes:
|
||||
|
||||
```
|
||||
./build/wakunode2 --dns-discovery:true --dns-discovery-url:enrtree://AOFTICU2XWDULNLZGRMQS4RIZPAZEHYMV4FYHAPW563HNRAOERP7C@test.nodes.vac.dev
|
||||
./build/wakunode2 --dns-discovery:true --dns-discovery-url:enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im
|
||||
```
|
||||
|
||||
Similarly, for `chat2`:
|
||||
|
||||
```
|
||||
./build/chat2 --dns-discovery:true --dns-discovery-url:enrtree://AOFTICU2XWDULNLZGRMQS4RIZPAZEHYMV4FYHAPW563HNRAOERP7C@test.nodes.vac.dev
|
||||
./build/chat2 --dns-discovery:true --dns-discovery-url:enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im
|
||||
```
|
||||
|
||||
The node will discover and attempt connection to all `wakuv2.test` nodes during setup procedures.
|
||||
The node will discover and attempt connection to all `waku.test` nodes during setup procedures.
|
||||
|
||||
To use specific DNS name servers, one or more `--dns-discovery-name-server` arguments can be added:
|
||||
|
||||
```
|
||||
./build/wakunode2 --dns-discovery:true --dns-discovery-url:enrtree://AOFTICU2XWDULNLZGRMQS4RIZPAZEHYMV4FYHAPW563HNRAOERP7C@test.nodes.vac.dev --dns-dis
|
||||
./build/wakunode2 --dns-discovery:true --dns-discovery-url:enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im --dns-dis
|
||||
covery-name-server:8.8.8.8 --dns-discovery-name-server:8.8.4.4
|
||||
```
|
||||
|
|
|
|||
|
|
@ -39,6 +39,4 @@ You should see other node receive something.
|
|||
|
||||
## Nangang cluster node
|
||||
|
||||
```
|
||||
/ip4/134.209.139.210/tcp/60000/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS
|
||||
```
|
||||
> TODO (2024-03-11): Fix node multiaddr
|
||||
|
|
|
|||
|
|
@ -6,20 +6,20 @@ Members can be dynamically added to the group and the group size can grow up to
|
|||
This differs from the prior test scenarios in which the RLN group was static and the set of members' keys was hardcoded and fixed.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
To complete this tutorial, you will need
|
||||
## Prerequisites
|
||||
To complete this tutorial, you will need
|
||||
|
||||
1. An rln keystore file with credentials to the rln membership smart contract you wish to use. You may obtain this by registering to the smart contract and generating a keystore, or by using the [rln-keystore-generator](./rln-keystore-generator.md) which does that for you.
|
||||
|
||||
|
||||
## Overview
|
||||
Figure 1 provides an overview of the interaction of the chat2 clients with the test fleets and the membership contract.
|
||||
Figure 1 provides an overview of the interaction of the chat2 clients with the test fleets and the membership contract.
|
||||
At a high level, when a chat2 client is run with Waku-RLN-Relay mounted in on-chain mode.
|
||||
|
||||
Under the hood, the chat2 client constantly listens to the membership contract and keeps itself updated with the latest state of the group.
|
||||
|
||||
In the following test setting, the chat2 clients are to be connected to the Waku test fleets as their first hop.
|
||||
The test fleets will act as routers and are also set to run Waku-RLN-Relay over the same pubsub topic and content topic as chat2 clients i.e., the default pubsub topic of `/waku/2/default-waku/proto` and the content topic of `/toy-chat/3/mingde/proto`.
|
||||
In the following test setting, the chat2 clients are to be connected to the Waku test fleets as their first hop.
|
||||
The test fleets will act as routers and are also set to run Waku-RLN-Relay over the same pubsub topic and content topic as chat2 clients i.e., the default pubsub topic of `/waku/2/default-waku/proto` and the content topic of `/toy-chat/3/mingde/proto`.
|
||||
Spam messages published on the said combination of topics will be caught by the test fleet nodes and will not be routed.
|
||||
Note that spam protection does not rely on the presence of the test fleets.
|
||||
In fact, all the chat2 clients are also capable of catching and dropping spam messages if they receive any.
|
||||
|
|
@ -30,7 +30,7 @@ You can test it by connecting two chat2 clients (running Waku-RLN-Relay) directl
|
|||
|
||||
# Set up
|
||||
## Build chat2
|
||||
First, build chat2
|
||||
First, build chat2
|
||||
|
||||
```bash
|
||||
make chat2
|
||||
|
|
@ -38,7 +38,7 @@ make chat2
|
|||
|
||||
## Set up a chat2 client
|
||||
|
||||
Run the following command to set up your chat2 client.
|
||||
Run the following command to set up your chat2 client.
|
||||
|
||||
```bash
|
||||
./build/chat2 --fleet:test \
|
||||
|
|
@ -49,7 +49,7 @@ Run the following command to set up your chat2 client.
|
|||
--rln-relay-cred-path:xxx/xx/rlnKeystore.json \
|
||||
--rln-relay-cred-password:xxxx \
|
||||
--rln-relay-eth-client-address:xxxx \
|
||||
--ports-shift:1
|
||||
--ports-shift:1
|
||||
```
|
||||
|
||||
In this command
|
||||
|
|
@ -62,7 +62,7 @@ In this command
|
|||
You may check the state of the contract on the [Sepolia testnet](https://sepolia.etherscan.io/address/0xF471d71E9b1455bBF4b85d475afb9BB0954A29c4).
|
||||
- the `--rln-relay-cred-path` option denotes the path to the keystore file described above
|
||||
- the `--rln-relay-cred-password` option denotes the password to the keystore
|
||||
- the `rln-relay-eth-client-address` is the WebSocket address of the hosted node on the Sepolia testnet.
|
||||
- the `rln-relay-eth-client-address` is the WebSocket address of the hosted node on the Sepolia testnet.
|
||||
You need to replace the `xxxx` with the actual node's address.
|
||||
|
||||
For `rln-relay-eth-client-address`, if you do not know how to obtain it, you may use the following tutorial on the [prerequisites of running on-chain spam-protected chat2](./pre-requisites-of-running-on-chain-spam-protected-chat2.md).
|
||||
|
|
@ -79,11 +79,11 @@ then you will see a couple of other messages related to setting up the connectio
|
|||
the content may differ on your screen though:
|
||||
```
|
||||
Connecting to test fleet using DNS discovery...
|
||||
Discovered and connecting to @[16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm, 16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ, 16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS]
|
||||
Discovered and connecting to @[16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp, 16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W, 16Uiu2HAmDCp8XJ9z1ev18zuv8NHekAsjNyezAvmMfFEJkiharitG]
|
||||
Listening on
|
||||
/ip4/75.157.120.249/tcp/60001/p2p/16Uiu2HAmQXuZmbjFWGagthwVsPFrc5ZrZ9c53qdUA45TWoZaokQn
|
||||
Store enabled, but no store nodes configured. Choosing one at random from discovered peers
|
||||
Connecting to storenode: 16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm
|
||||
Connecting to storenode: 16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp
|
||||
```
|
||||
You will also see some historical messages being fetched, again the content may be different on your end:
|
||||
|
||||
|
|
@ -124,18 +124,18 @@ Once you type a chat line and hit enter, you will see a message that indicates t
|
|||
<Jul 26, 12:55> Alice: Hi
|
||||
```
|
||||
The numerical value `165886530` indicates the epoch of the message `Hi`.
|
||||
You will see a different value than `165886530` on your screen.
|
||||
You will see a different value than `165886530` on your screen.
|
||||
If two messages sent by the same chat2 client happen to have the same RLN epoch value, then one of them will be detected as spam and won't be routed (by test fleets in this test setting).
|
||||
At the time of this tutorial, the epoch duration is set to `10` seconds.
|
||||
You can inspect the current epoch value by checking the following [constant variable](https://github.com/waku-org/nwaku/blob/44c543129ee4149255a00a05f1e7d21f8fa28626/waku/v2/waku_rln_relay/constants.nim#L51) in the nim-waku codebase.
|
||||
Thus, if you send two messages less than `10` seconds apart, they are likely to get the same `rln epoch` values.
|
||||
|
||||
After sending a chat message, you may experience some delay before the next chat prompt appears.
|
||||
After sending a chat message, you may experience some delay before the next chat prompt appears.
|
||||
The reason is that under the hood a zero-knowledge proof is being generated and attached to your message.
|
||||
|
||||
|
||||
Try to spam the network by violating the message rate limit i.e.,
|
||||
sending more than one message per epoch.
|
||||
sending more than one message per epoch.
|
||||
Your messages will be routed via test fleets that are running in spam-protected mode over the same content topic i.e., `/toy-chat/3/mingde/proto` as your chat client.
|
||||
Your spam activity will be detected by them and your message will not reach the rest of the chat clients.
|
||||
You can check this by running a second chat user and verifying that spam messages are not displayed as they are filtered by the test fleets.
|
||||
|
|
@ -158,26 +158,26 @@ Note that the value used for `rln-relay-eth-client-address` in the following cod
|
|||
|
||||
The two chat clients namely `Alice` and `Bob` are connected to the test fleets.
|
||||
`Alice` sends 4 messages i.e., `message1`, `message2`, `message3`, and `message4`.
|
||||
However, only three of them reach `Bob`.
|
||||
This is because the two messages `message2` and `message3` have identical RLN epoch values, so, one of them gets discarded by the test fleets as a spam message.
|
||||
However, only three of them reach `Bob`.
|
||||
This is because the two messages `message2` and `message3` have identical RLN epoch values, so, one of them gets discarded by the test fleets as a spam message.
|
||||
The test fleets do not relay `message3` further, hence `Bob` never receives it.
|
||||
You can check this fact by looking at `Bob`'s console, where `message3` is missing.
|
||||
You can check this fact by looking at `Bob`'s console, where `message3` is missing.
|
||||
|
||||
|
||||
**Alice**
|
||||
```bash
|
||||
./build/chat2 --fleet:test --content-topic:/toy-chat/3/mingde/proto --rln-relay:true --rln-relay-dynamic:true --rln-relay-eth-contract-address:0xF471d71E9b1455bBF4b85d475afb9BB0954A29c4 --rln-relay-cred-path:rlnKeystore.json --rln-relay-cred-password:password --rln-relay-eth-client-address:https://sepolia.infura.io/v3/12345678901234567890123456789012 --ports-shift=1
|
||||
./build/chat2 --fleet:test --content-topic:/toy-chat/3/mingde/proto --rln-relay:true --rln-relay-dynamic:true --rln-relay-eth-contract-address:0xF471d71E9b1455bBF4b85d475afb9BB0954A29c4 --rln-relay-cred-path:rlnKeystore.json --rln-relay-cred-password:password --rln-relay-eth-client-address:https://sepolia.infura.io/v3/12345678901234567890123456789012 --ports-shift=1
|
||||
```
|
||||
|
||||
```
|
||||
Choose a nickname >> Alice
|
||||
Welcome, Alice!
|
||||
Connecting to test fleet using DNS discovery...
|
||||
Discovered and connecting to @[16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm, 16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ, 16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS]
|
||||
Discovered and connecting to @[16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp, 16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W, 16Uiu2HAmDCp8XJ9z1ev18zuv8NHekAsjNyezAvmMfFEJkiharitG]
|
||||
Listening on
|
||||
/ip4/75.157.120.249/tcp/60001/p2p/16Uiu2HAmH7XbkcdbA1CCs91r93HuwZHSdXppCNvJTDVvgGhuxyuG
|
||||
Store enabled, but no store nodes configured. Choosing one at random from discovered peers
|
||||
Connecting to storenode: 16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm
|
||||
Connecting to storenode: 16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp
|
||||
<Jul 26, 10:41> Bob: hi
|
||||
<Jul 26, 10:41> Bob: hi
|
||||
<Jun 29, 16:21> Alice: spam1
|
||||
|
|
@ -204,23 +204,23 @@ your rln identity commitment key is: bd093cbf14fb933d53f596c33f98b3df83b7e9f7a19
|
|||
>> message4
|
||||
--rln epoch: 165886593
|
||||
<Jul 26, 13:05> Alice: message4
|
||||
>>
|
||||
>>
|
||||
```
|
||||
|
||||
**Bob**
|
||||
```bash
|
||||
./build/chat2 --fleet:test --content-topic:/toy-chat/3/mingde/proto --rln-relay:true --rln-relay-dynamic:true --rln-relay-eth-contract-address:0xF471d71E9b1455bBF4b85d475afb9BB0954A29c4 --rln-relay-cred-path:rlnKeystore.json --rln-relay-cred-index:1 --rln-relay-cred-password:password --rln-relay-eth-client-address:https://sepolia.infura.io/v3/12345678901234567890123456789012 --ports-shift=2
|
||||
./build/chat2 --fleet:test --content-topic:/toy-chat/3/mingde/proto --rln-relay:true --rln-relay-dynamic:true --rln-relay-eth-contract-address:0xF471d71E9b1455bBF4b85d475afb9BB0954A29c4 --rln-relay-cred-path:rlnKeystore.json --rln-relay-cred-index:1 --rln-relay-cred-password:password --rln-relay-eth-client-address:https://sepolia.infura.io/v3/12345678901234567890123456789012 --ports-shift=2
|
||||
```
|
||||
|
||||
```
|
||||
Choose a nickname >> Bob
|
||||
Welcome, Bob!
|
||||
Connecting to test fleet using DNS discovery...
|
||||
Discovered and connecting to @[16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm, 16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ, 16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS]
|
||||
Discovered and connecting to @[16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp, 16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W, 16Uiu2HAmDCp8XJ9z1ev18zuv8NHekAsjNyezAvmMfFEJkiharitG]
|
||||
Listening on
|
||||
/ip4/75.157.120.249/tcp/60002/p2p/16Uiu2HAmE7fPUWGJ7UFJ3p2a3RNiEtEvAWhpfUStcCDmVGhm4h4Z
|
||||
Store enabled, but no store nodes configured. Choosing one at random from discovered peers
|
||||
Connecting to storenode: 16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm
|
||||
Connecting to storenode: 16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp
|
||||
rln-relay preparation is in progress ...
|
||||
your membership index is: xx
|
||||
your rln identity key is: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
||||
|
|
@ -228,5 +228,5 @@ your rln identity commitment key is: d4961a7681521730bc7f9ade185c632b94b70624b2e
|
|||
>> <Jul 26, 13:05> Alice: message1
|
||||
>> <Jul 26, 13:05> Alice: message2
|
||||
>> <Jul 26, 13:05> Alice: message4
|
||||
>>
|
||||
```
|
||||
>>
|
||||
```
|
||||
|
|
|
|||
|
|
@ -5,11 +5,11 @@ You will connect your chat2 client to waku2 test fleets.
|
|||
Note that test fleets will not filter spam messages, they merely route messages.
|
||||
Spam detection takes place at the chat2 users end.
|
||||
In this setting, you should try to spam the network by violating the message rate limit i.e.,
|
||||
sending more than one message per epoch.
|
||||
sending more than one message per epoch.
|
||||
At the time of this tutorial, the epoch duration is set to `10` seconds.
|
||||
You can inspect the current epoch value by checking the following [constant variable](https://github.com/status-im/nim-waku/blob/21cac6d491a6d995a7a8ba84c85fecc7817b3d8b/waku/v2/protocol/waku_rln_relay/constants.nim#L245) in the nim-waku codebase.
|
||||
Your messages will be routed via test fleets and will arrive at other live chat2 clients that are running in rate-limited mode over the same content topic i.e., `/toy-chat/3/mingde/proto`.
|
||||
Your spam activity will be detected by them and a proper message will be shown on their console.
|
||||
Your spam activity will be detected by them and a proper message will be shown on their console.
|
||||
|
||||
# Set up
|
||||
## Build chat2
|
||||
|
|
@ -20,7 +20,7 @@ make chat2
|
|||
```
|
||||
|
||||
## Setup a chat2 node in rate-limited mode
|
||||
Run the following command to set up your chat2 client.
|
||||
Run the following command to set up your chat2 client.
|
||||
|
||||
```
|
||||
./build/chat2 --content-topic:/toy-chat/3/mingde/proto --ports-shift=1 --fleet:test --rln-relay:true --rln-relay-membership-index:your_index
|
||||
|
|
@ -28,7 +28,7 @@ Run the following command to set up your chat2 client.
|
|||
```
|
||||
In this command
|
||||
- the `rln-relay` flag is set to true to enable RLN-Relay protocol for spam protection.
|
||||
- the `rln-relay-membership-index` is used to pick one RLN key out of the 100 available hardcoded RLN keys.
|
||||
- the `rln-relay-membership-index` is used to pick one RLN key out of the 100 available hardcoded RLN keys.
|
||||
You can pass your index using this command `--rln-relay-membership-index: your_index` e.g., `--rln-relay-membership-index:19` .
|
||||
Please use the index assigned to you in the dogfooding coordination phase.
|
||||
If you pick an index at random you may end up using the same key-pair as someone else, hence your messaging rate will be shared with that person(s).
|
||||
|
|
@ -53,12 +53,12 @@ Once you type a chat line and hit enter, you will see a message that indicates t
|
|||
<Feb 15, 12:27> Bob: Hi!
|
||||
```
|
||||
The numerical value `164495684` indicates the epoch of the message `Hi!`.
|
||||
You will see a different value than `164495684` on your screen.
|
||||
You will see a different value than `164495684` on your screen.
|
||||
If two messages sent by the same chat2 client happen to have the same RLN epoch value, then one of them will be detected as spam by the receiving chat2 clients.
|
||||
At the time of this tutorial, the epoch duration is set to `10` seconds.
|
||||
Thus, if you send two messages less than `10` seconds apart, they are likely to get the same `rln epoch` values.
|
||||
|
||||
After sending a chat message, you may experience some delay before the next chat prompt appears.
|
||||
After sending a chat message, you may experience some delay before the next chat prompt appears.
|
||||
The reason is that under the hood a zero-knowledge proof is being generated and attached to your message.
|
||||
|
||||
Once you are done with the test, make sure you close all the chat2 clients by typing `/exit` command.
|
||||
|
|
@ -70,10 +70,10 @@ quitting...
|
|||
# Sample test output
|
||||
|
||||
In the following sample test, two chat2 clients are set up, namely `Alice` and `Bob`.
|
||||
`Bob` sends three messages i.e., `message1`, `message2`, and `message3` to the test fleets.
|
||||
`Bob` sends three messages i.e., `message1`, `message2`, and `message3` to the test fleets.
|
||||
Test fleets will route the messages to their connections including `Alice`.
|
||||
The two messages `message2` and `message3` have an identical RLN epoch value of `164504930`, so, one of them will be detected as a spam message by `Alice`.
|
||||
You can check this fact by looking at the `Alice` console, where `A spam message is found and discarded : <Feb 16, 14:08> Bob: message3` is presented.
|
||||
The two messages `message2` and `message3` have an identical RLN epoch value of `164504930`, so, one of them will be detected as a spam message by `Alice`.
|
||||
You can check this fact by looking at the `Alice` console, where `A spam message is found and discarded : <Feb 16, 14:08> Bob: message3` is presented.
|
||||
|
||||
|
||||
Bob
|
||||
|
|
@ -82,11 +82,11 @@ Bob
|
|||
Choose a nickname >> Bob
|
||||
Welcome, Bob!
|
||||
Connecting to test fleet using DNS discovery...
|
||||
Discovered and connecting to @[16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ, 16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm, 16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS]
|
||||
Discovered and connecting to @[16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W, 16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp, 16Uiu2HAmDCp8XJ9z1ev18zuv8NHekAsjNyezAvmMfFEJkiharitG]
|
||||
Listening on
|
||||
/ip4/75.157.120.249/tcp/60002/p2p/16Uiu2HAmKdCdP89q6CwLc6PeFDJnVR1EmM7fTgtphHiacSNBnuAz
|
||||
Store enabled, but no store nodes configured. Choosing one at random from discovered peers
|
||||
Connecting to storenode: 16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ
|
||||
Connecting to storenode: 16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W
|
||||
>> message1
|
||||
--rln epoch: 164504929
|
||||
<Feb 16, 14:08> Bob: message1
|
||||
|
|
@ -111,11 +111,11 @@ Alice
|
|||
Choose a nickname >> Alice
|
||||
Welcome, Alice!
|
||||
Connecting to test fleet using DNS discovery...
|
||||
Discovered and connecting to @[16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ, 16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm, 16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS]
|
||||
Discovered and connecting to @[16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W, 16Uiu2HAkzHaTP5JsUwfR9NR8Rj9HC24puS6ocaU8wze4QrXr9iXp, 16Uiu2HAmDCp8XJ9z1ev18zuv8NHekAsjNyezAvmMfFEJkiharitG]
|
||||
Listening on
|
||||
/ip4/75.157.120.249/tcp/60001/p2p/16Uiu2HAkyTos6LeGrj1YJyA3WYzp9qKQGCsxbtvyoBRHSu9PCrQZ
|
||||
Store enabled, but no store nodes configured. Choosing one at random from discovered peers
|
||||
Connecting to storenode: 16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ
|
||||
Connecting to storenode: 16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W
|
||||
>> <Feb 16, 14:08> Bob: message1
|
||||
>> <Feb 16, 14:08> Bob: message2
|
||||
>> A spam message is found and discarded : <Feb 16, 14:08> Bob: message3
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ import
|
|||
|
||||
const
|
||||
FilterPeer =
|
||||
"/ip4/104.154.239.128/tcp/30303/p2p/16Uiu2HAmJb2e28qLXxT5kZxVUUoJt72EMzNGXB47Rxx5hw3q4YjS"
|
||||
# node-01.gc-us-central1-a.wakuv2.test.statusim.net on wakuv2.test
|
||||
"/ip4/34.16.1.67/tcp/30303/p2p/16Uiu2HAmDCp8XJ9z1ev18zuv8NHekAsjNyezAvmMfFEJkiharitG"
|
||||
# node-01.gc-us-central1-a.waku.test.statusim.net on waku.test
|
||||
FilterPubsubTopic = PubsubTopic("/waku/2/default-waku/proto")
|
||||
FilterContentTopic = ContentTopic("/examples/1/light-pubsub-example/proto")
|
||||
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ import
|
|||
|
||||
const
|
||||
LightpushPeer =
|
||||
"/ip4/134.209.139.210/tcp/30303/p2p/16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ"
|
||||
# node-01.do-ams3.wakuv2.test.statusim.net on wakuv2.test
|
||||
"/ip4/178.128.141.171/tcp/30303/p2p/16Uiu2HAkykgaECHswi3YKJ5dMLbq2kPVCo89fcyTd38UcQD6ej5W"
|
||||
# node-01.do-ams3.waku.test.statusim.net on waku.test
|
||||
LightpushPubsubTopic = PubsubTopic("/waku/2/default-waku/proto")
|
||||
LightpushContentTopic = ContentTopic("/examples/1/light-pubsub-example/proto")
|
||||
|
||||
|
|
|
|||
|
|
@ -21,15 +21,16 @@ import
|
|||
proc now*(): Timestamp =
|
||||
getNanosecondTime(getTime().toUnixFloat())
|
||||
|
||||
# An accesible bootstrap node. See wakuv2.prod fleets.status.im
|
||||
|
||||
# An accesible bootstrap node. See waku.sandbox fleets.status.im
|
||||
const bootstrapNode =
|
||||
"enr:-Nm4QOdTOKZJKTUUZ4O_W932CXIET-M9NamewDnL78P5u9D" &
|
||||
"OGnZlK0JFZ4k0inkfe6iY-0JAaJVovZXc575VV3njeiABgmlkgn" &
|
||||
"Y0gmlwhAjS3ueKbXVsdGlhZGRyc7g6ADg2MW5vZGUtMDEuYWMtY" &
|
||||
"24taG9uZ2tvbmctYy53YWt1djIucHJvZC5zdGF0dXNpbS5uZXQG" &
|
||||
"H0DeA4lzZWNwMjU2azGhAo0C-VvfgHiXrxZi3umDiooXMGY9FvY" &
|
||||
"j5_d1Q4EeS7eyg3RjcIJ2X4N1ZHCCIyiFd2FrdTIP"
|
||||
"enr:-QEkuEB3WHNS-xA3RDpfu9A2Qycr3bN3u7VoArMEiDIFZJ6" &
|
||||
"6F1EB3d4wxZN1hcdcOX-RfuXB-MQauhJGQbpz3qUofOtLAYJpZI" &
|
||||
"J2NIJpcIQI2SVcim11bHRpYWRkcnO4bgA0Ni9ub2RlLTAxLmFjL" &
|
||||
"WNuLWhvbmdrb25nLWMud2FrdS5zYW5kYm94LnN0YXR1cy5pbQZ2" &
|
||||
"XwA2Ni9ub2RlLTAxLmFjLWNuLWhvbmdrb25nLWMud2FrdS5zYW5" &
|
||||
"kYm94LnN0YXR1cy5pbQYfQN4DgnJzkwABCAAAAAEAAgADAAQABQ" &
|
||||
"AGAAeJc2VjcDI1NmsxoQPK35Nnz0cWUtSAhBp7zvHEhyU_AqeQU" &
|
||||
"lqzLiLxfP2L4oN0Y3CCdl-DdWRwgiMohXdha3UyDw"
|
||||
|
||||
# careful if running pub and sub in the same machine
|
||||
const wakuPort = 60000
|
||||
|
|
|
|||
|
|
@ -18,13 +18,16 @@ import
|
|||
../../../waku/waku_discv5,
|
||||
../../../waku/factory/builder
|
||||
|
||||
# An accesible bootstrap node. See wakuv2.prod fleets.status.im
|
||||
# An accesible bootstrap node. See waku.sandbox fleets.status.im
|
||||
const bootstrapNode =
|
||||
"enr:-Nm4QOdTOKZJKTUUZ4O_W932CXIET-M9NamewDnL78P5u9DOGnZl" &
|
||||
"K0JFZ4k0inkfe6iY-0JAaJVovZXc575VV3njeiABgmlkgnY0gmlwhAjS" &
|
||||
"3ueKbXVsdGlhZGRyc7g6ADg2MW5vZGUtMDEuYWMtY24taG9uZ2tvbmct" &
|
||||
"Yy53YWt1djIucHJvZC5zdGF0dXNpbS5uZXQGH0DeA4lzZWNwMjU2azGh" &
|
||||
"Ao0C-VvfgHiXrxZi3umDiooXMGY9FvYj5_d1Q4EeS7eyg3RjcIJ2X4N1" & "ZHCCIyiFd2FrdTIP"
|
||||
"enr:-QEkuEB3WHNS-xA3RDpfu9A2Qycr3bN3u7VoArMEiDIFZJ6" &
|
||||
"6F1EB3d4wxZN1hcdcOX-RfuXB-MQauhJGQbpz3qUofOtLAYJpZI" &
|
||||
"J2NIJpcIQI2SVcim11bHRpYWRkcnO4bgA0Ni9ub2RlLTAxLmFjL" &
|
||||
"WNuLWhvbmdrb25nLWMud2FrdS5zYW5kYm94LnN0YXR1cy5pbQZ2" &
|
||||
"XwA2Ni9ub2RlLTAxLmFjLWNuLWhvbmdrb25nLWMud2FrdS5zYW5" &
|
||||
"kYm94LnN0YXR1cy5pbQYfQN4DgnJzkwABCAAAAAEAAgADAAQABQ" &
|
||||
"AGAAeJc2VjcDI1NmsxoQPK35Nnz0cWUtSAhBp7zvHEhyU_AqeQU" &
|
||||
"lqzLiLxfP2L4oN0Y3CCdl-DdWRwgiMohXdha3UyDw"
|
||||
|
||||
# careful if running pub and sub in the same machine
|
||||
const wakuPort = 50000
|
||||
|
|
|
|||
|
|
@ -1055,10 +1055,10 @@
|
|||
"current": {
|
||||
"selected": true,
|
||||
"text": [
|
||||
"wakuv2.test"
|
||||
"waku.test"
|
||||
],
|
||||
"value": [
|
||||
"wakuv2.test"
|
||||
"waku.test"
|
||||
]
|
||||
},
|
||||
"datasource": {
|
||||
|
|
@ -1148,4 +1148,4 @@
|
|||
"uid": "U6YIdDSVz",
|
||||
"version": 1,
|
||||
"weekStart": ""
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ procSuite "Peer Manager":
|
|||
await allFutures(nodes.mapIt(it.mountRelay()))
|
||||
|
||||
let nonExistentPeerRes = parsePeerInfo(
|
||||
"/ip4/0.0.0.0/tcp/1000/p2p/16Uiu2HAmL5okWopX7NqZWBUKVqW8iUxCEmd5GMHLVPwCgzYzQv3e"
|
||||
"/ip4/0.0.0.0/tcp/1000/p2p/16Uiu2HAmQSMNExfUYUqfuXWkD5DaNZnMYnigRxFKbk3tcEFQeQeE"
|
||||
)
|
||||
require nonExistentPeerRes.isOk()
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ procSuite "Peer Manager":
|
|||
|
||||
# Failed connection
|
||||
let nonExistentPeerRes = parsePeerInfo(
|
||||
"/ip4/0.0.0.0/tcp/1000/p2p/16Uiu2HAmL5okWopX7NqZWBUKVqW8iUxCEmd5GMHLVPwCgzYzQv3e"
|
||||
"/ip4/0.0.0.0/tcp/1000/p2p/16Uiu2HAmQSMNExfUYUqfuXWkD5DaNZnMYnigRxFKbk3tcEFQeQeE"
|
||||
)
|
||||
require:
|
||||
nonExistentPeerRes.isOk()
|
||||
|
|
@ -218,7 +218,7 @@ procSuite "Peer Manager":
|
|||
await allFutures(nodes.mapIt(it.mountRelay()))
|
||||
|
||||
let nonExistentPeerRes = parsePeerInfo(
|
||||
"/ip4/0.0.0.0/tcp/1000/p2p/16Uiu2HAmL5okWopX7NqZWBUKVqW8iUxCEmd5GMHLVPwCgzYzQv3e"
|
||||
"/ip4/0.0.0.0/tcp/1000/p2p/16Uiu2HAmQSMNExfUYUqfuXWkD5DaNZnMYnigRxFKbk3tcEFQeQeE"
|
||||
)
|
||||
require nonExistentPeerRes.isOk()
|
||||
|
||||
|
|
|
|||
|
|
@ -138,6 +138,7 @@ suite "Waku ENR - Multiaddresses":
|
|||
var record: Record
|
||||
require record.fromURI(enrUri)
|
||||
|
||||
# TODO: get rid of wakuv2 here too. Needt to generate a ne ENR record
|
||||
let
|
||||
expectedAddr1 = MultiAddress
|
||||
.init("/dns4/node-01.do-ams3.wakuv2.test.statusim.net/tcp/443/wss")
|
||||
|
|
|
|||
|
|
@ -194,8 +194,8 @@ A node will attempt connection to all discovered nodes.
|
|||
|
||||
This can be used, for example, to connect to one of the existing fleets.
|
||||
Current URLs for the published fleet lists:
|
||||
- production fleet: `enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im`
|
||||
- test fleet: `enrtree://AO47IDOLBKH72HIZZOXQP6NMRESAN7CHYWIBNXDXWRJRZWLODKII6@test.wakuv2.nodes.status.im`
|
||||
- production fleet: `enrtree://AIRVQ5DDA4FFWLRBCHJWUWOO6X6S4ZTZ5B667LQ6AJU6PEYDLRD5O@sandbox.waku.nodes.status.im`
|
||||
- test fleet: `enrtree://AOGYWMBYOUIMOENHXCHILPKY3ZRFEULMFI4DOM442QSZ73TT2A7VI@test.waku.nodes.status.im`
|
||||
|
||||
See the [separate tutorial](../docs/tutorial/dns-disc.md) for a complete guide to DNS discovery.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue