A few weeks ago, I started experimenting with something I wasn't even sure would be practical: live audio/video communication between phones entire...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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!