DEV Community: Gautam Gupta

I Got Video Calls Working Over Bluetooth mesh. Now They Work Across Phones and PCs.

Gautam Gupta — Tue, 27 Oct 2026 22:17:06 +0000

A few weeks ago, I started building MeshLive, an open-source app for voice/video calls and live broadcasts over Bluetooth, without internet, SIM cards or servers.

Back then, most of the work was getting real-time video to function between two Android phones.

Now I've released Android v0.4.0-beta, added an experimental Windows beta and a native macOS implementation, and continued work on the iPhone app.

One of the demos now shows a Windows PC making a video call with an Android phone, entirely over Bluetooth.

That was quite a step up from the first two-phone prototype.

What's new in 0.4.0?

The biggest addition is relayed calls.

Previously, direct calling required two devices to be within Bluetooth range. Live broadcasts could already travel through other phones, but private calls were a different problem.

Now Android has experimental call relaying.

If two verified contacts are too far apart to connect directly, intermediate MeshLive phones can forward the call between them.

It's opt-in under Settings > Advanced, and still very much beta.

Other changes include:

Better call setup and reconnection.
Lower audio delay on slower Bluetooth links.
Improved handling of unknown callers before media transmission.
Blocking that also applies to livestreams and relaying.
A fix for Mac calls prompting Bluetooth pairing when Hide phone name is enabled.

But the release notes are only a small part of the work.

The problem with video over Bluetooth

The biggest constraint has always been bandwidth.

On Android, MeshLive supports three media transports:

Transport	Why use it?	Tradeoff
BLE GATT	Default, broad compatibility, no pairing	Large writes can block other traffic
LE L2CAP CoC	Byte stream with credit-based flow control	Serious compatibility bugs on some Android stacks
Bluetooth Classic RFCOMM	Higher throughput on suitable devices	Usually needs pairing

Bluetooth discovery happens over BLE regardless of the selected media transport.

The Android app uses VP9 or AV1 video and Opus audio. Its conservative video default is 240p at 15 FPS and 200 kbps.

That doesn't sound impressive next to an ordinary internet video call.

But on Bluetooth, especially when both devices are sending video simultaneously, even that can be difficult to sustain.

One video frame could delay the audio by almost a second

This was one of the more frustrating issues.

A large encoded video frame could occupy the GATT writer while smaller audio packets waited behind it.

The first fix was giving audio separate queue headroom.

That addressed the overflow, but not the underlying problem: the transport was still busy writing video.

So I experimented with splitting larger video frames into roughly 2 KB authenticated fragments and giving audio opportunities to transmit between them.

I also tested speech-led playback, because solving the send-side queue wasn't enough if late video could still increase the receiver's shared buffering delay.

In one recorded Samsung M31 ↔ ASUS GATT comparison:

Measurement	Before	After
Audio queue age, p95	457 ms	140 ms
Framing overhead	—	~4.2%

The separate fragments-plus-speech-led test reduced median shared playout delay from 459 ms to 364 ms on the same phone pair.

These are measurements from specific development-build experiments, not complete mouth-to-ear latency measurements or proof that every device now passes the quality checks.

Still, they helped identify why simply increasing buffers wasn't the answer.

The fixed-fragment and speech-led approach became the default for compatible direct GATT calls. More adaptive, airtime-sized fragments remain experimental.

The technical comparison is documented in Call head-of-line A/B.

Relaying calls is harder than relaying broadcasts

For a broadcast, the source produces a stream and nearby viewers receive it.

A viewer can also forward that stream to another device.

Importantly, the forwarder doesn't need to re-encode the video for the next hop. It forwards the existing encrypted media, avoiding another encode/decode cycle for transmission.

But Bluetooth still has an airtime cost.

A relay receives packets and sends them again using its radio. Every additional viewer and hop competes for limited capacity.

Private calls make this harder because both endpoints produce audio and video simultaneously.

The relay has to move traffic in both directions while preserving the authenticated session and its timing.

MeshLive's relayed-call design keeps the intermediate phones out of the media content. They forward end-to-end encrypted packets rather than decrypting the conversation.

The endpoints retain the content keys.

There are also admission and overload protections, so a phone shouldn't keep accepting connections it cannot reasonably serve.

This is why relayed calls are still behind an experimental setting rather than being enabled for everyone.

Then came Windows and Mac

Another challenge was taking the app beyond Android.

Android, Windows and Apple's operating systems don't expose identical Bluetooth capabilities. Discovery, advertising, connection roles and permissions differ.

On Android, MeshLive uses a compact BLE announcement to advertise call and stream availability.

The Apple implementation has to handle different advertising restrictions, including representing discovery information through service UUIDs.

