Using Waku v2 Light Push to Cut Mobile Battery Drain in Chat Apps

Problem: constant gossipsub connections drain mobile batteries

Mobile chat apps that stay subscribed to a Waku Relay gossipsub mesh keep a persistent connection, repeatedly receiving all traffic for a topic even when no new messages arrive. This continuous radio use shortens battery life and increases data usage, especially on constrained devices.

Thesis: Light Push lets publishers hint availability so light nodes fetch only when needed

Waku v2 Light Push adds an optional hint channel. Publishers send a lightweight push hint to a light‑push server when they have a message for a topic. Light nodes register interest with that server, receive the hint, open a short‑lived connection to pull the message via Relay or Store, then go idle again. Propagation still uses the Relay mesh; the hint merely avoids keeping the light node in the mesh full‑time.

How Light Push fits into the Waku v2 stack

Waku v2 consists of three core services:

• Relay – gossipsub mesh that propagates messages.
• Store – optional persistent cache for historical queries.
• Filter – content‑topic based subscription.

Light Push does not replace any of these; it runs alongside them. A publisher that supports Light Push:

1. Publishes the message to the Relay mesh as usual.
2. Sends a push hint (a small protobuf‑encoded envelope) to a configured Light Push server.

A light node that enables Light Push:

1. Registers its interest (node ID and topics) with the Light Push server.
2. Waits for a hint; on receipt, opens a brief dial‑out to a Relay peer (or Store) to fetch the exact message.
3. Closes the connection and returns to a low‑power state.

Configuration example (pseudo‑command line)

Assuming you have the waku binary installed, run the publisher with Light Push enabled:

# Run on a server or CI node with network access
waku node \
    --listen-address /ip4/0.0.0.0/tcp/30303/http \
    --relay=true \
    --lightpush=true \
    --lightpush-server  \
    --topic /mychat/1

Run the light node (e.g., on a mobile‑simulated environment) with Light Push client mode:

# Run as a regular user; needs outbound TCP/UDP to the relay and to the light‑push server
waku node \
    --listen-address /ip4/127.0.0.1/tcp/0/http \
    --lightpush=true \
    --lightpush-server  \
    --topic /mychat/1 \
    --discovery=false   # optional: disable mDNS for a cleaner test

Where to run: Any host with the Waku v2 binary; publisher needs inbound port 30303 open for Relay gossip, light node needs outbound connectivity to the Relay mesh and the Light Push server. Permissions: No root required; just the ability to bind to the chosen ports and open outbound sockets. Expected checks: After starting both nodes, use a tool like wakucli pubsub topics on the light node to see that it reports zero active gossipsub subscriptions for /mychat/1 while still receiving messages when a push hint arrives. Risks: If the publisher does not send a push hint, the light node will not be notified and may miss messages unless a fallback polling mechanism is implemented.

Worked example: mobile chat client

1. Alice’s mobile app starts as a light node, registers interest in topic /mychat/alice with the Light Push server. 2. Bob sends a new chat message. His app (the publisher) publishes the message to the Relay mesh and simultaneously pushes a hint to the Light Push server containing the message CID and the topic. 3. The Light Push server forwards the hint to Alice’s registered node ID. 4. Alice’s device receives the hint, wakes its radio, opens a short TLS‑encrypted stream to a Relay peer, fetches the message by CID, verifies the signature, displays the chat bubble, then closes the stream and returns to idle. 5. Throughout the interval between messages, Alice’s device maintains no gossipsub subscription for that topic, reducing inbound packets and radio wake‑ups.

Trade‑offs and limitations

• Latency: There is a small delay between message publication and hint delivery (network round‑trip to the Light Push server) plus the fetch round‑trip. For real‑time use cases where sub‑second latency is critical, full Relay subscription may still be preferable.
• Publisher dependency: Light Push only works if the publisher implements the hint step. Legacy publishers that only use Relay will leave light nodes unaware unless they fall back to polling.
• Privacy consideration: The Light Push server learns which topics a node is interested in (via registration) and can correlate hints with specific nodes, revealing interest metadata that a passive gossipsub subscription would not expose.
• Version sensitivity: The exact protobuf layout of push hints and the interaction with Relay/Store can change between Waku v2 minor releases. Always check the release notes of the binary you are using.

Actionable closing

To decide whether Light Push suits your mobile messaging product:

1. Set up a test publisher and light node using the configuration snippets above.
2. Enable Light Push on both sides and run a simple chat loop.
3. Monitor the light node’s active gossipsub subscriptions (e.g., wakucli pubsub subscriptions) – you should see none for the test topic while still receiving messages.
4. Measure battery impact with a profiling tool (e.g., Android Battery Historian) comparing Light Push mode against full Relay subscription.
5. If latency is acceptable and publisher support is guaranteed, roll out Light Push in production; otherwise keep a fallback polling path for older clients.

By shifting from constant mesh presence to on‑demand fetching guided by push hints, you can significantly cut unnecessary radio usage while preserving the reliability of Waku’s Relay‑based delivery.