A dozen projects have attempted to build chat that works without the internet — using Bluetooth, Wi-Fi Direct, LoRa, or peer-to-peer mesh networking. Most are dead. Several are open source but abandoned. A few are alive but proprietary. None interoperate with each other. This page maps the landscape: what each project does, how open it is, whether it is still maintained, and why the fundamental constraints of Android and Bluetooth make this category so extraordinarily difficult to build well.
Every card below represents a project that has claimed, at some point, to support Bluetooth or offline/mesh communication. Status badges reflect the state of development as of mid-2025. "Dead" means the app has been removed from stores, the repository has been archived, or the company behind it has ceased operations.
Every project compared on transport technology, openness, security, platform support, and offline capability. Radar is highlighted. Features in grey rows are section headers. Scroll horizontally on smaller screens.
| Feature / Dimension |
📡
Radar
Active
|
🌿
Briar
Briar Project
Active
|
🔗
Berty
Berty Technologies
Active
|
⚡
BitChat
Dorsey / Nostr
Experimental
|
🌉
Bridgefy
Bridgefy Inc.
Active
|
🗺️
Meshtastic
Open Source
Active
|
📻
Serval
Flinders Uni
Stalled
|
🔥
FireChat
Open Garden
Dead
|
📞
Meshenger
Open Source
Active
|
🔵
Nearby API
Google
API Only
|
🍎
AirDrop
Apple
Proprietary
|
|---|---|---|---|---|---|---|---|---|---|---|---|
| 📶 Radio Transport | |||||||||||
| BLE advertising / scanningBluetooth Low Energy beacons for peer discovery | ✓ | ✓ | ✓ | ✓ | ✓ | Control onlyLoRa carries data | ✗Wi-Fi only | ✓ | ✗ | ✓ | Discovery only |
| BLE GATT data transferBluetooth connections for actual message delivery | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ |
| Wi-Fi Direct / Wi-Fi Aware (NAN)Peer-to-peer Wi-Fi without a router | ✓Wi-Fi Aware (NAN) | ✓Wi-Fi Direct | ✓Wi-Fi Direct | ✗ | ✗ | ✗ | Wi-Fi Ad-hoc | ✓iOS Multipeer | ✗Needs AP | ✓ | ✓File transfer only |
| Local Area Network (LAN / Wi-Fi AP)Delivery over a shared Wi-Fi network or hotspot | ✓ | ✗ | Partial | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✓ | ✗ |
| LoRa long-range radioSub-GHz dedicated radio hardware; 10–50 km range | ✗ | ✗ | ✗ | ✗ | ✗ | ✓Primary transport | ✗ | ✗ | ✗ | ✗ | ✗ |
| Tor / internet relay fallbackEncrypted relay over the internet when local fails | ✓E2E relay + Tor via Orbot; serverless DHT discovery | ✓Tor onion (native) | ✓libp2p / IPFS | Nostr relay | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| 🔓 Openness & Transparency | |||||||||||
| Source code open / auditableCan security researchers independently audit the code? | ✗ | ✓GPL-3.0 | ✓MIT/Apache | ✓MIT | ✗ | ✓GPL-3.0 | ✓GPL (unmaintained) | ✗ | ✓GPL-3.0 | ✗Closed binary | ✗Proprietary |
| Wire protocol publicly documentedCan a third party independently implement a compatible client? | ✗ | ✓Full protocol spec | PartialUses libp2p standards | Nostr NIPsBLE layer undocumented | ✗ | ✓Protobuf schema | PartialRhizome spec exists | ✗ | ✓Simple / readable | ✗ | ✗ |
| Third-party integration possibleCan other developers build on top of this project? | ✗ | ✓Fork / extend source | ✓gomobile-ipfs SDK | ✓Open source, early | SDKCommercial; API key; closed | ✓Excellent API/SDK | Source availableUnmaintained risk | ✗Dead, no source | ✓Open source | API onlyPlay Services required; closed terms | ✗Apple only; zero access |
| Interoperable with other appsCan two different apps on this list talk to each other? | ✗ | ✗ | ✗ | Potential (Nostr) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| 📱 Platform & Development Status | |||||||||||
| Android support | ✓ | ✓ | ✓ | ✓In development | ✓ | ✓ | Old APK only | ✗Removed | ✓ | ✓ | ✗ |
| iOS supportFull mesh / BLE features — not just internet fallback | ✗Platform prevents BLE mesh | PartialIn development; BT limited on iOS | ✓BLE limited in background | ✓In development | ✓ | ✓App; BLE to hardware | ✗ | ✗Removed | ✗ | ✗ | ✓Apple only |
| Actively maintained (2024–2025)Regular commits, releases, bug fixes | ✓ | ✓ | ✓Small team | ✓Very new (2025) | ✓Commercial roadmap | ✓Very active | ✗Dormant ~2018+ | ✗Company folded | ✓Hobbyist pace | ✓Google product | ✓Apple OS-level |
| Requires additional hardware beyond a smartphone | ✗ | ✗ | ✗ | ✗ | ✗ | ✓LoRa board required | ✗ | ✗ | ✗ | ✗Needs Play Services | ✗Apple device only |
| 🔒 Security | |||||||||||
| End-to-end encrypted messagesMessages encrypted before leaving sender; only recipient can read | Web relay onlyBLE/WiFi = physically bounded cleartext | ✓Over all transports | ✓ | PartialNostr keys; BLE layer varies | Claims yesPreviously broken (2020 CVE) | ✓AES-256 | Partial | ✗Plaintext messages | ✓ | Transport layer onlyApp must add own E2E | ✓TLS; Apple controls keys |
| No phone number or account requiredCan the user communicate without registering a real-world identity? | ✓Random UUID; zero PII | ✓Nickname only | ✓ | ✓Nostr keypair | ✓ | ✓ | ✓ | Nickname onlySocial graph visible | ✓ | No; but Google account linkable | ✗Apple ID / device identity |
| Publicly disclosed security CVEs / vulnerabilities | ✗None disclosed | ✗Audited, none significant | ✗ | — Too new to audit | ✓2020: entire crypto broken; messages readable | MinorDefault channel key shared | — | ✓No encryption; social graph harvesting reported | ✗ | —Closed; unknown | UWB tracking2021: PrivateDrop research |
| 📶 Offline & Mesh Capability | |||||||||||
| Functions with zero internet or cellularNo internet infrastructure at all — BLE, Wi-Fi P2P, or LoRa only | ✓ | ✓ | PartialBLE works; some features need internet | BLE onlyRelay features require internet | ✓BLE mesh mode | ✓Core design | ✓Wi-Fi mesh | ✓BLE / Wi-Fi Direct | LAN onlyNeeds a Wi-Fi AP | ✓ | ✓ |
| Multi-hop store-and-forward meshMessages relay peer-to-peer to reach out-of-range recipients | ✓BLE + WiFi Aware hops | ✓ | Partial | BasicEarly implementation | ✓ | ✓Core design; excellent | ✓Rhizome bundle routing | ✓ | ✗ | ✗Direct connections only | ✗ |
| Typical range per radio hopApproximate real-world range under normal conditions | BLE: ~10–30 m Wi-Fi Aware: ~50–80 m |
BLE: ~10–30 m Wi-Fi: ~50 m |
BLE: ~10–30 m Wi-Fi: ~50 m |
BLE: ~10–30 m | BLE: ~10–30 m | 10–50 kmLoRa; depends on terrain | Wi-Fi: ~50–100 m | BLE: ~10–30 m | LAN: full building | BLE: ~30 m Wi-Fi: ~80 m |
Wi-Fi Direct: ~9 m |
| Serverless peer discovery (DHT)Find peers with no central directory — a distributed hash table replaces the lookup server | ✓UUID → IP + geo DHT | PartialNo directory; manual Tor contact exchange | ✓libp2p / IPFS Kademlia DHT | ✗Nostr relay servers | ✗Bridgefy servers | ✗Optional central MQTT broker | ✗Local mesh only | ✗Open Garden servers | ✗LAN only; manual QR | ✗Google Play Services | ✗Local BLE only |
¹ BLE/Wi-Fi Aware messages in Radar are sent as physically-bounded cleartext — they never leave the local radio environment, but they are not encrypted on the wire. Messages via the web relay are end-to-end encrypted with sealed-sender metadata protection. This is an inherent consequence of how BLE GATT works: establishing a full encryption handshake over BLE adds significant overhead and latency. The local physical constraint (a message cannot be intercepted beyond radio range without physical presence) is the security boundary for the P2P channel.
Interoperability: zero across all apps. Every single project in this table — including every open-source one — uses a proprietary or incompatible protocol for its local radio layer. A Briar user and a Radar user standing side by side cannot exchange a message over Bluetooth. A Berty user and a Meshtastic user are equally isolated. This is not a deliberate design choice by any one developer — it is the consequence of having no open standard for BLE-based mesh chat. That standard does not exist.
All product names, logos, and brands mentioned in this comparison are the property of their respective owners and are used here solely for informational and comparative purposes. Radar is not affiliated with, endorsed by, or sponsored by any of the projects listed above.
Every app in this comparison has independently invented its own discovery protocol, peer addressing scheme, message routing algorithm, and encryption model. The result is a completely fragmented ecosystem where every implementation is an island. Understanding why no standard exists is essential to understanding the limitations of every app in this space — including Radar.
The IETF has published no RFC for Bluetooth Low Energy peer-to-peer messaging. There is no equivalent of XMPP, Matrix, or SIP for the BLE transport layer. Every developer building a BLE chat app starts from scratch on the protocol design. This means years of work, bespoke security models, and zero interoperability between apps.
Bluetooth SIG does have a Mesh Networking specification — but it was designed for smart lighting, building automation, and sensor networks. It uses controlled flooding and managed flooding algorithms optimised for short, infrequent, broadcast-style sensor readings. It is not designed for unicast two-party conversations, large payloads, or the privacy requirements of personal messaging. No mainstream chat app uses it.
Both Android and iOS severely limit what third-party applications can do with Bluetooth. Google's Nearby Connections API hides its entire protocol behind a closed black box — it works, but only within the same app. Apps cannot discover each other across different Nearby implementations. Apple's Multipeer Connectivity and AirDrop are even more tightly locked. Developers cannot build standards-compatible software because the platforms themselves prevent it.
Meshtastic has a fully documented, open, cross-implementable protocol over LoRa. Third parties have built independent implementations, and the ecosystem is genuinely open. But it requires purchasing dedicated LoRa hardware and is therefore not a "phone-only" solution. For pure smartphone BLE mesh, nothing comparable exists. Briar documents its protocol fully but does not provide a public SDK, making integration laborious even for motivated developers.
Bridgefy, which marketed itself as a developer platform for offline mesh, charged per-API-key and published no protocol specification. The most widely deployed "mesh chat SDK" in the world — used at the 2019 Hong Kong protests, the 2020 US demonstrations, and multiple disaster zones — was undocumented, proprietary, and subsequently found to have completely broken encryption. The crisis it was trusted to handle is the exact one where its weaknesses were most dangerous.
If your contact uses Briar and you use Radar, you cannot message them over Bluetooth. If half a community uses Meshtastic hardware and the other half has only phones, the phone users can only talk to each other via an internet relay if one is available. The offline "mesh" only works when everyone uses the same app — which is rarely the case in the emergencies these tools are designed for.
Building reliable BLE-based chat on Android is one of the most constrained software engineering problems in mobile development. The Android Bluetooth stack imposes hard limits that no third-party app can override, regardless of how much engineering effort is applied. These are not implementation bugs — they are fundamental architectural constraints enforced at the OS and hardware level. Users and reviewers often attribute these limitations to developer error. They are not.
ACCESS_FINE_LOCATION to scan. Android 12+ added three new dedicated Bluetooth permissions. Users can deny any of these, silently breaking discovery.Why these constraints matter for Radar specifically: Radar's BLE behaviour — discovery delays, occasional missed peers, the need for the app to be running in the foreground, and limitations on how many concurrent peers can be connected — is a direct consequence of the constraints described above. The developer cannot make BLE discovery instantaneous. The developer cannot make background scanning completely reliable. The developer cannot maintain simultaneously active connections to more than ~7–10 peers. The developer cannot send the same beacon in multiple formats at once. Every Bluetooth chat app on Android faces exactly the same constraints. Briar, Berty, Bridgefy, and BitChat all encounter these same limitations — they simply have fewer users reporting them.
Every app that has tried to solve offline mesh chat has either abandoned the effort, kept their implementation closed, or found that BLE alone is insufficient for reliable messaging. The following explains the fundamental engineering problems that make this category so difficult — and why the "just fix it" framing applied to app reviews misunderstands the nature of the problem.
For two devices to communicate over BLE, one must be advertising and the other must be scanning — and they must overlap in time. The advertising device broadcasts a beacon every 100–1000 ms. The scanning device listens for ~5 seconds, then rests for ~25 seconds (to save battery). If the scan window doesn't coincide with an advertising burst, the devices never discover each other.
Increasing the scan frequency kills battery life. Reducing it increases discovery latency. There is no configuration that makes discovery both instant and battery-efficient. Apps must choose a point on the trade-off curve and live with the consequences. No amount of engineering eliminates this fundamental constraint.
Adding end-to-end encryption to a BLE message requires key exchange (adds round-trips), larger payloads (challenges the 497-byte MTU limit), and computational overhead. On a messaging transport that already has strict bandwidth and connection constraints, every extra byte and every extra round-trip has a real cost.
Bridgefy's 2020 failure is the starkest illustration of this: the team took shortcuts on cryptography precisely because implementing proper E2E encryption on BLE is non-trivial. Briar, which does implement strong E2E encryption over Bluetooth, took years of engineering and is still Android-only after nearly a decade of development.
In a mesh, a message to a recipient who is out of direct radio range must be relayed through intermediate nodes. But intermediate nodes don't know who is "out there" or where the recipient is. Without internet infrastructure, there is no global directory. Store-and-forward routing — carrying a message until you encounter someone closer to the recipient — requires every relay node to store potentially many messages, use battery to keep BLE active, and have some mechanism for the message to expire when it cannot be delivered.
Routing in Bluetooth mesh is an unsolved problem at scale. It works in small crowds. It degrades poorly as network size grows, message volume increases, or relay nodes go offline.
"Low Energy" in Bluetooth Low Energy refers to the advertising and connection establishment phases. Continuous BLE scanning — the kind needed to discover new peers in real time — can consume 10–30% of battery per hour depending on scan parameters and device hardware. Running BLE advertising simultaneously adds more. Add Wi-Fi Aware, foreground service overhead, GPS, and encryption, and a mesh chat app running in full "active mesh" mode can drain a phone in 3–6 hours.
Apps that reduce battery drain (by scanning less frequently, using lower-power modes, or disabling features) are criticised for being slow to discover peers. Apps that prioritise speed are criticised for draining the battery. The physics does not offer a middle path.
BLE Class 2 devices (the kind in every smartphone) have a nominal range of ~10 metres indoors, ~30 metres in open space. Real-world range is often less due to human body shielding, walls, interference from other 2.4 GHz devices (Wi-Fi, microwave ovens), and the way Android reduces transmit power to save battery.
Wi-Fi Aware extends this to ~50–80 metres but requires both devices to support it. Neither transport approaches the range needed for city-scale or disaster-zone communication. Meshtastic's LoRa approach (10–50 km per hop) is the only realistic long-range solution — but it requires dedicated hardware and is therefore not a replacement for phone-native mesh.
A bug in a conventional server-based app can be reproduced with one device and one server. A bug in a mesh app may only appear when three or more devices are arranged in specific proximity, with specific Android versions, specific hardware chipsets, specific battery levels, and specific OS background-activity configurations.
The BLE stack itself behaves differently across device manufacturers. A Samsung Galaxy, a Pixel, and a Xiaomi running the same Android version will exhibit subtly different scanning behaviour, connection timing, and MTU negotiation results. End-to-end testing of a mesh chat app is a fundamentally more difficult engineering problem than testing a conventional centralised messenger.
The bottom line for Radar: Radar is one of only a handful of apps in the world that has successfully implemented multi-transport offline mesh chat (BLE + Wi-Fi Aware + LAN) in a single Android application, with a full feature set including maps, SOS, group chat, and an encrypted internet relay fallback. That relay itself depends on no single central server: peers are located through two distributed hash tables spread across the devices themselves — a UUID → IP address resolution and a geographic location → nearby-peers search — so discovery keeps working even if Radar's own server is blocked or shut down, healing around the failure for better resilience against a government shutdown. The limitations users encounter — occasional discovery delays, range constraints, the absence of iOS support, inability to connect to more than ~10 peers simultaneously — are not the result of development shortcuts. They are the consequence of building on top of an OS and a radio protocol that were not designed for what Radar uses them to do. Every other app in this landscape faces the same constraints. The ones that appear not to have these problems either use dedicated radio hardware (Meshtastic), rely on internet connectivity as their primary channel, or no longer exist.
Given the fragmented state of this ecosystem and the hard limits described above, Radar's design decisions — and its current limitations — can be understood in their proper context.
Radar is one of the only consumer Android apps that implements BLE GATT messaging, Wi-Fi Aware (NAN) high-bandwidth transfer, LAN delivery, and encrypted internet relay within a single application — with automatic fallback between channels. Most apps in this space support at most one or two transports. Building and maintaining all four simultaneously, across the full diversity of Android hardware, represents a substantial engineering achievement.
Radar's protocol is not published as an open specification, and Radar's source is not open. This limits auditability compared to Briar — a real trade-off worth acknowledging. In this context it is worth noting that the two major commercial predecessors in the space (FireChat and Bridgefy) were also closed — and one had its entire encryption broken. Closed source is not evidence of insecurity, but open source is stronger evidence of the opposite. Radar's BLE/Wi-Fi messages are explicitly labelled with a yellow padlock to indicate they are not encrypted, which is honest and auditable behaviour at the application layer.
Discovery latency, range, the lack of iOS support, concurrent connection limits, and background scanning reliability are all constraints imposed by Android, Bluetooth, Apple, and physics — not by Radar's implementation choices. There is no software fix for the 31-byte BLE payload limit. There is no app-level workaround for Apple blocking background BLE advertising on iOS. There is no way to make Bluetooth reach 1 km without hardware. Reviewers and users who attribute these constraints to developer shortcomings are, however understandably, misidentifying where the ceiling is.