A few weeks ago, I started experimenting with something I wasn't even sure would be practical: live audio/video communication between phones entirely over Bluetooth.
No internet, SIM, accounts or servers.
The idea came during the internet shutdowns around student protests in India. Apps like Bitchat demonstrated offline messaging, and I wanted to see whether we could go beyond text.
That experiment became MeshLive, a free and open-source Android and iOS project.
I've just released v0.3.0-beta, and quite a bit has changed since the first public build.
What's new?
Audio-only broadcasts: Live audio uses far less Bluetooth bandwidth than video, can reach further under suitable conditions, and can continue with the screen off.
Better calls: Voice calling now has proper ringing, answer/decline notifications and lock-screen handling.
Android ↔ iPhone: Devices running MeshLive can discover each other and communicate across platforms.
Privacy improvements: Discovery identifiers rotate every 15 minutes. Unknown callers initially see a temporary identity rather than your contact identity.
More reliable streaming: Improvements to slower Bluetooth links, reconnections and the overall UI.
There's still support for two-way voice/video calls and live broadcasts that nearby phones can relay onward.
The part I underestimated
Bluetooth bandwidth.
Getting usable video over one Bluetooth connection is already tricky. Relaying it to more phones introduces additional bandwidth and latency constraints.
The other challenge is Android itself. Different manufacturers, chipsets and OS versions can behave surprisingly differently.
I've now tested the project on seven Android phones and an iPhone 16 Plus, but that's still nowhere near enough coverage.
Why I'm open-sourcing it
I don't think something like this can become genuinely useful through testing on just my own phones.
It needs people trying different device combinations, reporting issues, improving Bluetooth compatibility and reviewing the implementation.
And I want to be clear: this is still an experimental beta. Performance varies, some functionality remains unfinished, and the security hasn't been independently audited. Please don't rely on it for safety-critical communication.
Try it
Android APK + source: https://github.com/MeshLive/meshlive-android
Early iOS implementation: https://github.com/MeshLive/meshlive-ios
If you have two phones, try a call or stream without internet. I'd especially appreciate reports containing the phone models, Android/iOS versions and what worked or failed.
Contributions and technical feedback are welcome.
Top comments (13)
The rotating discovery identifiers are a nice touch. Most hobby mesh projects leave a static broadcast name that effectively becomes a tracking beacon, so expiring it every 15 minutes is a real privacy win. I am curious how the cross-platform discovery handshake works between Android and iOS, given how differently the two OSes treat background Bluetooth advertising.
Thanks! yeah the cross platform discovery was actually one of the trickier parts because ios is much more restrictive with bluetooth advertising.
On android i can broadcast a custom 22 byte announcement using manufacturer data, but ios only lets apps advertise a name and service uuids. So i ended up packing the entire iphone announcement into a single 128 bit uuid. It contains a magic marker, version, announcement type (call/stream/viewer), device id, transport, codec and some routing info.
Android then uses a masked uuid scan filter to recognize and decode it, while ios can read android's manufacturer data normally. Once discovered, both use gatt followed by the same authenticated handshake and encryption protocol. the advertisement itself isn't trusted for identity verification.
The annoying part though is background discovery. ios moves advertised uuids into its overflow area when the app is backgrounded, which android can't scan. So an iphone needs meshlive open in the foreground to be discoverable by android.
15 min rotating ids are already enabled on android, while the ios implementation is still experimental and needs more hardware testing. Definitely one of the bigger cross platform headaches 😅
Thanks for the detail. The iOS overflow-area behavior explains a lot, background advertising on iOS has bitten many Bluetooth projects. Do the rotating identifiers survive an app restart, or does a restart mint a fresh identity?
Good question! On ios, restarting the app doesn't automatically generate a new identity. the presence key is stored in the keychain, and the rotating id is derived from that key and the current 15 min time window.
So restarting within the same window generally gives the same id, while the next rotation generates a different one. the long term identity also survives restarts.
a fresh reinstall is handled differently though, it starts a new presence generation. rotating ids are still experimental and off by default on ios for now.
That answers it cleanly, thanks. The keychain-backed presence key surviving restarts makes sense, and keeping rotating IDs experimental and off by default feels like the cautious right call. One thing I am still curious about: when two devices first discover each other, how is presence verified on that first contact, or is that deliberately out of scope for now?
Good question! on first contact, the bluetooth advertisement is just an untrusted discovery hint, it doesn't prove identity.
Once the devices connect over gatt, they run an authenticated handshake using their long term p256 identity keys, signed ephemeral keys and fresh nonces. The rotating id is then checked against the authenticated identity.
So a stranger's identity is cryptographically authenticated, but you don't know who actually owns that key yet. That's where qr codes/safety codes and verified contacts come in. once verified, a changed identity key can be detected and rejected.
Same idea on ios and android, though rotating discovery is still experimental on ios.
The layered design is clean: authenticate the key first, then bind it to a person out of band with the QR code flow. My one concern would be what happens when a user gets a new device, since the long term key changes and all their verified contacts would see a key change warning.
Aah I didn't think about that. Right now the identity key is hardware-backed and non-exportable, so switching phones means a new identity. Verified contacts won't automatically trust the new key and would need to reverify via QR/safety code. A signed handoff from the old device could be a nice solution eventually, but that's not implemented yet.
Hey Gautam, I read your MeshLive post. I'm a solo founder too and stuck on the same problem with my own tool, so I'm curious: who's the one kind of person you'd most want using it right now?
Right now probably someone who's into experimenting with tech and has a couple of android phones to test on. bluetooth compatibility across different devices is one of my biggest challenges, so those early testers are really valuable.
Long term though, i'd love to see it used by people who need offline communication during internet shutdowns, disasters or in remote areas.
Curious what you're building btw?
Makes sense, device testing is the hard part with Bluetooth. One idea: keep a public compatibility list (phone model, Android version, works / doesn't) and ask each tester to add one line. Testers like seeing their phone on it, and it shows newcomers the app is real.
For the offline crowd, people in the Meshtastic and Briar communities already care about communication without internet, so they might be your early testers too.
I'm building FounderPulse (linked in my profile): it finds people who recently asked online for what you sell, with the link to each post. If you paste the MeshLive page, I'd be curious whether it finds people asking for offline calling.
Yeah exactly! i've actually already got a public device compatibility table and a github issue template where testers can report their phone model, android version and what worked or didn't. still need a lot more devices covered though.
I've been reaching out to communities like meshtastic, briar and other offline communication groups too, definitely the right audience for this.
and founderpulse sounds interesting! i'll check it out and try putting meshlive through it. Curious what it finds.
Nice, you're way ahead of me on the compatibility table. Small thought for coverage: since a call needs two phones anyway, ask each tester to pair with a friend's phone and report both models. One test, two devices covered.
Let me know what FounderPulse finds, good or bad!