Running fiber on Android mobile: 24/7 availability and watchtower delegation

Context

We are integrating Fiber into a React Native mobile wallet (Android + iOS). For Android, we plan to compile fiber-lib as a native Rust library (with --features sqlite for storage) and bridge it into the app via FFI/JSI. This is an alternative to the WASM path (fiber-wasm + fiber-js) to get native threading, proper Tokio runtime, and SQLite persistence.

The Problem: Android Kills Background Processes

On Android, the OS aggressively kills background processes to reclaim memory and battery. Even with foreground services, there is no guarantee the app stays alive 24/7. This means:

1. The fiber node running in-app will be killed periodically
2. The P2P connections will drop
3. The node cannot sign commitment_signed while killed
4. Incoming HTLCs will expire if the node stays offline too long

We understand that ReestablishChannel handles reconnection well (sub-second in the happy path), and gossip catch-up resumes after reconnect. But the real risk is HTLC expiry during the offline window.

Watchtower as Partial Mitigation

Fiber's standalone_watchtower_rpc_url allows delegating channel monitoring to a remote third party. This covers:

• Detecting cheating (counterparty broadcasts an old commitment)
• Settling force-closed channels
• Claiming HTLCs that expired while we were offline

However, the watchtower currently requires the local_settlement_key (a Privkey) per channel, as seen in CreateWatchChannelParams. This means:

• The third-party watchtower holds a per-channel private key
• It's a trust-based relationship (the watchtower could sign settlement to an address it controls)

Questions for the Team

1. Has the team considered the mobile/Android use case? Is anyone running fnn or fiber-lib on Android devices? What's the experience?

2. Foreground service viability: If we register an Android foreground service with a persistent notification, does the Tokio runtime + P2P stack stay alive reliably? Are there known issues with network state changes (WiFi ↔ cellular)?

3. Watchtower delegation for mobile:

   • Is the standalone_watchtower_rpc_url path the recommended approach for mobile?
   • The local_settlement_key trust requirement — are there plans to make the watchtower work with only public data, or at least limit what the watchtower can do with the key?
   • For the WASM build (fiber-wasm), there's a related issue (#1410) about watchtower auth not being wired through. Would native mobile face the same problem?

4. Gossip and storage on mobile:

   • What's a realistic estimate for the network graph size on CKB mainnet?
   • The gossip store keeps 4 weeks of history. How large can this grow (rough order of magnitude)?
   • Is there a "pruned" or "light" mode for mobile where we don't need the full routing graph?

5. Offline receiving: Since LN requires the recipient to sign commitment_signed, a mobile node fundamentally cannot receive payments while killed. Is there any ongoing work or design discussion around:

   • A receive-only sub-key that could be delegated to a third party?
   • A ChannelSigner trait abstraction that would allow remote signing?
   • Any other mechanism to decouple key holding from node operation?

6. Suggested mobile architecture: Do you see a mobile fiber node as viable long-term, or would you recommend a hybrid approach (mobile RPC client connecting to a remote always-online fiber node, similar to CCH standalone mode)?

What We've Explored

We documented three integration approaches here:

1. Mobile native full node + delegated watchtower (Rust native, SQLite, FFI into React Native)
2. Hosted LSP (equivalent to Breez/Greenlight: server runs node, device signs remotely)
3. Hybrid RPC (mobile RPC client connecting to remote fiber node)

We see Approach 1 as the most decentralized but have concerns about the 24/7 issue. Any guidance would be appreciated!