Dogfooding is very important to the culture of the Waku team. If we do not eat our own dog food, who will?
We are eager to see application built on Waku, so we run a mini internal hackathon in March this year, to test our own ideas and see what our team mates would build.
The hackathon was organized over a week, before it started, Waku CCs listed ideas and form teams of 2-3 people. 6 projects reached some level of maturity and were presented to a panel of IFT CCs.
There was no prizes, the intent of the panel was to provide an opinion on whether the ideas, and related business cases had potential.
The primary intent was to understand how dev ready our library, protocols and software are. In addition to having some fun and some cross-team bondings. We run a retrospective after the hackathon to capture lessons and action items.
We also ask our panelist to provide a recommendation or not to pursue the projects.I am included a note about this for each project.
Stats
- 12 Waku core contributors participated to the hackathon
- TypeScript was the most popular language
- Sometimes combined with Svelte
- Golang and Rust where also used
- One project was multi-platform
- All projects involved contributors from different Waku sub-teams
- 6 projects were presented
- 2 projects had overwhelming support from the panelists
- 3 projects had a mix yes/not sure feedback from the panelists
Projects
WhisperBox.app
Live App: https://www.whisperbox.app/
Repo: GitHub - whisperbox-org/whisperbox
Description: WhisperBox is a Web3-powered form platform that prioritizes privacy through end-to-end encryption and decentralized storage. Create secure forms, surveys, and polls without compromising user data.
Panel Verdict: Strong support.
WhisperBox is a promising project that solves a clear problem by providing a private, secure, and decentralized alternative to Google Forms. It has a well-defined market need, low resource requirement, and seamless UX. There’s internal demand for the solution, and potential for monetization via premium features or a light tokenomics model. While opinions on the business case vary, the project showcases Waku’s capabilities and has value as a universal utility in the web3 space.
Recommended Next Step: IFT people ops are keen for such a solution as the tools we currently use do not fully align with our principles. Waku already committed to develop 2 web apps: Qaku (to MVP) and Logos Forum (PoC). Once those commitments are successfully delivered, we will propose to include further work on WhisperBox as part of the Waku roadmap.
Waku Remote
Repo: GitHub - adklempner/tauri-waku at hackathon
Description: I want to be able to use my phone to scan a QR code on my computer(s) and then change the volume of that computer using my phone.
Panel Verdict: Not sure.
Waku Remote has mixed feedback, with concerns about its unclear problem statement, differentiation, and target user base. While it has potential applications in IoT and home staking nodes, further validation and exploration are needed. The project requires a clearer focus on the live connection protocol and studying current market solutions to improve UX and determine viability.
Recommended Next Steps: The idea of using Waku to control a remote Nimbus or Dappnode staking node has often been discussed but never materialized. I suggest to refine the use case and better understand the current home/self hosting market (dappnode, Synology, Qnap) and to understand what USP this can bring (privacy, sovereignty, ux, etc)
Waku Phone
Live App: https://weboko.github.io/waku-phone/
Repo: GitHub - weboko/waku-phone
Description: A phone app to call people over Waku by using your Contacts
Panel Verdict: Strong support:
Waku Phone is a promising concept that showcases Waku’s potential as a decentralized VoIP alternative, offering a privacy-preserving solution for communication. While it has potential as a dedicated app for privacy-conscious users, monetization is unclear, with options like token-gated access. The project requires a STUN server, and further exploration is needed to determine feasibility and reliability. It’s recommended to pursue the project, with clearer problem definition, UX refinement, and potential integration with the Status app.
Recommended Next Steps: Further discuss with Status app leadership if and when there is appetite for such feature. Further technical exploration would be necessary to decentralized STUN server, and also understand reliability level without a TURN server. Would recommend to pick up once Waku incentivization is more mature as it would be unsustainable to introduce the usage of altruist TURN servers (if needed).
Waku Name Service
Repos:
- GitHub - stubbsta/waku-ens-contract: WNS domain name to IP mapping smart contract
- GitHub - gabrielmer/waku-name-service
Description: Resolve IP and wallet addresses from a normal browser without anyone getting doxxed. Kind of like ENS but much more privacy preserving - not linking a domain to a wallet/IP, but linking a domain to a public key and the rest is negotiated in private through Waku
Panel Verdict: Mixed - unsure/do not pursue.
WNS aims to provide privacy-preserving name resolution, but its potential is uncertain due to unclear monetization and declining ENS traction. Despite a strong technical foundation, the project lacks a clear go-to-market strategy and demand validation. Refinement is needed to find a clear use case and business case, with some potential seen in using WNS for marketplace service providers.
Recommended Next Steps: I believe this concept to be crucial for a generalised marketplace. However, in it is current form it has failed to convinced on the unique selling point. I would recommend the team to re-iterate on the use case. This is likely to be picked up as we enhance discovery and negotation strategies for the waku-service marketplace.
Waku Sign
Repo: GitHub - threeproto/waku-sign-extension
Description: Pair your software wallet with a browser extension to request and fulfil signature and other Web3 RPC requests without relaying on a centralized infrastructure.
Panel Verdict: Mix Pursue/Not sure
Waku Sign is a promising project that addresses WalletConnect’s centralization and improves dApp-wallet communication with a decentralized solution. However, adoption may be challenging due to WalletConnect’s strong market presence. The project’s monetization model is unclear, and further research is needed to determine its viability. Integrating with the Waku SDK or testing it in Status’s browser extension could be potential solutions.
Recommended Next Steps: Discuss with Status leadership if there is any appetite in the matter. The Status team is working on a companion web extension to enable dapp to browser to Status Desktop communication. Integrating Waku to enable pairing with Status Mobile seems to be a natural next step.
However, some maturity from js-waku is needed, especially in terms of working in browser extension. Would need to review technical feasibility once planned js-waku related milestones are delivered.
Passkey for RLN
Description:
- Register with passkey
- Reconstruct RLN Keystore from passkey
Panel Verdict: Mix/Not Sure.
The “Passkley for RLN” project aims to simplify RLN credential management using passkeys, which could increase adoption and ease of use for RLN and its various use cases. However, the revenue model and problem-solution fit are unclear, leading to a recommendation to not pursue the project. On the other hand, some see value in exploring ways to secure RLN credentials, and using a passkey or password manager could be an acceptable solution, given that the wallet has ultimate control. The limitations of the approach may not be significant, especially if the industry moves towards using one wallet address per app, as recently suggested by Vitalik.
Recommended Next Steps: The intent in 2025 is to integrate RLN in applications (Status, Qaku), which will highlight the most critical UX challenges. Secure handling of RLN credentials may be one, and if so, this should be picked up.
Lessons and Action Items
The retrospective session was a collaborative effort to reflect on the lessons learned, successes, and challenges faced during the hackathon. The team discussed various topics, including the need for specs for redundant work, issues with libwaku and js-waku, and the importance of state machines and ACK messages for application-level communication.
The team also participated in the 4 Ls activity, which highlighted the following:
- Liked: Collaboration, technical knowledge, and creative projects
- Lacked: Tech skills, weak foundations, and error messages
- Learned: Browser behaviour, wallet injection strategies, and encryption
- Longed For: Improved dev-ex, reliability, and new features
The action items from the session include:
- Waku team to use the voice channel more often
- Improve python bindings: Integrating this officially in the Waku roadmap will be review at a later stage, as our study of the market in 2024 put Rust and NodeJS as the most promising SDKs.
- Stabilize TWN and discuss stricter process for sandbox or new logos prod fleet: stricter js-waku/nwaku interop quality processes have been applied as part of nwaku release. Due to the commitment of providing a stable Qaku instance for IFT Town Halls and events, we will review the need of a dedicated fleet for Logos web apps.
- Review usage of js-waku in React with hooks: js-waku to take this item and review if specific work needs to be booked, especially with the ramp-up of Logos/internal web apps.
- Make it easier to connect implementations together: Alignment across the implementations is already planned with the Messaging API milestone. Work has started to include the concept of network presets to easily starts nodes targeting a specific network.
- Resolve UX issues, such as RLN membership: this is to be driven by the integration of RLN in IFT apps.
- Improve available examples of js-waku functionality: js-waku to review and at a minimum, empower the Waku chat/app team to build logos web apps.
Conclusion
The work done by the hackathon participants was very impressive, I was in awe of our ability to use Waku for audio calls, and the potential to make this in a decentralised manner.
Several of the projects are in line with what we need to do for Waku in the context of IFT and Status app, there are a lot of overlap and I will be discussed those further with the Status team.
We are planning to run two more internal hackathon in 2025, I am looking forward to see maturity improvement of our SDKs, as well as RLN usage, by then.
Congratulations to all the participants for trying out your ideas and putting them out there.
Finally, thank you to the panelists for taking the time to review the projects and providing feedback.