Desktop support also meant dealing with different connection roles instead of assuming every device could behave like an Android phone.

The protocol still needs to agree on the important things: authenticated connections, media framing, encryption and call signalling.

The Windows beta is now available, with the attached video demonstrating a call to an Android phone.

For Mac, I've added an experimental native application. It can be built from source and has working bidirectional voice/video calling with Android in the project's current implementation.

The iPhone app has also received more development, although it's still at an earlier validation stage.

I wanted the same basic idea to extend across the devices people already own, rather than requiring a separate piece of networking hardware.

Privacy also needed work

MeshLive doesn't require accounts or central servers to establish its local communication sessions.

Its security design uses signed handshakes, ephemeral key agreement and authenticated encryption. Calls and streams also have an end-to-end media encryption layer, separate from the encryption on each Bluetooth hop.

On Android, discovery identifiers rotate every 15 minutes by default, while unknown callers initially encounter a temporary identity.

In 0.4.0, the protocol also requires an unknown caller to prove possession of its claimed identity before the callee sends media. That isn't the same as proving someone's real-world identity.

Blocking now extends to broadcasts and relaying as well.

None of this makes Bluetooth communication invisible. Nearby scanners can still observe advertisements, connection metadata and traffic patterns. There is no independent security audit yet.

The full limitations are in the project's privacy documentation.

Why testing is still the biggest problem

I've tested the Android app across seven reference phones from Samsung, Xiaomi, ASUS and OPPO.

The results vary enormously depending on the phone combination.

Different chipsets, Bluetooth implementations, Android versions, codecs and connection behaviour can all change what happens.

Something working on one phone pair doesn't mean the same code will behave properly on another.

That's also been an interesting part of using AI coding tools on this project.

Most of the implementation was written with Claude Code, but the difficult part has often been reproducing failures on hardware, collecting measurements and deciding which changes actually helped.

The repository has a public device compatibility table, benchmark results and engineering decision records rather than treating a successful build as proof of reliability.

Where it stands now

MeshLive is still experimental, but it's made quite a bit of progress since the first Android beta.

There's now a Windows beta, a native Mac implementation, continued iPhone development and opt-in multi-hop calls on Android.

The long-term goal is better compatibility, lower latency and more practical communication between nearby devices without depending on internet infrastructure.

Try it or inspect the code:

If you try it, I'd especially appreciate reports with the device models, OS versions, transport and exactly where things worked or failed.

The project is free and open source under GPL-3.0-or-later. Contributions and technical feedback are welcome.

I built an offline Bluetooth video calling and live streaming app. Here's what's new in MeshLive 0.3.0.

Gautam Gupta — Mon, 19 Oct 2026 20:16:43 +0000

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.

I built an open-source Windows desktop companion for crypto with WinUI 3, Rust and Node

Gautam Gupta — Sat, 17 Oct 2026 18:44:42 +0000

I’ve been involved in crypto for years, and one thing I've always struggled with is the constant context switching.

I'd be working on something, want to check one price on DexScreener, then end up on X, looking at wallets, checking other tokens, or switching between trading terminals.

I wanted a way to keep the information I regularly check visible without constantly opening another tab or app.

So I started building a simple Windows desktop price ticker.

That eventually turned into TrenchHQ, a free and open-source desktop companion for crypto users.

It's now live on the Microsoft Store, and the source code is available on GitHub.

What it does

TrenchHQ lets you create floating overlays and screen-edge panels that stay visible while you work, browse or trade.

You can customize their size, position, colors and transparency, arrange them across multiple monitors, and save your layouts.

Currently, you can use these panels for:

CEX Price Ticker: Follow spot pairs from exchanges.
On-chain DEX Price Ticker: Track prices from specific liquidity pools.
Wallet Watcher: Monitor activity from public wallet addresses.
X Tracker: Watch posts from selected accounts using the official API.
Website: Keep websites in their own panels with persistent logins.
Application Window: Pin compatible Windows applications into your workspace.

The on-chain integrations currently cover Solana, Ethereum, Base, BNB Smart Chain and Robinhood Chain.

The interesting part was building the desktop experience

I wanted this to feel like part of Windows, not another dashboard running inside a browser.

That meant supporting floating always-on-top windows, screen-edge panels, multiple monitors and customizable layouts.

The core application is built using WinUI 3 / .NET, with supporting Rust and Node components.

One design decision was to separate panels from widgets.

A panel controls where something appears: its position, size, monitor, appearance and window behavior.

A widget controls what information is displayed inside it.

So you can configure a price ticker, wallet tracker or X feed independently of where it appears on your desktop.

You can also reuse saved widgets in different panels.

