SimpleX Chat: connections instead of accounts, and a CLI that is the app binary

There is no account, so there is nothing to log into

The claim in the project description is that this is a messaging network operating without user identifiers of any kind, and the README repeats it as the first messaging platform with none. Nothing in the setup asks for a phone number, a handle or an email address. What you get instead is a set of connections, each made separately with one other person.

Making one is a small ritual. You share a link with the other person, or scan a QR code from their phone, in person or during a video call. The README is specific that the channel carrying that link does not have to be secure: it is enough that you can confirm who sent the message and that the connection came up. Once it exists, you can verify the connection security code to check it.

The consequence is structural rather than cosmetic. There is no global user list to browse and no identifier to hand to a third party, so two people who never connect have no relationship the network can record. Discovery is handled elsewhere, through a directory, which is a separate surface with its own trust story.

An unverified link is a link you have not checked

Accepting a weak channel for the invitation is a deliberate trade, and the README states the compensating control plainly: verify the connection security code after connecting. The link or QR code gets you in, and the code comparison is what tells you that the person on the other end is who you think it is.

Both halves matter. Verification is a manual step, so a user who never opens the code comparison has an established connection whose peer was identified only by whatever channel carried the link. And because the invitation is a bearer-style secret in practice, forwarding it or scanning it from an untrusted source is the whole of the exposure window before that comparison happens.

Encryption itself is stated in two layers: a double ratchet end-to-end scheme with an additional encryption layer on top. The metadata claim is separate and broader, covering who you talk to and when. Neither statement tells you what the extra layer is or how the two combine, so the code comparison is the only verification step the README describes in operational terms.

The direct APK is aarch64, so the store is the general route

Android has two documented paths. The app is on Google Play under the package name chat.simplex.app, and there is also a direct link to a file named simplex-aarch64.apk on the latest release. The name is the news: that artifact is built for 64-bit ARM, so it is not the universal Android download. Anyone on another architecture is pushed back to the store listing, and anyone who wants a build ahead of the store has to match the architecture themselves.

On iOS the app is in the App Store, and there is a TestFlight preview that carries new features one to two weeks earlier. That preview is limited to 10,000 users, so it is a staged release channel rather than an alternative distribution, and a bug report from someone on it describes a different build from the one in the store.

The description also lists desktop apps, and there is a terminal app, described as a console app or CLI for Linux, macOS and Windows.

The container ships one stripped binary and nothing else

The Dockerfile documents the build closely enough to be reproduced. It starts from Ubuntu 22.04, installs the toolchain through ghcup, and pins the compiler before touching any code:

ENV BOOTSTRAP_HASKELL_GHC_VERSION=9.6.3
ENV BOOTSTRAP_HASKELL_CABAL_VERSION=3.10.1.0

The system dependencies are named explicitly, including an llvm-12 pair, so the build expects that exact major version:

RUN apt-get update && apt-get install -y curl git build-essential libgmp3-dev zlib1g-dev llvm-12 llvm-12-dev libnuma-dev libssl-dev

The compile step enables a client library flag on two packages, which is how the messaging queue side gets linked in:

RUN cabal build exe:simplex-chat --constraint 'simplexmq +client_library' --constraint 'simplex-chat +client_library'

Then the binary is stripped to reduce size and copied into an image built `FROM scratch`. The runtime container therefore has no shell, no package manager and no configuration files, only the executable. That is a good property for a minimal deployment and a bad one for debugging, since there is nothing inside to inspect, and the pinned GHC, cabal and Ubuntu versions are the versions you need if you want to rebuild it.

Stable and beta ship in the same week, on different lines

The three most recent releases are all on the 7.1 beta line: v7.1.0-beta.7 on 2026-10-20, v7.1.0-beta.8 on 2026-10-31 and v7.1.0-beta.9 on 2026-11-02, and the last push to the repository was on 2026-11-02. The default branch is called stable, so the branch you clone is the conservative line rather than the one where the next minor version is being assembled.

That has a reporting consequence. A stable user and a 7.1 beta user are running different code, so a crash or a behaviour difference reported from the beta does not describe the stable build, and triage has to ask which channel the reporter is on before anything else. The README's own note that iOS features reach TestFlight one to two weeks early describes the same two-track shape on the store side.

The README links a Wefunder page inviting investment, and questions to the team are answered by hand, which the README says can take up to 24 hours. Both facts bear on the same question an adopter has, which is how quickly a problem on the beta line gets attention.

The terminal app is the same executable, and the client is this repository

The build in the Dockerfile produces exactly one artifact, the simplex-chat executable, which is then stripped. There is no separate server target in the build command and no server directory in the repository root, which holds apps, src, tests, docs, website, packages, bots, scripts and fastlane. The client is the repository.

What the client talks to is a separate component. The build constraint on simplexmq with the client_library flag is the visible edge of that boundary: the queue protocol lives in another project, and this repository compiles its client half.

The flip side is that the same binary is what you script. A terminal client built from this source, shipped alone in a container and stripped of symbols, is the form that runs unattended.

Groups and a directory sit outside the project's responsibility

Discovery runs through the SimpleX Directory, and a SimpleX bot exists so that users can add their own groups and communities to it. The README attaches a condition to that in one line: the project is not responsible for the content shared in those groups. A directory users can add their own groups to, whose content the project disclaims, is the weak point in a network whose central claim is that identities are not enumerable.

Two groups are named as official. One is the users group for questions, the other is a developer group for people building on the platform, covering chat bots and automations, integrations with other apps, and social apps. Both are ordinary connections, reached by opening a link in the app or in a desktop browser and scanning the QR code, which is the same mechanism as any other contact. Nothing about them is privileged at the protocol level; they are pointed at because the project says so.

The team is reachable the same way, through a chat with the developers button that appears when you have no conversations, an option in app settings, or a SimpleX address. Every route to the team listed here is itself a connection, which is consistent with the design.

Translations are tracked per surface, and the docs column points at master

Localization runs through Weblate with contributions from users, and the README keeps a table where each row is a locale and each remaining column is a surface: Android and iOS, the website, and the GitHub docs. Reading the rows rather than the prose is the useful part, because coverage is uneven by design of the table. Bulgarian has entries for the mobile apps and nothing for the website, so a Bulgarian user on the website is reading English while the same user on Android is not.

The same table exposes a branch inconsistency worth knowing before you file a documentation fix. The default branch of the repository is stable, while the GitHub docs column links into the master branch, so a link from the translation table can land on a tree that is not the one your build came from.

The rest of the documentation is split by audience rather than by version. There is a WHY document explaining the reasoning for the network, a JOIN_TEAM document, a user guide under docs, and a blog that carries the security audit announcements. None of those is tied to a release number in the README, so a guide written before 7.0 is not labelled as such.

Editorial conclusion

SimpleX Chat fits people who want to hand out a per-conversation link instead of a phone number, and who are prepared to check a security code after connecting. It does not fit a team that needs a directory of all users, a shared account, or a guarantee about who can find whom, because none of those exist in the model. Before adopting, install from the store rather than the direct APK, which is aarch64 only, and decide whether you want the stable line or the beta, since the three most recent releases, up to v7.1.0-beta.9 on 2026-11-02, are all betas.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. simplex-chat/simplex-chat on GitHub