From 0edd5fdc9ada3f18dc3013f2927e0363682f5762 Mon Sep 17 00:00:00 2001
From: jm-clius <jm-clius@users.noreply.github.com>
Date: Mon, 28 Feb 2022 17:45:22 +0000
Subject: [PATCH] deploy: f094846c706f0268bc0ae35150d3a1430d1d7044

---
 docs/tutorial/bridge.md         | 88 +++++++++++++++++++++++++++++++++
 waku/common/config_bridge.nim   |  2 +-
 waku/v2/node/wakunode2.nim      |  2 +-
 waku/v2/protocol/waku_relay.nim |  2 +-
 4 files changed, 91 insertions(+), 3 deletions(-)
 create mode 100644 docs/tutorial/bridge.md

diff --git a/docs/tutorial/bridge.md b/docs/tutorial/bridge.md
new file mode 100644
index 000000000..44f28c6ff
--- /dev/null
+++ b/docs/tutorial/bridge.md
@@ -0,0 +1,88 @@
+# 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 bridge
+
+# 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
+```
diff --git a/waku/common/config_bridge.nim b/waku/common/config_bridge.nim
index 275ca1737..250d21bd7 100644
--- a/waku/common/config_bridge.nim
+++ b/waku/common/config_bridge.nim
@@ -111,7 +111,7 @@ type
 
     store* {.
       desc: "Flag whether to start store protocol",
-      defaultValue: true
+      defaultValue: false
       name: "store" }: bool
 
     filter* {.
diff --git a/waku/v2/node/wakunode2.nim b/waku/v2/node/wakunode2.nim
index 36468ccbe..babf01809 100644
--- a/waku/v2/node/wakunode2.nim
+++ b/waku/v2/node/wakunode2.nim
@@ -387,7 +387,7 @@ proc publish*(node: WakuNode, topic: Topic, message: WakuMessage) {.async, gcsaf
     return
 
   let wakuRelay = node.wakuRelay
-  debug "publish", topic=topic, contentTopic=message.contentTopic
+  trace "publish", topic=topic, contentTopic=message.contentTopic
   var publishingMessage = message
 
   let data = message.encode().buffer
diff --git a/waku/v2/protocol/waku_relay.nim b/waku/v2/protocol/waku_relay.nim
index 39927263f..b9e9c12a8 100644
--- a/waku/v2/protocol/waku_relay.nim
+++ b/waku/v2/protocol/waku_relay.nim
@@ -68,7 +68,7 @@ method publish*(w: WakuRelay,
                 pubSubTopic: string,
                 message: seq[byte]
                ): Future[int] {.async.} =
-  debug "publish", pubSubTopic=pubSubTopic, message=message
+  trace "publish", pubSubTopic=pubSubTopic, message=message
 
   return await procCall GossipSub(w).publish(pubSubTopic, message)