Waku - Ensure network compatibility between Status v1 clients (Whisper v6) and Waku 0

[oskarth]

Problem

As part of https://github.com/vacp2p/specs/issues/27 we want to create a new subprotocol, which will pave the way for things such as bandwidth improvements. However, we want Waku version 0 to be compatible with Whisper v6 / shh/6 / Status v1 so nodes can keep talking to each other with no disruption.

Details

We need to do bridging of traffic in the future regardless. (Full) Waku nodes should listen to Whisper v6 traffic and relay it further to Waku clients.

Acceptance criteria

• [ ] Documented strategy for ensuring compatibility between Whisper v6 and Waku v0.

Possible solutions

See above.

Notes

-

[oskarth]

Some early explorations for WakuWhisper mode in https://github.com/status-im/nim-eth/pull/120

Can't happen in subscription handler (decrypted/diff data structure); needs to happen in inside queue logic. Consider reference to Whisper object / queue. Then wakuWhisper config. This way we have something like:

• Waku
• Whisper
• Waku mode with WakuWhisper bridge capability

fyi @kdeme @decanus

[oskarth]

Implementation detail: Also consider not polluting e.g. whisper_protocol.nim in nim-eth, but instead have Whisper reference in waku protocol namespace and do capability / conditional checking there

[oskarth]

See https://github.com/status-im/nim-eth/pull/120 for current state

On a spec level it seems fairly straightforward, mostly implementation details right now it seems like.

One thing that has to be thought about a bit more is Waku->Whisper. Do we want to keep publishing on Whisper, or just publish on Waku? If just Waku and we do bridging that way too, we need to ensure it doesn't double bridge, i.e. Waku>Whisper>Waku>...

[kdeme]

So I've updated https://github.com/status-im/nim-eth/pull/120 to do bridging by letting Whisper protocol and Waku protocol use a shared queue. I don't see any problems with that in the nim implementation right now.

Next, I think if you want compatibility you will need to forward in both directions as a bridge. How else can an old client still receive messages from newer clients?

I'm not sure what you mean with double bridge. However it did make me realise that connecting two bridges to each other will cause duplicate messages between them as they will send the messages both over the Whisper and the Waku protocol. So perhaps some action should be taken there. (maybe that is what you meant?)

• Whisper Node A <-> Bridge Node B <-> Bridge Node C <-> Whisper Node D => when Node A send a message, D will receive it however between B and C the message will be transferred twice.

[oskarth]

Yeah exactly. The other alternative I wrote above is to publish on Whisper as well but not read (bandwidth). For now I've documented the only publish on Waku story. If we can figure out a way to avoid double relaying that'd be useful.

See https://github.com/vacp2p/specs/pull/28/commits/b8407bb6502ae0ccf067157c43260fffd54d0942 for spec

[kdeme]

So the current double relay issue exists because we have two bridges (nodes) connected to each other via rlpx and both support Waku and Whisper, so both these protocols are active between the two nodes. The message queue gets shared (or messages from 1 queue get relayed to the other, similar situation). And as we have two protocols now sending these messages to peers, each message will have a duplicate between bridges.

Ideally this could be resolved by not only sharing the message queue, but also the per peer hash set of received messages. Or not necessarily sharing but updating the hash set per peer of each protocol when messages get send for one protocol. This solution might turn out to be complex and intrusive, this will depend on the specific implementations of course. TBI.

Other ideas:

• Ugly: Just tell Waku to shut up when Whisper is connected (and/or the other way around). Would require several additional checks in the protocols, making it a very ugly and unwanted solution.
• Cleaner but more complex: Make the bridge exist out of two nodes (two different enodes), one with Waku capability & one with Whisper capability. Share/relay queues between the nodes. This doesn't directly solve the problem, as the bridges might still connect to each other over both enodes. However, you can cleanly disconnect one now. So the complexity here would be that you have to arrange the node network setup somehow. Or build in checks to now allow only one of the connections between bridges (How? Use same keypair for each node? Is this possible?).
  • To add to the overkill here, a simple subprotocol could be defined to share the messages between the nodes.

[oskarth]

I'd consider this done, even though a better strategy might be found. @kdeme re-open if you disagree