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

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?