pm/draft-roadmap/improve_devex_api_twn_metrics_docs.md

Improve DevEx: API, TWN, Metrics, Docs

Estimated date of completion: {Enter date}

Resources Required for 2025H2:

• {roles and % application to it}
• {external services consumed (Vac/IFT)}
• {infrastructure}

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

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)

Improved Browser Bootstrap

Owner: js-waku

Feature: TODO see https://github.com/waku-org/pm/pull/308

FURPS: TODO

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)

Waku Sync

Owner: core research

Feature: Store Sync

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)

Define and Implement Light Push Error codes in nwaku

Owner: nwaku

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).
• R3. 80% message transmission success rate on live Status network (service node from both Status Desktop and fleet Waku instances)

For S1. Linux amd64 CLI as service node Includes spec delivery

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 API

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.
• 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.
• 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

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 API

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.
• 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.
• 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; used by chat SDK
• S2. Golang library; used by status-go

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 follow when contributing to documentation
• Setup an initial structure

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)