Waku API FURPS

(proposing to move away from "messaging api" to avoid confusion)

Functionality

Setup, start and stop a Waku node.
Support edge node operation mode.
Support relay node operation mode.
Does automatic peer discovery based on the node platform and operation mode.
Returns health and connectivity information using proven heuristics.
Previously discovered peers are persisted across restarted, and potentially used for future connections.

When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay).
Disconnection detection and recovery, and other peer management matters are automatically handled.
Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation.
Developers pass and receive data to the API in types native to the wrapping language.
By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed.
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.

Sends a message using peer-to-peer reliability (service node redundancy for edge, optional store confirmation)
Receives messages using peer-to-peer reliability (service node redundancy for edge, periodic store query, periodic filter ping)