This was original written, posted and agreed up on beginning of November. Posting it here for transparency and to be able to follow up on things. - Oskar
We have two main goals for Waku v2 over the next month or so:
- Getting our first users, aka production-ready.
- Making it worth using.
These two main goals then splits up into a few strands of work.
Getting our first users
The first means integrating with initial users.
- User 0 is us, with the toy chat application we built for Dingpu.
- User 1 is Status, more specifically via status-nim.
- User 2 is browser-based, i.e. WalletConnect (or similar).
User 1 and 2 have slightly separate needs. For Status, the Nim Node API will likely be used. For something like WalletConnect, we need something that works through browsers. Currently, the most obvious path here is the REST based JSON RPC API mentioned previously.
What does success look like? For User 1, experimental Waku v2 mode in desktop (e.g.).
For User 2, a end-to-end WalletConnect PoC using Waku v2 (or similar). User 2 has some dependencies depending on how things go with secure web server support. For both of these, this means supporting the teams and making sure everything is setup and documented properly for the relevant teams. We are delivering a product that they can use, and want to use.
Worth using
For making it worth using, just moving to libp2p, GossipSub and req/resp for historical messages is a step up. However, it needs to be more enticing than this to make it worthwhile in the bigger picture. There are a few pieces here, and for now I believe we can look at it as two separate tracks.
A big one is privacy - we can’t claim to be privacy-preserving if we haven’t studied this in more detail. This means studying GossipSub privacy properties, and also touches on experimental spam protection through RLN, since if we weren’t privacy-preserving spam protection would be easy.
Another big one is user-run nodes and accounting - what was mentioned as track 3 before. This is necessary to be able to service light nodes in the network in a decentralized fashion. The obvious first step here is to do light connection accounting spec/PoC and making this visible. As for making node running easy, this interacts with the getting our first users goal above. We may be able to piggyback on the node running program for Nimbus here.
There is also some work re scaling here, but with GossipSub and topic sharding enabled we are in a decent shape here I believe. There may be some stress testing and simulation that we can do here, but that would likely fall under getting production-ready.
Note that the critical path is getting production-ready, whereas these other things are more stuff that can be done in parallel.
Summary
In summary, two main goals, each with two main tracks:
- Production-ready: User 1
- Production-ready: User 2
- Worth using: Privacy
- Worth using: Accounting
Neatly mapping to four people, which is how many we are full time on Vac. My suggestion is that each person has one main focus (Of course, there will always be issues that don’t fall neatly in one place or another, or collaboration etc). Specifically, I’m suggesting the following:
- User 1 - Dean
- User 2 - Hanno
- Privacy - Sanaz
- Accounting - Oskar
I’ll also help out where I can on the other tracks. Kim will support with targeted efforts where it makes sense and he has some special knowledge (bridge, Nim, etc).
What this would mean more practically is something like:
- Dean to make sure Status can use Waku and filter, store protocol etc through status-nim. This means ensuring it meets the needs of the Status protocol, e.g. encrypted payloads, persistence of store messages, specs up to date and useful. To work together with Hanno on general production-ready issues.
- Hanno to make sure there’s a REST JSON RPC API that makes sense, can be translated to HTTP-based, and can be used by browser-based apps like WalletConnect. To work together with Dean on general production-ready issues.
- Sanaz to work on privacy researchy issues, specifically RLP PoC for spam protection and GossipSub privacy guarantees, as well as spec guarantees. Later also study and prioritize work around unlinkability, etc.
- Oskar to work on accounting for light nodes PoC, make sure its policy encompasses previosuly proposed solutions and is extensible, setting the ground for later settlement and stronger guarantees. Also see how we can make this visible and possibly integrate with node running program.
Of course this is open for discussion, and if anyone has a different view of how we should structure things over the next month or two let’s talk about it! [UPDATE: Agreed upon.]
The goal with this is to make it more clear what work needs to be done medium term, and for each person to be able to take responsibility for and define the work that needs to be done, as opposed to micro management around specific issues on a weekly basis.