That separation made it much easier to support different kinds of content without building a completely different desktop-window system for each feature.

Adding on-chain data

Centralized exchange prices were relatively straightforward.

On-chain markets introduced a different set of problems.

A token can trade across multiple liquidity pools, sometimes on different DEX protocols, with different prices and liquidity.

Rather than only showing a generic aggregated token price, I wanted users to be able to select a specific supported pool and follow that market.

The app currently supports Solana and four EVM chains.

It also has to work with different data providers, some of which require API credentials, have usage limits or support different streaming capabilities.

TrenchHQ lets users configure their own provider connections and supports compatible provider fallback.

Live streaming is available where supported, with polling as another option.

Why I made it open source

Crypto-related desktop applications have an obvious trust problem.

I didn't want to ask people to install a closed-source executable that connects to market-data providers and handles their API credentials without being able to inspect the code.

TrenchHQ doesn't connect to wallets for signing, hold funds or execute trades. It is currently a monitoring tool.

Provider credentials are configured by the user, and the application doesn't require a TrenchHQ account.

The project is released under the MIT license, with setup instructions, architecture documentation and contribution guidelines in the repository.

It's finally available

After building and testing the desktop app, I also went through the Microsoft Store publishing process.

TrenchHQ is now available for Windows x64, with Store-managed installation and updates.

GitHub: https://github.com/gautamgpt1/TrenchHQ

Microsoft Store: https://apps.microsoft.com/detail/9plrs95wjkss

Website: https://gautamgpt1.github.io/TrenchHQ/

It's still early, and there's plenty I'd like to improve.

I'd especially appreciate feedback from anyone working with WinUI, Windows desktop utilities, on-chain market data or open-source applications.

I'm also curious: what other kinds of information would you want to keep visible in a desktop overlay?

I built MeshLive: video calling and live broadcasting over Bluetooth mesh, without internet (Open source)

Gautam Gupta — Sat, 10 Oct 2026 11:47:48 +0000

A few weeks ago, during the student protests in Delhi, I saw how mobile internet was shut down and how the government even tried to get Bitchat's GitHub repositories taken down, although they remained accessible.

That genuinely bothered me. Students were protesting for fair exams, and even basic communication was being restricted.

That got me thinking: why stop at text? What if we could make voice/video calls and broadcast live video over Bluetooth without internet?

So I started experimenting with it.

What I built:
MeshLive is a free, open-source Android app for communication between nearby phones over Bluetooth.

It currently includes:

Live camera and microphone broadcasting over Bluetooth

Multi-hop relaying, where nearby phones can forward a broadcast beyond the original sender's range

Two-way voice/video calls between nearby phones

Experimental offline messaging and additional communication features

No account, backend server, mobile data or Wi-Fi required for the media

There's also an early iOS implementation, although Android is the main focus right now.

The difficult part

Unsurprisingly, Bluetooth bandwidth was the biggest challenge.

Getting live video through such a limited connection is difficult enough. Add relaying, different Android versions, manufacturers, codecs and Bluetooth implementations, and things get messy pretty quickly.

I'd been working on a rough MVP for a few weeks. Then Bitchat was removed from Indian app stores, and with another protest approaching in Delhi, I decided to go all in.

Bought another phone within my budget, subscribed to the $200 Claude Max plan, and spent roughly 36 hours testing, breaking and fixing whatever I could.

A lot of the development was AI-assisted, but testing real Bluetooth behaviour still meant dealing with the actual devices available to me.

Where it stands

It's still an experimental beta.
Video can be laggy, some phone combinations don't work properly, and several features are still experimental or insufficiently tested. It also hasn't undergone an independent security audit.

I wouldn't recommend relying on it for emergencies or anything safety-critical yet. I could only test with a limited number of phones, and that's one of the biggest constraints right now.

Why open source?

Because I don't see something like this becoming genuinely useful without wider testing and contributions. Different Android manufacturers and Bluetooth implementations introduce problems that are difficult to catch with just a few devices.

And I believe the potential applications go far beyond the protests that initially inspired me: disasters, network outages, remote locations and other situations where conventional communication isn't available.

So I'm putting the work out there rather than waiting until everything is perfect.

Android source: https://github.com/MeshLive/meshlive-android

Download beta APK: https://github.com/MeshLive/meshlive-android/releases/tag/v0.1.0-beta

Early iOS: https://github.com/MeshLive/meshlive-ios

If you're interested in Android, Bluetooth, codecs, peer-to-peer networking, or just have a couple of spare phones to test with, I'd really appreciate the help.

Even bug reports with phone models, Android versions and what worked or failed would be useful.

PRs and feedback are welcome.