Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Waku v0 PoC #120
@kdeme that's fine, I wanted to duplicate it to KISS for now. Can always optimize it later, perhaps for waku v1? (rule of three). Alternatively, if it makes it easier to have WakuWhisper capability inside Waku namespace and not pollute whisper_protocol.nim
From PM with Kim for reference
After spending a bit of time with the bridge stuff I agree that #122 is probably necessary.
My nim-foo isn't quite up to par, I had some issues with type duplication, essentially I tried to do
I think I'll wait until you've done the refactoring above, then above should essentially work. Do you want to work on the same branch? might be easier, also since I think we usually work slightly different hours.
I've removed the fix-119 merge commit and rebased to get that fix + refactor changes in. Adjusted the Waku/0 code to make use of
@oskarth I've dropped your last commit as it had merge issues with the above and I was planning to change the approach somewhat, see below. I hope that's OK.
Next, some bridging attempt:
The original idea I had was to simply share the queue. I don't believe this will create problems in terms of network message forwarding.
If one shared queue would be a problem somehow, another option would be to allow for a custom function to be called in the
I've adjusted the waku test to have a
Added to the regular p2p test cases, and dropped the commit of the extra test task.
How about a separate fn for adding caps in right order? Strictly speaking, having WakuWhisper bridge is more than just having waku and whisper capability, so perhaps bridging should even be a flag.
What do we need to do to get this merged? Can we do the cleaner queue implementation in a follow up PR?
Yes, default we should not bridge in case we have both capabilities. This is now just a quick implementation to be able to test it. If we go for 1 shared queue we should have:
However, I think the last point requires DSL change, I'll think about it.
For merging I think I first have to figure out why appveyor test fails. And I think we can also drop the commits adding the waku_basic_client.nim? There is no real use for this now.
According to `doc/p2p.md` capability should be three letters. I can't see this in https://github.com/ethereum/devp2p/blob/master/rlpx.md#capability-messaging though, but better safe than sorry. This also dismabiguates and stays somewhat consistent in vocabulary: Whisper -> Waku whisper -> waku shh -> wkk