Lightpush or Relay: Selecting a Default Publish Path for Bandwidth-Constrained Waku v2 Light Nodes

Question

A Waku v2 light node on a mobile or metered connection must choose between two documented publishing mechanisms. Lightpush submits messages to a server that relays them, reducing outbound bandwidth and peer connections, while Relay gossips directly, avoiding trust concentration in a single operator and hiding the publish origin from any one server. The specifications describe both paths but do not mandate a default for light nodes, leaving the privacy-versus-resource balance as an open design decision.

Client behavior varies across implementations, and the practical choice depends on Lightpush server availability, service-node incentives, and peer-exchange results within a given shard. Because Waku v2 components evolve, any assumption about defaults, fallback chains, or protocol identifiers should be verified against the specific client version in use.

For a light node targeting intermittent connectivity and low data usage, which publishing path should serve as the default?

If Lightpush is preferred, how should the client handle absence of a server for a content topic or shard?

If Relay is preferred, what minimum peer and bandwidth budget keeps publishing viable?

Tasadduq Burney · Answer

Answer the Core Question First
There is no specification‑mandated default for light nodes. The choice between Lightpush and Relay should be driven by the node’s operational profile and the user’s privacy tolerance.
Lightpush as Default – When It Makes Sense

Out‑bound traffic is limited to a single HTTP/HTTPS request to a lightpush server.
Peer‑to‑peer gossip is avoided, reducing radio wakeups on intermittent or metered networks.
Accepts that the server sees the sender’s IP and message metadata; privacy trade‑off is explicit.

Relay as Default – When It Makes Sense

Full peer‑to‑peer gossip keeps publish origin hidden from any single operator.
Requires maintaining at least one stable libp2p connection within the shard.
Increases outbound data because the node must send the message to each peer in the gossip fan‑out.

Handling Absence of a Lightpush Server

Queue Locally: Store the message in a local buffer until a server becomes reachable.
Discovery Attempt: Periodically query the network for lightpush advertisements for the target content topic or shard.
Conditional Fallback: If no server is found after a configurable back‑off period, offer the user a choice:

Stay offline – return a transient "unavailable" status.
Switch to Relay – provided the node has at least one stable peer and the user consents to higher data usage.

Relay Viability – Minimum Requirements

Maintain a minimum of one stable peer in the relevant shard.
Ensure the node can sustain repeated outbound gossip of the message size without exceeding the user’s data budget. Exact byte counts are implementation‑specific; test against the target client version.

Verification Steps for Your Deployment

Check the client’s configuration schema for any existing publish_path defaults.
Confirm the lightpush discovery mechanism and the identifiers used for content‑topic mapping in the client version you plan to deploy.
Run a small test against a local Waku v2 network to measure outbound bytes for both Lightpush and Relay under the same message payload.

Missing Diagnostic Detail
To refine the recommendation for your specific setup, please provide the Waku v2 client version** you intend to use and the target shard** or content topic. These details influence server discovery, protocol identifiers, and the practical bandwidth cost of each path.

Lightpush or Relay: Selecting a Default Publish Path for Bandwidth-Constrained Waku v2 Light Nodes

1 answer

Answer the Core Question First

Lightpush as Default – When It Makes Sense

Relay as Default – When It Makes Sense

Handling Absence of a Lightpush Server

Relay Viability – Minimum Requirements

Verification Steps for Your Deployment

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments