Removing bridge.md tutorial as v1 doc was removed (#1954)

This commit is contained in:
Ivan Folgueira Bande 2023-08-28 10:09:42 +02:00 committed by GitHub
parent 01634f57f0
commit 04df6d1fa7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 0 additions and 88 deletions

View File

@ -1,88 +0,0 @@
# Bridging messages between Waku v1 and Waku v2
## Background
The `wakubridge` application allows bridging messages between Waku v1 and Waku v2 networks.
Packets received on the Waku v1 network are published once on the Waku v2 network using [`17/WAKU2-RELAY`](https://rfc.vac.dev/spec/17/).
Similarly, Waku v2 messages received on the configured [`17/WAKU2-RELAY`](https://rfc.vac.dev/spec/17/) pubsub topic are bridged to the Waku v1 network.
[`15/WAKU2-BRIDGE`](https://rfc.vac.dev/spec/15/) specifies how Waku v2 messages are converted to Waku v1 envelopes and vice versa.
The `wakubridge` application follows the topic recommmendations for bridging as set out in [`23/WAKU2-TOPICS`](https://rfc.vac.dev/spec/23/#bridging-waku-v1-and-waku-v2)
## Setting up a `wakubridge`
Start by compiling the `wakubridge` binary.
```bash
# The first `make` invocation will update all Git submodules.
# You'll run `make update` after each `git pull`, in the future, to keep those submodules up to date.
make wakubridge
# See available command line options
./build/wakubridge --help
```
The next step is to run a `wakubridge` connected to both a Waku v1 and a Waku v2 network.
### Connecting to a Waku v1 network
Many [config options available for Waku v1 nodes](../../waku/v1/README.md) are also available for the `wakubridge`, with a slight change in the naming (most often a `-v1`-suffix).
This includes configuration to connect to a peer or a fleet of peers.
For example, to connect the bridge to the existing Status Waku v1 `test` fleet:
```bash
./build/wakubridge --fleet-v1:test
```
To connect the bridge directly to a static enode URL:
```bash
./build/wakubridge --staticnode-v1:<enode-url>
```
The `--staticnode-v1` argument may be repeated.
### Connecting to a Waku v2 network
Similarly, several [config options available for Waku v2 nodes](../../waku/v2/README.md) are also available for the `wakubridge`, with a slight change in the naming (most often a `-v2`-suffix).
This includes configuration to connect to static Waku v2 peers:
```bash
./build/wakubridge --staticnode-v2:<peer-multiaddr>
```
The `--staticnode-v2` argument may be repeated.
### Setting the Waku v1 and Waku v2 private keys
It is possible to set the v1 and v2 node private keys for the bridge:
```bash
./build/wakubridge --nodekey-v1:<v1-private-key-as-hex> --nodekey-v2:<v2-private-key-as-hex>
```
### Configuration summary
A typical `wakubridge` setup, combining the configuration items above, could look something like this:
```bash
./build/wakubridge --nodekey-v1:<v1-private-key-as-hex> --nodekey-v2:<v2-private-key-as-hex> --staticnode-v1:<enode-url> --staticnode-v2:<peer-multiaddr>
```
By default the `wakubridge` will then begin to bridge all Waku v1 messages routed by `staticnode-v1` to the Waku v2 network defined by the default Waku v2 pubsub topic (`/waku/2/default-waku/proto`) and participated in by `staticnode-v2`.
Waku v2 messages on the default Waku v2 pubsub topic will similarly be bridged to Waku v1.
This is the likely configuration for most `wakubridge` setups.
### Other configuration
For testing purposes, or for advanced bridging applications,
it is possible to run the `wakubridge` application with a Waku v1 topic interest:
```bash
./build/wakubridge --waku-v1-topic-interest:true
```
It is also possible to change the default Waku v2 pubsub topic from/to which messages are bridged:
```bash
./build/wakubridge --bridge-pubsub-topic:/waku/2/my-bridge-pubsub-topic/proto
```