Add section on compatiblity and waku v1 v2 bridge (#179)

* Add section on compatiblity and waku v1 v2 bridge

* Update specs/waku/waku-v2.md

Co-authored-by: Oskar Thorén <ot@oskarthoren.com>

* Update specs/waku/waku-v2.md

Co-authored-by: Dean Eigenmann <7621705+decanus@users.noreply.github.com>

Co-authored-by: Oskar Thorén <ot@oskarthoren.com>
Co-authored-by: Dean Eigenmann <7621705+decanus@users.noreply.github.com>

specs/waku/waku-v2.md

@@ -25,6 +25,10 @@ authors: Oskar Thorén <oskar@status.im>
         * [HistoryResponse](#historyresponse)
     + [Content filtering](#content-filtering)
       - [Protobuf](#protobuf-2)
+- [Upgradability and Compatibility](#upgradability-and-compatibility)
+    * [Compatibility with Waku v1](#compatibility-with-waku-v1)
+      - [Bridge](#bridge)
+      - [Security Considerations](#security-considerations)
 - [Copyright](#copyright)
 - [References](#references)
 
@@ -310,6 +314,68 @@ implementation matches spec
 
 Initial raw version. Released []()
 
+# Upgradability and Compatibility
+## Compatibility with Waku v1
+
+Waku v2 and Waku v1 are different protocols all together. They use a different
+transport protocol underneath; Waku v1 is devp2p RLPx based while Waku v2 uses
+libp2p. The protocols themselves also differ as does their data format.
+Compatibility can be achieved only by using a bridge that not only talks both
+devp2p RLPx and libp2p, but that also transfers (partially) the content of a
+packet from one version to the other.
+
+### Bridge
+
+A bridge requires supporting both Waku versions:
+
+* Waku v1 - using devp2p RLPx protocol
+* Waku v2 - using libp2p protocols
+
+Packets received on the Waku v1 network SHOULD be published just once on the
+Waku v2 network. More specifically, the bridge SHOULD publish
+this through the Waku Relay (PubSub domain).
+
+Publishing such packet will require the creation of a new `Message` with a
+new `WakuMessage` as data field. The `data` and `topic` field from the Waku v1
+`Envelope` MUST be copied to the `payload` and `contentTopic` fields of the
+`WakuMessage`. Other fields such as nonce, expiry and ttl will be dropped as
+they become obsolete in Waku v2.
+
+Before this is done, the usual envelope verification still applies:
+
+* Expiry & future time verification
+* PoW verification
+* Size verification
+
+Bridging SHOULD occur through the `WakuRelay`, but it MAY also be done on other Waku
+v2 protocols (e.g. `WakuFilter`). The latter is however not advised as it will
+increase the complexity of the bridge and because of the
+[Security Considerations](#security-considerations) explained further below.
+
+Packets received on the Waku v2 network SHOULD be posted just once on the Waku
+v1 network. The Waku v2 `WakuMessage` contains only the `payload` and
+`contentTopic` fields. The bridge MUST create a new Waku v1 `Envelope` and
+copy over the `payload` and `contentFilter` fields to the `data` and `topic`
+fields. Next, before posting on the network, the bridge MUST set a new expiry
+and ttl and do the PoW nonce calculation.
+
+### Security Considerations
+As mentioned above, a bridge will be posting new Waku v1 envelopes, which
+requires doing the PoW nonce calculation.
+
+This could be a DoS attack vector, as the PoW calculation will make it more
+expensive to post the message compared to the original publishing on the Waku v2
+network. Low PoW setting will lower this problem, but it is likely that it is
+still more expensive.
+
+For this reason, bridges SHOULD probably be run independently of other nodes, so
+that a bridge that gets overwhelmed does not disrupt regular Waku v2 to v2
+traffic.
+
+Bridging functionality SHOULD also be carefully implemented so that messages do
+not bounce back and forth between the two networks. The bridge SHOULD properly
+track messages with a seen filter so that no amplification can be achieved here.
+
 # Copyright
 
 Copyright and related rights waived via

wordlist.txt

@@ -41,6 +41,7 @@ devp
 DevP
 devp2p
 DNS
+DoS
 ECDSA
 Eigenmann
 EIP