Virtual Offsite Recommendations: Waku Web Apps

Team: Gabriel, Vaclav, Pedro

Over our virtual offsite session, our team reviewed the current state of Waku web app development, the assumptions we’re building on, and the direction we want to take.

We agreed that our main working assumptions are:

  • Waku network is functional and stable.

  • Messaging API is defined and usable.

  • Users and developers value privacy and censorship resistance.

Key discussion points

We looked at the unique value Waku can bring to web apps, such as offering a browser-native, P2P alternative to centralized backends. We talked about common architectural patterns emerging from our work, the need for better persistent storage via Codex, and how to identify the right target audiences: from Logos community members to hackathon builders.

Challenges came up around UX, shifting from centralized to P2P architecture, ensuring product-market fit, and maintaining apps over time. We also stressed the importance of keeping code open, making it easy for others to contribute, and setting a standard “deliverables” list for any app we release.

Recommendations moving forward

  • Keep building apps: new ideas, Web2 clones, Web3 improvements, and niche use cases (activism, whistleblowers).

  • Derive and document architectural patterns, especially for identity, state sync, and decentralized persistence.

  • Integrate persistent storage with Codex for complete use cases like large file transfer and history.

  • Maintain existing apps (Quaku, Opchan, WhisperBox, Trollbox) and keep them aligned with Waku updates.

  • Define standard deliverables: accessible deployment, public repo, spec, forum post, demo video, social posts, and inclusion in the Awesome Waku Repo.

  • Encourage external contributions with “good first issues” and clear entry points.

  • Prioritize based on recurring patterns before creating libraries or abstractions.

  • Do outreach and surveys with communities (Logos, Privacy Now, Railgun, etc.) to identify real needs.

  • Use content formats like live coding streams to show integrations and attract developers.

This direction should help us grow a stronger ecosystem around Waku, make it easier for newcomers to contribute, and keep our apps relevant and maintained.

2 Likes

@Zoltan regarding the lite Protocol tester: do you monitor run results?

How much effort would it be to make it run on waku.sandbox, and use websocket (client) instead of TCP for those runs?

I wonder if we should get an ENS domain and deploy all apps on a subdomain with IPFS + eth.link to really show case the unstoppable aspect of dapps

Yes! something I definitely want to see. I would encourage more black-on-white writing of needs on Waku/js-waku/Codex you see.

1 Like

@fryorcraken Honestly I look at status.prod runs rarely. Maybe an possible summary to be send somewhere as an extension needed.

To set up a infra run for waku.sandbox is quite easy. It is even possible to just deploy a new image configured to run on waku-sandbox instead of status-prod.

I’m not sure if we ever tried ws/wss between nwaku nodes… we need to examine this option. But I remember during the offiste in Split we discussed something similar with @weboko to replicate LPT functionality to js-waku, exactly to test and dogfood edge mode from browser.

2 Likes