Briar: a messenger that syncs over Bluetooth when the internet is gone

No central server, so the sync happens between the devices

Briar is described as a messaging app designed for activists, journalists, and anyone else who needs a safe and easy way to communicate. The distinguishing architectural claim is in the next paragraph: unlike traditional messaging apps, Briar does not rely on a central server, and messages are synchronized directly between the users' devices.

That single sentence changes what the application is. There is no account to create and no company holding a copy of your messages, which removes both a privacy exposure and a single point of failure. It also means the app is not a drop-in replacement for a mainstream messenger, since the convenience of a central server is precisely the convenience being given up.

The two transport options are what make the design usable in the situations the project targets. If the internet is down, Briar can sync via Bluetooth or Wi-Fi, keeping information flowing in a crisis. If the internet is up, Briar can sync via the Tor network, protecting users and their relationships from surveillance.

The Bluetooth path is the unusual one and the one worth understanding properly. A Bluetooth sync does not need a network, a server or a rendezvous point, so a group of phones in the same physical place can exchange messages with the internet unplugged. That is a capability for a situation where a conventional messenger simply stops working, and it is why the project describes the app as being for people who need to communicate in a crisis.

The Tor path is the one used when connectivity exists, and the framing is about protecting relationships as well as content, since an observer who can see who is talking to whom learns something regardless of the message body.

The application is written in Java, and the repository is a mirror of the source at the project's own forge, code.briarproject.org, with the homepage at briarproject.org.

The code is split into a transport layer and an application layer

The top-level directories describe the architecture, and the naming makes the separation explicit.

There are two parallel sets. The bramble layer is bramble-android, bramble-api, bramble-core and bramble-java, and the briar layer is briar-android, briar-api, briar-core and briar-headless. Both layers have an Android module, an API module and a core module, which tells you the split runs vertically through the stack rather than being one transport sitting beside one application.

What bramble is for is not spelled out in the README, so the safest reading is the one the names support: bramble is the component that carries messages between devices, and it is the part that has to work over Bluetooth, over Wi-Fi and over Tor. Keeping that in a separate API, with its own core and its own Java implementation, means the transport can be reused and tested independently of anything Briar-specific.

The briar layer holds the application. briar-android is the Android client, briar-api is the application-facing interface, briar-core holds the shared logic, and briar-headless is the piece that runs the application without a user interface, which is the usual shape for a system that also runs on servers or in automation.

Two more directories are worth a look. briar-mailbox is a submodule, and mailbox-integration-tests/ is a separate module, so the mailbox and its integration are tested apart from the rest. The libs/ directory holds shared libraries, and the patches/ directory holds patch files, with the .gitmodules file at the root confirming that submodules are used to bring in the external code.

The build is Gradle, with build.gradle, settings.gradle, a dagger.gradle file for dependency injection wiring, gradle.properties, the wrapper and its Windows counterpart, and a .gitlab-ci.yml for continuous integration.

Reproducible build images exist so you can check the APK yourself

The reproducible builds section is the part of the README that matters most to anyone who cares about the security claims, and it is a specific commitment rather than a general assurance.

The project provides docker images, hosted in a separate briar-reproducer project, to ease the task of verifying that the published APK binaries include nothing but the publicly available source code. The README says you can either use those images or use them as a blueprint to build your own environment for reproduction.

The wording of the claim is precise and worth repeating in the same terms: the goal is to verify that the binaries contain nothing but the source. That is a stronger and more checkable claim than saying the build is reproducible, because a reproducible build guarantees that a given source produces a given binary, while the image set lets anyone confirm that the binary you installed came from the source you can read.

This matters more than usual for a messenger aimed at people whose safety depends on the software being what it claims to be. A download from an app store is a download from a company, and a reproducible build image is an alternative to taking that on trust.

The rest of the distribution story is more conventional. There are badges for F-Droid and for Google Play, and the README also offers a direct APK download from the project site, which is useful for a device that does not have either store. A user manual and a wiki are linked under useful links, along with the project website, the source tree and a privacy policy.

Funding is handled through Liberapay, with Bitcoin and BCH addresses given, which fits a project whose audience tends to prefer that over card processing.

Translations and dependency pinning are handled as project chores

Two files in the repository root point at the work that keeps the project running across its community.

TRANSLATION.md is the translation workflow. For a messenger used across regions and by people at real risk, localisation is not a nicety, and having a dedicated document for it rather than a wiki page buried somewhere is a sign of how seriously it is taken.

update-dependency-pinning.sh is the other one, and the name tells you the practice. In a project where the security model depends on the cryptography and the transport being right, pinning dependency versions and updating them deliberately is a deliberate choice, and a script for it means the update is a repeatable operation rather than something that happens when someone notices a stale entry.

There is a CONTRIBUTING.md for the contribution process, and the .idea/ directory is committed, which is unusual but not unusual for a project with a stable team using IntelliJ.

The .gitlab-ci.yml confirms where the continuous integration runs, which is consistent with the mirror arrangement: the canonical repository is on the project's own GitLab instance at code.briarproject.org, and GitHub carries a copy for people who find projects there. The last push to the mirror was on 2026-10-13 and the repository is not archived, so the mirror is being kept current rather than frozen at the point it was set up.

The licence situation needs a note. The repository licence is recorded as one GitHub cannot classify, and there is a LICENSE.txt file at the root, so the terms to read are in that file rather than in a standard identifier.

What the README does not tell you

The README is short, and it is honest about that. Several things a person evaluating a messenger would want to know are simply not stated here, and it is worth listing them rather than filling the gaps with guesses.

The message model is not described. Whether messages are delivered once or stored, how long a conversation persists, and what happens to a message sent while the recipient is offline are all questions the README leaves open. For a messaging app, these are the questions that determine whether it fits, and there is no summary of them in the visible text.

Group messaging, contact discovery and the mechanics of how a Bluetooth mesh forms are also not covered. The existence of a mailbox submodule suggests messages are queued somewhere for later delivery, which is a sensible design for a store-and-forward model, but the details of that mechanism are not in the README.

The supported Android versions are not stated. The F-Droid and Play listings would say, but the README does not, and that is a practical question for anyone installing directly from the APK link.

The headless module is not explained either. briar-headless is in the repository and its name is suggestive, and for a project that also references a mailbox and automation, it likely means there is a way to run Briar without the phone interface. The README does not say what it is for.

None of this makes the project weak. It makes the README a starting point rather than a specification, and the user manual at briarproject.org/manual/ and the wiki are where the answers live. For anyone assessing whether Briar fits their situation, the manual is the document to read, and the reproducible build images are the document to trust.

Editorial conclusion

Briar is worth installing if your threat model includes the network being cut or watched, because the direct device-to-device sync is a different architecture from a messenger with a server in the middle and it keeps working when the internet does not. It is the wrong tool if you want the convenience of a mainstream messenger, since there is no account, no contact discovery and no message history beyond the sync model, and it is the wrong tool if you need to reach people who do not have it installed. Before you rely on it, verify three things yourself: that the build you install matches the source you can audit, which is exactly what the reproducible build images exist for, that your device and Android version are supported by the release you fetch from the F-Droid, Google Play or the direct APK link, and that the licence terms in the LICENSE.txt file suit your use, since the repository licence is recorded as one GitHub cannot classify and the project itself is hosted on a self-managed forge rather than on GitHub.

Frequently asked questions

Official sources

1. briar/briar on GitHub
2. Issues
3. Project website
4. README