Improve DevEx: API, TWN, Metrics, Docs §

Estimated date of completion: 31 Aug

Resources Required for 2025H2:

• 2 js-waku engineers
• 1.5 nwaku eng
• 1 core research for 1 month
• 1 app chat eng for 1 month

Proceed with a number of improvements to the developer experience on Waku, for both internal and external purposes. This includes:

• Improving The Waku Network reliability for Logos apps and other web apps
• Simplifying the Waku API
• Measuring Waku usage across all integrations
• Review and setting strategy for Waku documentation
• Testing quic as new transport

Strategic Objective §

Logos Movement Community Enabling via Dev-X + Telemetry

FURPS §

See deliverables.

Risks §

Risk	(Accept, Own, Mitigation)
Define collaboration with BI for metrics	Communicate
Browser reliability is a multi-prong problem (js-waku/libp2p, nwaku/nim-libp2p)	Strong collaboration
No “documentation” expert or dedicated resources	outsource help from doc experts in IFT, focus on setting guidelines for all Waku CCs to follow

Deliverables §

Global Network Metrics §

Owner: App/Chat Dev

Feature: Network Metrics Tracker

FURPS:

• all

Checklist:

• Specs: link to specs and/or API definition
• Code: link to GitHub issues/PRs/Epic
• Dogfood: link to dogfooding session/artefact
• Docs: links to README.md or docs.waku.org (TBD)

Scalable Data Sync in Browser §

Owner: js-waku

Feature: SDS

FURPS:

• all

For S2. For Web apps as a developer library.

Checklist:

• Specs: link to specs and/or API definition
• Code: link to GitHub issues/PRs/Epic
• Dogfood: link to dogfooding session/artefact
• Docs: links to README.md or docs.waku.org (TBD)

Implement Light Push Error codes in The Browser §

Owner: js-waku

Feature: Light Push

FURPS:

• F4. Supports comprehensive error codes for various failure scenarios.
• U4. Provides descriptive error messages in responses.
• R2. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).

For S2. Browser as client Spec delivery not included.

Checklist:

• Specs: link to specs and/or API definition
• Code: link to GitHub issues/PRs/Epic
• Dogfood: link to dogfooding session/artefact
• Docs: links to README.md or docs.waku.org (TBD)

Introduce Waku API in the Browser §

Owner: js-waku

Feature: Waku SDK

FURPS:

• F1. Setup, start and stop a Waku node.
• F2. Support edge node operation mode.
• F4. Does automatic peer discovery based on the node platform and operation mode.
• F5. Returns health and connectivity information using proven heuristics.
• F6. Previously discovered peers are persisted across restarted, and potentially used for future connections.
• U1. When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay).
• U2. Disconnection detection and recovery, and other peer management matters are automatically handled.
• U3. Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation.
• U4. Developers pass and receive data to the API in types native to the wrapping language.
• U5. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed.
• U6. Developers only need to handle errors in cases of irretrievable failure requiring end-user action. Internal errors are not bubbled up if they can be recovered internally.
• R1. Sends a message using peer-to-peer reliability (service node redundancy, optional store confirmation)
• R2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping)

For S3. Browser; distribution via npmjs.com.

Checklist:

• Specs: link to specs and/or API definition
• Code: link to GitHub issues/PRs/Epic
• Dogfood: link to dogfooding session/artefact
• Docs: links to README.md or docs.waku.org (TBD)

Introduce Waku API in nwaku §

Owner: nwaku

Feature: Waku SDK

FURPS:

• F1. Setup, start and stop a Waku node.
• F3. Support relay node operation mode.
• F4. Does automatic peer discovery based on the node platform and operation mode.
• F5. Returns health and connectivity information using proven heuristics.
• F6. Previously discovered peers are persisted across restarted, and potentially used for future connections.
• U1. When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay).
• U2. Disconnection detection and recovery, and other peer management matters are automatically handled.
• U3. Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation.
• U4. Developers pass and receive data to the API in types native to the wrapping language.
• U5. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed.
• U6. Developers only need to handle errors in cases of irretrievable failure requiring end-user action. Internal errors are not bubbled up if they can be recovered internally.
• R1. Sends a message using peer-to-peer reliability (service node redundancy, optional store confirmation)
• R2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping)

For:

• S1. Nim library; import via git path.
• S2. Golang library; available on pkg.go.dev.

Checklist:

• Specs: link to specs and/or API definition
• Code: link to GitHub issues/PRs/Epic
• Dogfood: link to dogfooding session/artefact
• Docs: links to README.md or docs.waku.org (TBD)

Review Documentation and Define Guidelines §

Owner: core research

(No FURPS)

• Review the current developer documentation
  • And contributor doc
• Define a guideline for Waku teams to
  • Minimum requirements to consider “doc done” for any future deliverable
  • How to contribute to documentation: location, format
• Setup an initial structure to enable the guideline

Trial QUIC §

Owner: nwaku

Feature: nwaku

FURPS:

• S4. QUIC transport is supported for peer-to-peer message routing connections.

Checklist:

• Specs: link to specs and/or API definition
• Code: link to GitHub issues/PRs/Epic
• Dogfood: link to dogfooding session/artefact
• Docs: links to README.md or docs.waku.org (TBD)

Optimise Browser Bootstrapping §

Owner: js-waku

Feature: js-waku

FURPS:

• R1. From an operating state, a node can resume transmitting messages within 1 second after disconnection; in a network with 1 bootstrap node, 100 service nodes and 500 browser nodes (Vac-DST)
• P1. From a cold start, a node can start transmitting messages within 5 seconds; in a network with 1 bootstrap node, 100 service nodes and 500 browser nodes (Vac-DST)

Checklist:

• Specs: link to specs and/or API definition
• Code: link to GitHub issues/PRs/Epic
• Dogfood: link to dogfooding session/artefact
• Docs: links to README.md or docs.waku.org (TBD)