Closed oskarth closed 4 years ago
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:
fyi @kdeme @decanus
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
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>...
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?)
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
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:
I'd consider this done, even though a better strategy might be found. @kdeme re-open if you disagree
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
Possible solutions
See above.
Notes
-