Feature Request: Automatic Bluetooth - Nostr Gateway Node for Internet Blackout Scenarios #1021
Description
The whitepaper already describes a Gateway Peer architecture (Mesh → Gateway → Nostr Relay → Remote Gateway → Remote Mesh), including a sequence diagram and a note that this would be an "optional module." The dual transport layer (Bluetooth mesh + Nostr) is implemented. But currently, each device only selects between Bluetooth and Nostr for its own messages - no device relays other peers' messages across the transport boundary.
What's missing: When a device has internet access, it should be able to automatically relay nearby offline peers' Bluetooth mesh traffic to/from the Nostr network - acting as a bridge between the two transport layers.
The Idea
When a device detects internet connectivity (Wi-Fi, cellular or satellite), it becomes a gateway node that:
- Receives messages from the local Bluetooth mesh (arriving via multi-hop relay from offline users)
- Forwards them to the Nostr relay network without breaking E2E encryption
- In reverse: pulls Nostr messages destined for local peers and injects them into the Bluetooth mesh for hop-based delivery
Why This Is Urgent/Necessary
During Iran's recent internet blackout (January 2026), Bitchat saw a surge in downloads. But some users still had connectivity through Starlink. With this feature, even one Starlink-connected device in a neighborhood could bridge the entire local mesh to the outside world, every offline user's messages would hop through Bluetooth until they hit that gateway, then flow globally via Nostr.
The need is real and recurring !!
Implementation considerations
- Opt-in: Gateway mode should be toggleable (battery/bandwidth cost)
- Deduplication: Multiple gateways in one mesh shouldn't publish the same message to Nostr repeatedly (message IDs could handle this)
- Loop prevention: Messages bridged from mesh → Nostr → mesh must not re-enter the originating mesh
- Transport conversion: The gateway needs to wrap Noise-encrypted BLE payloads into Nostr events (and reverse), maintaining the inner encryption - the whitepaper's sequence diagram already outlines this conversion step
- Privacy: Gateways relay encrypted payloads. Metadata exposure at the bridge point should be minimized
Related issues: #165: Needs internet relay
Also #180 and #508 (LoRa bridge proposals - similar concept but hardware-dependent; this proposal leverages the existing Nostr layer with no extra hardware)
The architectural pieces (dual transport, message routing, store-and-forward, Nostr relay integration) are already there. This feature would connect them to make the mesh truly resilient in the exact scenarios Bitchat was built for.