Waku v2: Briding with waku v1

[kdeme]

Problem

Waku v2 will run on libp2p (Flood/GossipSub + request - response protocol(s) ).
Waku v1 is a "capability" on devp2p/rlpx.

As it currently is specified, the envelope structure will also change.

This issue is about investigating how a bridge can work, transferring back and forth these different envelopes, maintaining the payloads.

Acceptance criteria

Lay out how a bridge between these networks can work.

[kdeme]

Disclaimer: This is a first write up and I'd have to look more into the libp2p side to understand if all is possible, mostly the part regarding the signature (See TBI mentions) is not clear and needs further investigation.

Payload bridging

A bridge would require obviously support for both Waku versions:

• Waku v1 - with devp2p/rlpx underneath
• Waku v2 - with libp2p underneath

For Waku v2, most of the envelope fields will be removed. There is no more nonce (to calculate PoW) and expiry and TTL (to calculate when an envelopes is expired) field.
As the envelope data structure differs between Waku v1 and Waku v2, the bridge will have to transfer payloads from envelopes from one version to the other.

For messages flowing from Waku v1 to Waku v2, the usual checks should remain as with normal v1 to v1 relaying:

• Expiry & future time checks
• PoW check (albeit low)
• size check

Next, a new Waku v2 envelope should be created, the payload copied, and the envelope published as message on Waku v2 gossip domain.

For messages flowing from v2 to v1, the bridge will have to create a Waku v1 envelope. It will have to set a new expiry/ttl and it will have to do the, limited, PoW calculation.
So differently from previously Whisper to Waku bridging, "reposting" will need to be done instead of just relaying.
This could be a DoS attack vector, as a malicious actor could post lots of messages on Waku v2, giving bridges lots of reposting work. For this reason, the bridges should probably be run independently of other Status fleet nodes (a bridge that goes down should not disrupt regular Waku v2 to v2 traffic).

Payload encryption removal and passing of signature

update: This section is obsolete, see #159 (comment)
A second concern regarding compatiblity of v1 and v2 is regarding the current optional payload encryption and signing
Currently payload encryption is optional, either using symmetric or asymmetric keys.
Additionally, the payload can also be signed (before the encryption). Both these features are currently used in the Status application/specification.
The signature is an extra problem as Libp2p PubSub has its own support for optionally signing the payload.

So the idea is to remove the encryption in Waku v2, and to leave this to the layer up (where it is also done for encryption in e.g. the Status application)
Keeping compatiblity here is much more troublesome, but can probably be achieved by doing a step in-between where both encryption and no encryption is allowed.
For the signature part, from my current understanding it should be possible to also copy over the signature, unless the signature is not only done on purely the unencrypted data part of the payload, TBI.

E.g.
For Waku v2 side:

• Post envelopes always without the optional encryption. Signing can/will be done at libp2p PubSub level.
• When receiving envelopes (on specific topic content filter), still try to decrypt with asymmetric/symmetric key, if it fails, just pass it along a layer up as is (should be v2 envelope), signature should be in libp2p PubSub layer. If decryption passes, get the signature from the message payload. This means that Waku v2 also needs support of the v1 envelope data format structure: https://specs.vac.dev/specs/waku/envelope-data-format.html.

For Waku v1 side:

• Keep posting envelopes as is now, with the additional optional encryption.
• Keep decrypting as is done now, but if it fails, still pass it along a layer up. It will be a messages for waku v2, and should still contain the signature.

For Waku v1-v2 bridge:

• When bridging messages from v2 to v1, the data field needs to be created, with payload and signature for libp2p side (to be further investigated!).
• When bridging messages from v1 to v2, decryption will not be possible, so we can't get the signature. We can only pass it along without signature. This is an issue, but can be resolved with less then ideal step mentioned in Waku v2 above.

And eventually, the decryption step in Waku v2 can be removed once v1 and bridge is dropped.

However, to avoid the annoyance of having to support the old envelope data format & having to either get the signature at libp2p PubSub or at payload level, the step of removing the encryption could also be done from one v1 version to another v1 version.
This way it should always be possible for the bridge to copy over the signature (TBI).

Note: It is still under discussion if we should leave the option for optional encryption in Waku v2 open. So this is more a discussion about how the Status application/specification should use it. And it will also require additional changes, e.g. waku-org/nwaku#39 (comment)

[kdeme]

Update:
The PubSub spec makes it clear that signing happens by the keypair where the peerid is also derived from. So this is a libp2p pubsub interal message authentication and not usable outside of this setting. We should probably advice not to use this as it will have privacy consequences (If this is enabled, it will be possible to link a gossipSub message to a peerId and thus IP-address).

Anyhow, this means that we could move both signing & encryption to the layer up, which makes more sense as it is more clearly separated.
So the examples/explanation in "Payload encryption removal and passing of signature" above becomes obsolete.

For the bridge it is just a matter of passing along the data field of Waku v1 to the payload field of Waku v2, and vice versa. The filters in v2 will not be able trigger purely on whether it can decrypt. This is for a layer higher. The logic currently in Waku v1 [envelope data format spec] (https://github.com/vacp2p/specs/blob/master/specs/waku/envelope-data-format.md) will need to be repeated on the application side when using Waku v2, for messages originating from a Waku v1 client.
It is either that or removing the optional encryption in an in-between step from one waku v1 version to another.

A question that remains is where to do the signing. Currently it is before Waku v1 encryption, but when Waku encryption is removed, is it still fine to leave the signature there without the Waku encryption?
AFAIK the signature is used to derive the sender in public chats, which anyone can decrypt, so probably, yes.
But I'm not sure if it is also used in the same way for private 1:1/group chats.

[oskarth]

@kdeme Any update on this?

[kdeme]

See #179 and #181