Making Waku Development Leaner

Waku
,
6

Let’s dive into an example to help illustrate this.

A current goal is to replace go-waku with nwaku as the Waku implementation in Status apps.

This requires a multi-step process. We can approach this problem in two ways: a “fat” approach or a “lean” approach.

Fat Approach

A fat approach involves maintaining a feature branch of Status-go and proceeding with all necessary work for a cold turkey switch at a targeted version of the Status apps. However, this approach has several drawbacks:

  1. Long development time (6-12 months)
  2. Difficulty with dogfooding (can only dogfood from feature branch)
  3. Need to maintain a feature branch to rebase regularly
  4. High risk when the switch happens, as it’s an all-in-one approach

Lean Approach

We opted for a gradual rollout of nwaku in Status apps, which breaks down into the following steps:

  1. Status Desktop only, relay mode only, Waku core protocols only on Linux, Mac, and Windows.
  2. Add Light mode support.
  3. Add Mobile: build on iOS and Android.
  4. Move peer-to-peer reliability implementation from Go-Waku to Nwaku.

These steps are tracked under specific milestones:

light mode vs relay mode in Status Desktop settings

Lean vs Fat

Let’s review the decisions made that differentiate a lean vs non-lean (fat) approach.

Integrate nwaku in Status Desktop

Fat approach:

  • Expose the API of all Waku core protocols in libwaku, C bindings, and Golang wrapper.
  • Rewrite p2p reliability protocol to fully remove Go-Waku dependency.
  • Do a hard switch when moving to Nwaku, doing it all at once for desktop builds.

Result: A lot of time spent before a working binary can be handed over to CCs and users.

Lean approach

  • Focus on “relay mode” only and expose the bare minimal core protocols on the API: discv5, store, relay; peer exchange as client, filter as client, light push as client, are left for later.
  • Focus on core protocols and re-use Go-Waku’s p2p reliability implementation for now.
  • Add an abstraction layer so that it’s possible to compile Status-go with Nwaku or Go-Waku; no need to maintain a feature branch.

Result: A binary that is restricted in scope but usable, can be handed over to CCs and interested users early on.

Integrate Nwaku in Status Mobile

Fat approach:

  • Expose the remaining core Waku API and get Light mode working before trying to build on iOS and Android.
  • Implement p2p reliability protocols for resource-restricted devices in Nim.

Result: Takes more time to get mobile apps for dogfooding in the hands of CC. The Go-Waku/Nwaku duality remains for longer as the p2p reliability implementation needs to be moved from Go-Waku to Nwaku.

Lean approach:

Move in parallel:

  • Build Nwaku in Status-go for Android.
  • Build Nwaku in Status-go for iOS.
  • Expose Waku Core API for Light mode: peer exchange, light push, and filter as client.

Also, keep using go-waku p2p reliability protocol’s implementation

Result: Official switch to Nwaku can be done faster, without re-writing the p2p reliability code from Go to Nim.
We don’t block Android and iOS build on light protocol API work, we move in parallel and join at the end.

Summary

By aiming for a lean approach, where we descope (light protocols as client API, p2p reliability) and split work into shippable chunks (Desktop relay, then mobile, then p2p reliability in Nim), we can put Nwaku-based binaries in the hands of CCs and users earlier (Desktop in Q1/early Q2) to start dogfooding. This means that as we reach D-Day to switch (H2), we would have had several months of hardening the binaries.

A more fat approach, where nothing is descope, and all work is done as we go along, would delay dogfooding possibilities, increasing risk and decreasing confidence when the switch needs to happen.

2 Likes