We want to have a clear scope for the next testnet so we know what to do target and when we can launch it.
Acceptance criteria
Agreed upon scope for next testnet (protocols, clients etc)
Issue with checklist of things that have to be done
Estimate for launch
Notes
My current thinking is as follows:
0) I think it'd be good if we can close track 1 very soon, especially as we have two people joining and prios/tracks might change a bit. As a reminder about scope: https://github.com/vacp2p/research/projects/1
1) We want to have at least store protocol integrated and in draft.
2) Filter protocol would be good too, but considering how slow development is there it might make sense to focus on store for now. I'd really rather this be done with though...
3) I think a rudimentary bridge would be useful, but the complexity of it isn't 100% clear to me. Perhaps just running v1 and v2 in same node? (Stretch here would be having the current data format being relayed)
4) While rpc scripts worked, I think it'd be good to have a basic more integrated end to end chat example, see https://github.com/status-im/nim-waku/issues/177
5) Waku Web PoC is not very far from being spec compliant (basically just WakuMessage), so it would be cool to have that as part of two basic clients github.com/vacp2p/waku-web-chat/
6) I'm not sure if Stimbus/Desktop would be able to participate here, depends a bit on how they are with bandwidth (cc @iurimatias)
oskarth
commented
3 years ago
Problem
We want to have a clear scope for the next testnet so we know what to do target and when we can launch it.
Acceptance criteria
Notes
My current thinking is as follows:
0) I think it'd be good if we can close track 1 very soon, especially as we have two people joining and prios/tracks might change a bit. As a reminder about scope: https://github.com/vacp2p/research/projects/1 1) We want to have at least store protocol integrated and in draft. 2) Filter protocol would be good too, but considering how slow development is there it might make sense to focus on store for now. I'd really rather this be done with though... 3) I think a rudimentary bridge would be useful, but the complexity of it isn't 100% clear to me. Perhaps just running v1 and v2 in same node? (Stretch here would be having the current data format being relayed) 4) While rpc scripts worked, I think it'd be good to have a basic more integrated end to end chat example, see https://github.com/status-im/nim-waku/issues/177 5) Waku Web PoC is not very far from being spec compliant (basically just WakuMessage), so it would be cool to have that as part of two basic clients github.com/vacp2p/waku-web-chat/ 6) I'm not sure if Stimbus/Desktop would be able to participate here, depends a bit on how they are with bandwidth (cc @iurimatias)
What are your thoughts @decanus and @kdeme ?