1 of 15

Virtual offsite:

Target API and architecture

Pablo, Ivan, Zoltan, Sasha

2 of 15

Waku crowds

  • Node operators - out of scope for this presentation
    • Nwaku-compose is their SDK, it works
    • Apps can be build on top by using REST API
  • Application builders are the focus of this presentation
    • We make no assumptions about their background knowledge of the Web3 domain
    • We assume most project expect and wants to provide web2 experience

3 of 15

What is the point of this presentation

Waku is a set for protocols for decentralized messaging FOS implemented as a library. It is not very popular, reasons could be:

1. Nobody cares that much about decentralized messaging given the drawbacks.

2. Some other competing project(s) are already being used for this purpose.

3. Waku is difficult to understand and integrate

4. Need more marketing/exposure

4 of 15

What is the point of this presentation

Waku is a set for protocols for decentralized messaging FOS implemented as a library. It is not very popular, reasons could be:

1. Nobody cares that much about decentralized messaging given the drawbacks.

2. Some other competing project(s) are already being used for this purpose.

3. Waku is difficult to understand and integrate

4. Need more marketing/exposure

5 of 15

Assumptions

  1. Everyone wants Web2 like experience
  2. Web3 solutions are complex by design
  3. No one cares about the complexity of decentralization — they just want to use it.
  4. Projects want ready-made solutions — APIs and SDKs.

6 of 15

What we want

North Star: projects grow to depend on Waku — sustainably.

  • Make it easy to integrated and clear on expectations of how Waku will behave.
  • Reducing Waku integration friction and boosting adoption in project architectures.

7 of 15

What was done

  • p2p-reliability spec
  • Messaging API draft
  • Waku API and suggestions draft
  • Transition to an event-based approach
  • Chat SDK repo

8 of 15

Existing solutions

Note: Waku is unique in that is a general-purpose

  • XMPT SDK
  • Matrix SDKs
  • Reown / WalletConnect
  • Nym

​

We looked at them as examples of something we might want to build.

9 of 15

Directions

  • Highly opinionated, convenient SDKs
    • Network, mode
    • Chat, Wallet
  • Event-based approach
  • Layered architecture of SDKs with defined specs

​

10 of 15

Challenges we take

We assume everyone wants web2 experiences, but…

…in comparison we provide:

  • Account free abstractions
  • Host yourself
  • Privacy & ownership
  • Public available solutions (OSS by default)

+ need to draw attention on domain specific challenges:

  • Delays
  • Time to connect / bootstrap
  • Design to reliability

​

11 of 15

Waku Core SDK

  • Depends: -
  • Targets: Waku SDK
  • Contributors: nwaku, js-waku
  • Features: core protocols, main primitives

12 of 15

Waku SDK

  • Depends: Waku Core SDK
  • Targets: Application SDK(s), projects
  • Contributors: nwaku, js-waku, app sdk
  • Features: usable protocols, protocol reliability strategies, send / receive

13 of 15

Application SDK(s)

  • Depends: Waku SDK
  • Targets: projects
  • Contributors: nwaku, js-waku, app sdk
  • Features: identities, chat, application reliability

14 of 15

15 of 15

Distribution

  • Release cadence, dogfooding, feedback
  • No pre-compiled artifacts for now
  • Separate repositories instead of mono-repository
    • Nwaku one repo
    • Application SDK(s) another, no decision if mono-repo or not
  • Packaging: npm, crates, nimble, etc.