[RFC] Constellation: Decentralized Mesh Networking for Multi-Flipper Coordination

[eaglecrat]

Summary

Proposal for a lightweight mesh protocol ("Constellation") enabling multiple Flipper One devices to coordinate without infrastructure. Use cases: swarm diagnostics, distributed RF mapping, collaborative badge emulation.

Scope

• Mesh Bootstrap: Devices discover peers via BLE/Sub-GHz broadcast
• State Sync: Minimal gossip protocol for shared telemetry and task distribution
• Role Election: Dynamic leader/follower without central coordinator
• Security: Per-session ephemeral keys, no persistent pairing

Spec

→ https://github.com/eaglecrat/-flipper-one-proposals/blob/main/constellation/constellation-mesh-protocol.md

Questions

1. Is there existing mesh/BLE mesh work in the roadmap?
2. Preferred transport: Sub-GHz or BLE?
3. Firmware feature or external application?

Risk

• Low device risk — transport layer only
• Can start as external app
• Stateless, ephemeral, no persistent storage

— ΩV

[alchark]

There is no sub-GHz radio in the Flipper One, but the MT7921 Bluetooth module we use supports BLE mesh. WiFi mesh is also an option (and perhaps a better one due to longer range, bandwidth and widespread support).

If anyone is willing to produce a proof of concept with an actual real world use case, that would be welcome. My strong preference here would be to rely on the standard stack as much as possible, e.g. use IP based transport over standard mesh protocols, and concentrate any development effort on actual usecase oriented functionality (as opposed to low level plumbing).

Right now the Flipper Devices team is not actively developing any mesh functionality

[eaglecrat]

@alchark Thanks for the detailed feedback.

Revisions based on your input:

1. Transport pivot: Dropping Sub-GHz from the proposal. Focusing on MT7921-native options: BLE Mesh (standard Bluetooth Mesh profile) and 802.11s WiFi mesh.

2. Standard stack preference: No custom CBOR wire format. Using IP-based transport over standard protocols:

   • WiFi mesh → 802.11s + batman-adv or standard Linux mesh
   • BLE mesh → Bluetooth Mesh model layer with standard provisioning

3. Use-case oriented: Instead of building low-level plumbing, the PoC would focus on a single real-world scenario: distributed RF environment mapping — multiple Flipper One devices in a room auto-discover each other, share RF sweep data, and produce a unified heatmap on the host.

4. Team not actively developing mesh: Understood. This would be a community-driven module that plugs into the existing Linux networking stack without requiring core team bandwidth.

Would a PoC scoped to "WiFi mesh for RF data sharing between 2–4 devices" be an appropriate consideration? Or do you prefer BLE Mesh for lower power?

— ΩV

[alchark]

WiFi sounds good. It’s more established, there are more frequency bands available out of the box, and it’s longer range than Bluetooth.

For low power operation something like LoRa would likely be better than either of these, but that requires a separate hardware attachment (no built in LoRa in Flipper One)