Berty: a messenger that keeps working when the network, and your trust in it, goes away

A messenger for the case where the network is hostile

The subtitle in the README is the entire pitch: Berty is an open, secure, offline-first, peer-to-peer and zero trust messaging app. It is built on top of the Wesh Protocol and developed by Berty Technologies, a French nonprofit.

The use cases section makes the intent clearer than the feature list does. Berty is designed to be used as a communication tool when all other traditional messengers fail: when you need to share sensitive information over untrusted networks while travelling, when you want to communicate anonymously, when you want full control over your data and do not want to rely on third-party servers, in countries that actively monitor and interfere with their network and censor some of its contents, and in areas with weak or no connection at all.

The security properties are listed as four commitments: messages are end-to-end encrypted by default, metadata is kept to a minimum, no phone number or email address is required to create an account, and it is built to retain those properties even on adversarial networks. Censorship resistance comes from being decentralized, distributed, peer-to-peer and serverless. The offline claim is backed by specific technology: no internet connection is required thanks to Bluetooth Low Energy and mDNS, which means nearby devices can find each other without any infrastructure at all.

The repository has 9,305 stars, 505 forks and 95 open issues, with 19 topic tags covering crdt, ipfs, libp2p, orbitdb, offline-first and surveillance. The last push was 2026-09-17.

The warning at the top of the README is not boilerplate

Before the introduction even starts, the README carries a blockquoted warning: Berty is still under active development and should not yet be used to exchange sensitive data. Further down, the Development Status section repeats the point from a different angle. The current implementation uses the Wesh Protocol, which means the encryption technique is safe and it works as a peer-to-peer app, but Berty has not yet been hardened, so please avoid using it on devices with weak sandboxes, such as unpatchable devices running old Android versions.

That distinction is worth pausing on, because it separates two different claims. The cryptography being sound is not the same claim as the implementation being hardened against a determined attacker with a vulnerable device. A messenger can be correctly encrypted and still leak through a compromised platform, and the README is explicit that this is the gap.

The API stability warning is equally blunt. The current Wesh Protocol is partially implemented, the API will continue to evolve in the near future, and the maintainers cannot guarantee non-breaking changes or any kind of API stability. Their advice for anyone embedding the protocol in an application is to be prepared for a rough ride.

There is also a note that repositories are being opened progressively, with additional modifications and updates to come, which tells you the project is still moving pieces of itself into public view.

Running it: two CLI tools and two mobile apps

The README's TLDR section is titled Install it, and it splits by platform. For mobile, the released versions are on Google Play and the Apple App Store; to build from source, the project points at the README inside `berty-bridge-expo/mobile`.

For the command line, you can `go run` or `go install` the CLI tool located in `go/cmd/berty`, and there are two main utilities. `berty mini` is a CLI messaging app that uses the Wesh Protocol, and `berty daemon` is a full node manageable through the Wesh Protocol API. The split is the useful part: mini is how you evaluate the protocol without running a node, and daemon is what you would actually deploy.

The monorepo is organised to match. The module path in go.mod is `berty.tech/berty/v2` on go 1.26.4, and the tree splits into `go/` for the core, `js/` for the JavaScript side, `api/` for the protobuf definitions, `berty-bridge-expo/` for the React Native bridge, plus `config/`, `docs/`, `tool/` and a `Dockerfile`.

The Dockerfile is a two-stage build on `golang:1.26.4-alpine` that runs `make go.install`, then ships a minimal `alpine:3.16.2` runtime with ncurses and four binaries copied in.

FROM            alpine:3.16.2
RUN             apk add --no-cache ncurses

ncurses is there for the terminal interface, which tells you the CLI is a real TUI rather than a thin print wrapper. The entrypoint is the node binary itself.

ENTRYPOINT      ["/bin/berty"]

What is actually underneath: libp2p, IPFS and a CRDT database

The dependency list in go.mod is the clearest description of the architecture, and it is a long one. Peer connectivity comes from `github.com/libp2p/go-libp2p` at v0.48.0 with the Kademlia DHT alongside it, plus a rendezvous implementation from the Berty organisation itself and `github.com/grandcat/zeroconf` for local discovery. Storage and content addressing come from `github.com/ipfs/kubo` at v0.41.0 with go-cid and go-datastore.

The data layer is where the interesting choice sits: `berty.tech/go-orbit-db` v1.22.3 provides an OrbitDB, which is a CRDT database on top of IPFS. That is the same family of technology that powers distributed ledgers, used here for a messaging app, and it is what makes the offline-first and eventually-consistent behaviour possible: two devices that cannot see each other edit the same conversation, and the states merge when a connection appears.

