TL;DR
- Layer separation for public facing vs low level: Waku Core, Waku API, App API(s)
- Public mentioning only for public facing API’s: give one option, e.g. Chat API
- Target platform presence is a MUST: Go, Rust, JS (Node & Browser)
- Manage expectations and be clear: rate limiting in the network, local-first approach, privacy, bandwidth consumption, limited scalability
Problem statement
Adoption is low and used primarily by Status, Railgun and The Graph. We conclude that this is partially related to the problems that project developers face while integrating Waku into their code bases. Most commonly seen are: lack of understanding of consequences of using P2P stack instead of centralized client-server architecture; limited understanding of development patterns in P2P way, e.g local-first approach; high entry point with integrating Waku into project’s code base due to different limitations of present protocol APIs (no retry in LightPush out of the box, no recovery of Filter subscriptions, Store protocol limitations in a public network).
Recommendations
- Layer separation for public facing vs low level: Waku Core, Waku API, App API(s)
It is critical to distinguish between what is publicly available for external consumers and what is not. For that we recommend the following layers of Waku APIs: Waku Core, Waku API, App API(s).
Waku Core: private, meant to be used for core development of the Waku protocol layer and have implementations close to RFCs and specs.
Waku API: public, set of API that addresses general problematic points for outside consumers such as Send and Receive functionality with retries, connection and peer management that addresses availability in the network.
App API(s): public, higher order functionality that is meant to be used by projects and addresses their specific needs, can include: identity management, encryption, chat abstractions.
- Public mentioning only for public API’s: give one option, e.g. Chat API.
To mitigate confusion we MUST limit our proposition to only APIs that are ready to be consumed by projects from the start and those are Waku API and App API(s). The option we propose is only to communicate about one that is suitable for consumption, though may vary by use case.
- Target platform presence is a MUST: Go, Rust, JS (Node & Browser)
We must ensure presence on projects’ main target platforms and smooth experience there. For that we derive different points such as: simple dependency management and package distribution, ease for building right from the start.
Simple dependency management and distribution depends on the language. We must ensure presence on crates, npm. We want it to be something like:
go get [github.com/waku-org/chatsdk](http://github.com/waku-org/chatsdk)
npm i @waku/sdk
Ease for building must be ensured with minimal configuration and opinionated defaults and requested API that has needed functionality embedded: sending and receiving with reliability, encryption tools, ambient connection management:
w := waku.New({
...
})
if err := w.Start(); err != nil {
panic("failed to start waku", err)
}
defer w.Stop()
w.Send("0xabc...", "hello")
go w.OnReceive(func(msg WakuMessage) {
fmt.Printf(msg)
...
})
Since Nim is the language of choice for IFT, we agree that implementations should be provided in both Nim and TypeScript. Support for other languages should be enabled through bindings to the Nim implementation.
- Manage expectations and be clear.
As mentioned in the Problem statement - many developers are not aware of tradeoffs that are coming with P2P infrastructure and SDKs. It is our duty to articulate what is possible and what not with providing clear documentation, simple yet useful examples and main benchmarks with limitations.
This includes: being clear on limitations of RLN and its time consumption (sync node, generate proof, need of RPC endpoint); public network’s Store availability limitations and need for local-first approach with its requirements; if superior privacy is needed - its burden on time to initiate message exchange etc; requirements on bandwidth; time to bootstrap a node for application to function. For TWN we need to be clear what benefits and drawbacks there are for projects: cost of TWN vs their network setup.
Links
