Meshtastic (off-grid mesh messaging) for the community library — and the BLE support it needs

[ToBeMoreHuman]

Hi team — following the external-APK / trust-tier discussion in #93, I'd like to put a Meshtastic tool forward for the community tool library, and flag the one SDK piece that would let it ship as a first-class, curated tool rather than a sideloaded tier-4 APK.

The tool: an off-grid mesh-messaging client (Meshtastic). It's a strong ethos fit for Light — decentralized, no-cloud, no-carrier, privacy-first, intentional comms. The phone talks to a small LoRa radio node; ~90% of users connect over BLE (the nRF52 nodes). I'd love this to live in the curated library so an LP3 owner can add it in one tap — signed by Light, using the Light UI kit — rather than every user having to enable dev mode and sideload an arbitrary APK.

What's needed to make it curated-ready: today the SDK blocks getSystemService/BluetoothAdapter and allow-lists no Bluetooth permission, so an SDK-built tool can't reach a node over BLE. I know I could ship it now as a tier-4 sideloaded APK per #93 — but that skips curation, the UI kit, and Light's signing, which is exactly the reach I'd want for a tool like this. For a curated version, the SDK would need a sanctioned BLE/GATT client primitive, in the spirit of LightQrCodeScanner / LightFileShare.

Minimum GATT surface a Meshtastic client exercises:

Capability	Why it's needed
Scan/filter by arbitrary service UUID	discover nodes advertising 6ba1b218-15a8-461f-9fa8-5dcae273eafd
Connect + bond/pair with a PIN	Meshtastic requires bonding (fixed 123456 or an on-device random PIN)
Write to a characteristic	send ToRadio protobufs
Read a characteristic repeatedly	drain the FromRadio FIFO until empty
Subscribe to notifications (CCCD)	FromNum signals "new data, go read"
MTU negotiation (up to ~512)	throughput; degrades gracefully to 23 if unavailable

The critical piece: bonding/PIN. A BLE surface that supports scan/read/write/notify but not PIN bonding wouldn't connect to Meshtastic at all — so if there's a phased rollout, a PIN-entry flow (perhaps mirroring the RequestPermissionComponent pattern) matters as much as the GATT ops themselves.

Permissions to allow-list: BLUETOOTH_SCAN (with neverForLocation so it doesn't drag in location), BLUETOOTH_CONNECT (Android 12+ split; LP3 is API 34).

Why it's not niche: a general GATT client also unblocks the Tesla phone-key tool (#71) and complements the Bluetooth-keyboard interest in #92 — it's platform plumbing that pays off across several library-worthy tools.

Happy to help make this concrete — I can share a written breakdown of exactly which GATT operations a real Meshtastic peripheral exercises (scan filter → PIN bond → config drain → FromNum notify loop → protobuf parse), so the required BLE surface is unambiguous. Thank you for your time and effort!

[dupontgu]

I think A) we definitely want to support BLE and B) you're on the right track with how you're thinking about it. Since bonding w/ a pin would require a "system" window, we'd want to follow the permission model as you mentioned and pass that responsibility over to the server/LightOS. It's unclear to me at the moment if any of the other functionality would have to live on that side as well to make that make sense / prevent any unwanted Android UI. This might be a littttle tricky to work on in the short term since the emulator's not gonna give a great BLE experience.

Would be helpful to get the exact requirements for Meshtastic, yeah.

If anyone wants to take a swing at BLE, file an issue, tag me, and reference this discussion. I would suggest pulling a kotlin BLE lib into :sdk:client (probably Kable or the nordic one) and then just expose the functionality needed through a Light... api for the tools to use. We can leave bonding on the client side for now, I think.

[cmg-ops]

I love this idea!!! please make it happen I am all for it!

[ToBeMoreHuman]

I will be purchasing a Meshtastic node to run some tests. Hopefully once the Tier 4 side loading on the Light Dashboard is up and running (I think I saw it should be ready by the end of the month), I will see how the two communicate using my real LP3.

I'll keep you posted!

[wsturgiss]

Personally I only use meshtastic over wifi. I found bluetooth usage to be too finnicky with dropped connections and reconnecting being annoying. Still a good idea to support the feature though, IMO