UmbrellaX vs SimpleX: private messaging, no identifiers, and usable scale

SimpleX is one of the few messengers I read with real respect before building UmbrellaX. It refuses phone numbers, usernames, public keys, and even random account IDs as stable user identifiers. That is a serious design. I still built UmbrellaX differently because I am not only optimising for the most radical privacy model. I am optimising for private communication that normal people can keep using: large groups, account continuity, fast delivery, calls, censorship resistance, and a company someone can hold responsible.

Below: the identity question, the routing question, the group question, the recovery question, and why I still prefer UmbrellaX as the default private messenger.

Where each project sits

UmbrellaX is the messenger I built. It runs MLS with post quantum hardening, registered as UmbrellaX TOO in Kazakhstan. It does not require a phone number. It gives the user a stable handle because people need a way to be found by the people they choose. The server does not get message content, and the system is designed around data minimisation, jurisdiction outside the Five Eyes, and transport that survives blocks.

SimpleX is a different answer to the same first question. It asks: what if the network never assigned a user identifier at all? Not a phone number. Not a username. Not a public key. Not even a random number. Messages move through pairwise queues and relay servers. The servers do not host user accounts. The user creates links or QR codes to make connections, and the app can use different relay operators so no one server gets the whole picture.

That is elegant. It is also demanding. The absence of identifiers removes a class of metadata, but it moves complexity into connection setup, device continuity, group mechanics, and recovery. I respect the design. I would not make it the default for the audience I am building for.

1. Identity without phone numbers is not the same as no identity at all

Both UmbrellaX and SimpleX reject phone number identity. That matters. Phone numbers are toxic identifiers for privacy. They connect a messenger account to carriers, banks, government forms, address books, breach dumps, and data brokers.

After that shared starting point, the projects split.

SimpleX removes persistent user identifiers almost completely. The system creates separate queues and credentials per connection. A server can see a queue, but not a global user account that owns every queue. This is the most radical version of “do not let the network know who the user is” that I have seen in a usable messenger.

UmbrellaX keeps a cryptographic identity and lets the user choose a handle. I do that because people need continuity. They need to move devices, recover accounts, get invited to groups, run teams, publish a contact method, and let trusted people find them later. A messenger that makes identity too invisible can become safer in theory and harder in life.

My choice is deliberate. I want to remove the phone number without removing the social affordance people need to communicate. UmbrellaX is not anonymous by default. It is private by default. Those are related goals, not identical goals.

2. Routing privacy has a cost

SimpleX routing is fascinating. The project says four different servers are used in each chat for security, and that they cannot observe which IP addresses talk to each other. Messages move through unidirectional queues rather than a single account inbox. Users can also run or choose servers.

That gives SimpleX a strong metadata story, especially against a server operator trying to learn who talks to whom. I did not build UmbrellaX to copy that exact property, because I chose a different protection boundary: less identity exposure than phone number messengers, plus a product normal people can keep using every day.

UmbrellaX chooses a central operator model with aggressive data minimisation and jurisdiction outside the Five Eyes. The trade is speed, reliability, moderation surface, abuse handling, group scale, simpler recovery, and a supportable product. I know what the server is allowed to know, I minimise it, and I put the company in a jurisdiction chosen for this job.

For some users, the SimpleX choice is correct. If the primary threat is “any stable identity or operator view is unacceptable”, SimpleX is built around that fear. My default user has a broader requirement: private chat that works every day, across groups, bad networks, device changes, and censorship events. For that user, UmbrellaX is the stronger balance.

3. Groups reveal the architecture

Groups are where messaging protocols stop being slogans.

SimpleX secret groups are intentionally private and decentralised. The documentation says every message and file is sent separately to every member, which makes secret groups suited to smaller groups. That follows from the design. If the network avoids a central group identity and avoids a central state holder, the clients have to do more work.

UmbrellaX uses MLS because I wanted groups to be first class. MLS gives me a tree. Membership changes stay bounded as the group grows. That is why UmbrellaX can target very large encrypted groups without changing the cryptographic model. I do not want a political group, community, company, or creator network to choose between privacy and scale.

SimpleX is working on channels, and the channel design is interesting. But the channel docs also say public channel functionality and privacy properties may change, and that channels do not attempt to encrypt public content from relay operators. That is fine for public distribution. It is not the same as private group messaging at scale.

UmbrellaX is built for encrypted groups as a normal user surface. SimpleX is built for maximum connection privacy first, with group scale handled through different mechanisms. That difference matters more than any feature checklist.

4. Recovery is part of privacy

Privacy people often underweight recovery because recovery feels boring until the phone is lost.

SimpleX stores user data on the user’s device. That is excellent for reducing server knowledge. It also means the user is responsible for preserving backups. The privacy policy is honest about this: if the user deletes the app without a backup, the data and private connections are gone.

I understand the purity of that design. I also know how normal users behave. Phones get stolen. Children delete apps. People change devices in airports. A phone dies in the middle of a move. A privacy product that cannot survive ordinary human chaos becomes a product for the unusually careful.

UmbrellaX is designed around account continuity from the beginning. I do not want recovery to become a backdoor, but I also do not want privacy to depend on the user being perfect. The point is to keep the server blind to content while giving the user a path back into their life.

That balance is harder than “everything lives only on the device”. It is also the balance I think a mass private messenger needs.

5. Jurisdiction and accountability are not side details

SimpleX Chat Ltd is registered in the United Kingdom. The network design reduces what preset server operators can know, and users can choose or run relays. That reduces jurisdictional exposure, but it does not make the project jurisdictionless. The company still exists somewhere. Preset infrastructure still exists somewhere. App stores still exist somewhere. Push notification paths still exist somewhere.

UmbrellaX is incorporated in Kazakhstan. Kazakhstan is not in the Five Eyes, not in the Fourteen Eyes, and has no mutual legal assistance treaty with the United States covering communications surveillance. I chose that before launch because I did not want to build a private messenger under US or UK compellability.

I also chose one accountable operator. That sounds less fashionable than decentralisation, but accountability has value. If UmbrellaX breaks a promise, there is a company, a founder, a jurisdiction, a policy surface, and a public architecture to inspect. With a relay network, responsibility can become more diffuse.

SimpleX reduces trust in the operator by design. UmbrellaX reduces operator knowledge and keeps responsibility legible. Both are serious choices. I prefer the second for a product meant to be used by millions of ordinary people.

Where SimpleX is a narrow specialist

SimpleX has real specialist traits. I want to name them cleanly without turning them into a default recommendation.

First, it has the most extreme no identifier design in this category. If having no persistent user ID matters more than usability, discovery, and continuity, SimpleX is the tool I would study first.

Second, it gives users unusual server choice. A user can use preset relays, choose other relays, or run their own. That is valuable for people who understand infrastructure and want that control.

Third, it gives a strong answer to server side contact graph visibility. Pairwise queues and separated relay knowledge make the server view much narrower than account based messengers.

Those specialist traits matter. They do not make SimpleX the stronger default messenger for the user I build for. I am building for people who need private communication to work under pressure without becoming a part time systems administrator.

Which to pick

Pick UmbrellaX when you want a private messenger for daily use: no phone number identity, large encrypted groups, post quantum MLS, reliable transport under blocking, account continuity, calls, and one accountable operator outside the Five Eyes.

Use SimpleX when your threat model places almost all weight on having no persistent identifier and on minimising what relay servers can infer. That is a valid threat model. It is not the whole private messaging market.

I am glad SimpleX exists. It proves that the phone number model was not inevitable. UmbrellaX takes the next step I care about: keep the privacy lesson, but build the messenger normal people can actually live in.