The protocol itself lives in `berty.tech/weshnet/v2`, and encryption comes from `github.com/hyperledger/aries-framework-go`. There is also Firebase in the dependency list, which is worth noting rather than glossing over: a privacy-first peer-to-peer app depending on a hosted push service is a normal arrangement for getting notifications to a phone that is not currently connected to the network, but it is a real dependency on someone else's infrastructure.

The Makefile shows the build culture. `make test` runs the Go tests, then the JS tests, installs yarn in `js/web`, then lints. `make generate` touches every `.proto` file to force regeneration and runs generation in `go`, `docs`, `js` and `config` before `go mod tidy`. Protobuf definitions are the source of truth and the API is generated from them, with `buf.gen.yaml` and `buf.gen.tag.yaml` at the root.

Version numbers, governance, and what the releases actually say

The releases are calendar-versioned with a build counter, v2.471.14 being the most recent on 2026-07-03, preceded by v2.471.13 and v2.471.12. The large middle number is a monotonic build identifier, which is how a project that ships continuously to app stores avoids reusing a build number.

What is inside them is unglamorous and honest. v2.471.14 is a single bridge-expo fix deriving the iOS App Group per build variant. v2.471.13 excludes `@types/node` from the TypeScript build. v2.471.12 resolves a test data race and Android release disk exhaustion in CI. A project shipping three patch releases in four days is one running continuously, and the fixes are exactly the category you would expect from a cross-platform app with native builds on both mobile platforms.

The governance statement is unusually direct. The README says the founding team's ultimate goal is to progressively relinquish control over Berty and to make it become a truly global community project, pointing at the berty/community repository for more. The philosophy paragraph argues that open-source is more secure because anyone can examine the code and improve it, and the project states the goal as contributing to a world where free and secure communications are common and fear of censorship or surveillance are not.

The licensing matches that posture in a practical way. The tree carries both LICENSE-APACHE and LICENSE-MIT with a COPYRIGHT file, and the repository license field reads NOASSERTION, which is what GitHub reports when a project ships more than one license file. Dual Apache and MIT is about as permissive as a project with a foundation behind it gets.

There is also a Crowdin badge and a `.crowdin.yml` in the tree, so the interface is translated through a hosted translation platform rather than hand-translated in pull requests. The README carries its own register on this point: the project is led by a small team who make mistakes, and asks readers to point out bugs and missing features.

How it compares to the encrypted messengers you already have

The honest comparison is against the two categories people usually reach for, and Berty is a different thing from both.

Signal is end-to-end encrypted, open source, and requires a phone number, with messages stored on a server until deleted. Berty asks for neither a phone number nor an email address, keeps no server copy because there is no server, and reaches other devices directly or over a local Bluetooth or mDNS link. If your concern is metadata retention, that is the whole difference and it is a large one. If your concern is the maturity of the client and its audit history, Signal is ahead by a wide margin.

Bridged-over-IPFS messengers sit closer to Berty, since they also avoid a central server. The difference there is the data model. Berty does not just transport messages, it puts them in a CRDT database, which is what lets two devices that never meet converge on the same conversation state. That is a stronger offline story than a transport-level protocol can offer, and a heavier dependency, since OrbitDB and IPFS bring their own storage and peer-discovery machinery.

The cost of the stronger story is the one the README keeps repeating. Berty has not been hardened, it should not be used for sensitive data, the protocol is partially implemented, and there is no API stability. On 9,305 stars and 95 open issues, the project has real adoption, but a foundation-run app with a small team is a different kind of dependency than a protocol with multiple independent implementations.

There is also the discovery question nobody answers for you. Peer-to-peer messaging needs a way to find the other device, and Berty answers it with rendezvous plus Bluetooth and mDNS for local cases. On a network with no internet and no nearby device, there is no path, which is the honest limit of the offline-first claim.

Editorial conclusion

Berty is interesting less as a WhatsApp replacement than as a working demonstration of what changes when you build a messenger with no accounts, no central servers and no assumption that a connection exists. The stack is substantial and real: libp2p, IPFS, OrbitDB for the CRDT layer, Bluetooth LE and mDNS for local discovery, a Go core bridged to React Native through Expo, and a documented Wesh Protocol. What you give up for that is equally real, and the project says so itself. The README warns that Berty is under active development and should not yet be used to exchange sensitive data, that it has not been hardened, and that the Wesh Protocol is only partially implemented with no API stability guaranteed. Run berty mini from go/cmd/berty to see the protocol work, and treat the app stores as a demonstration rather than a deployment.

Frequently asked questions

Official sources

1. berty/berty on GitHub
2. Issues
3. Project website
4. README
5. Releases