Here is below a review of the lessons we learned sponsoring this bounty and supporting developers in using JS-Waku:
- 4 projects for js-waku bounty:
- Wakumono: End-to-end encrypted message service linked to your Ethereum address (winner)
- DexNews: A social/blogging/news platform that uses Waku for comments on articles and profiles
- Third project by bitsikka: A Twitter like platform using Waku.
- Baseline on Waku: Was using Whisper (then centralized NATS solution) and project upgrades to Waku. https://docs.baseline-protocol.org/
Most projects focused on peer-to-peer (human-to-human) communications.
We selected Wakumono as the winning project among two submissions as the usage of js-waku was clearly presented in the demo and we were able to run the project locally to try it out ourselves.
Third and fourth projects were not submitted in time.
- First feedback session was not used: Be more relax about feedback, instead of pro-actively organizing them on our side, scout hackers first and organize slot if there is interest in it. Ensure a feedback session do happen at the end of the hackathon as it is a great way to collect feedback.
- Ensure that all idea/examples suggested in bounty are in line with the hackathon’s rules.
- The bounty specified that Waku needs to be used in a meaningful way. However some videos did not clearly show this.Next time we could mention that as part of the demo, we need to see an A to B communication using Waku.
- Devs do not tend to check specs, ensure that the JS-Waku documentation explains enough of the behavior spec reading is not needed to understand. Tracked with #193.
- Some doc may be written from a protocol dev (spec) point of view, ensure that all docs is written from a library consumer (e.g. dApp developer) point of view. Tracked with #193.
- What Content topics are was not clear. Fixed with #383.
- All hackers used examples to inspire their app, hence it is clear that adding more examples will be beneficial.
- Baseline project which I would categorize as M2M still used
ChatMessageinstead of their own message. I guess this is the danger of having
ChatMessagein js-waku. We should review how we want to handle application examples and possibly extract
ChatMessagefrom js-waku to the examples folder.
- One of the hacker used ClojureScript which does not see to play well we async/await keywords. Having an example without await/async could help (or even better, a ClojureScript example). Tracked with #182
- Signing/Validating signature/encrypting/decrypting messages are a number of operations that most project needed, having examples on how to do that (or even better, js-waku doing it for you) seemed to be a great addition. Tracked with #74.
- The winning project was a very close implementation to ETH-DM. The current spec of ETH-DM are not realistic. This project had to solve 2 problems: Creating encryption private key from eth key, link encryption public key to eth address. It’d be interested to provide a standard and secure to solve this problem for future developer. Tracked with #72.
- Wakumono has issue sending messages both directions, it’d be interesting to implement ETH-DM and see if there are any issue on js-waku side that needs fixing.