UmbrellaX vs Telegram: encryption by default, jurisdiction, and private messaging

I built UmbrellaX so every chat is end to end encrypted by default, including groups, cloud history and calls. Telegram does not work that way, and I think people forget how much that matters: only Telegram’s Secret Chats (one to one, single device, no cloud sync) are E2EE. I incorporated UmbrellaX in Kazakhstan with no mutual legal assistance treaty with the US. Telegram is a BVI company operating from Dubai after Pavel Durov’s 2024 arrest in France, and that is a story I read closely because it told me a lot about jurisdictional risk. Pick UmbrellaX when private messaging is the job. Telegram can remain useful for public channels and bots, but I do not treat that as a privacy advantage.

Below: five axes where I went a different way to Telegram, two narrow public utility cases where Telegram remains useful, and why that does not make it the better private messenger.

Where UmbrellaX sits

UmbrellaX is the messenger I built. It runs on MLS with post quantum hardening, registered as UmbrellaX TOO in Kazakhstan, sized for a billion users from day one. Every chat, group and call is E2EE by default. I refused to put a “secret mode” toggle in the UI, because almost nobody discovers a setting buried two screens deep. No phone number field on registration. The backend is 167 Rust microservices on 6 nodes across 4 regions at launch, with nine DPI bypass protocols (including a WebTunnel variant my team wrote) baked into the first release.

Telegram is a messenger most of you already use, often heavily. By Pavel Durov’s count it had roughly 900 million MAU in late 2024. Corporate structure is a BVI holding, operations in Dubai, protocol is MTProto 2.0 designed in house by Nikolai Durov. To be precise about what MTProto does: it encrypts traffic between client and server, but the server reads message content by default in cloud chats and groups. Only “Secret Chats”, limited to one to one on a single device, uses E2EE with forward secrecy. In August 2024 Pavel Durov was detained in France and indicted on twelve counts related to alleged criminal content. He is on limited French bail while the case grinds on, and I read that whole episode as a cautionary tale about where you incorporate a messenger millions rely on.

Both messengers support voice and video, run on iOS, Android and desktop, and get used in communities that face political pressure. The rest of this article is about the axes I made a different call on, and why.

1. End to end encryption by default

This is the single biggest difference, and most reviewers understate it.

When you send a message on UmbrellaX, your device encrypts it with a session key derived from MLS before anything leaves the phone. The server only ever sees ciphertext. I do not hold a key that could read the content, even if a court told me to. Group chats work the same way; key agreement happens inside the MLS tree so a group of 500 people is still ciphertext to the server. I think that is the only architecture that lets me put “private by default” on the landing page without flinching.

On Telegram in a regular chat, which is what almost everyone uses, MTProto encrypts the link between your device and Telegram’s server. The server decrypts to route, encrypts again for the recipient, and keeps a cloud copy so your other devices see the same history. Telegram holds the keys for that cloud copy. The convenience is genuinely lovely. It is also incompatible with E2EE under Telegram’s current architecture. Secret Chats do exist and do use E2EE, but they are one to one, cannot live in cloud history, do not sync across devices, and most users I know have never opened the menu where you start one.

Telegram’s official line is that the cloud server model is a deliberate tradeoff for convenience and that users who want E2EE should use Secret Chats. I respect Pavel Durov’s engineering chops and the scale of what he built, but I disagree with the framing. A toggle nobody finds is not a privacy feature, it is a marketing one. I refused to ship a product where confidentiality is a setting you have to discover.

2. Jurisdiction

I incorporated UmbrellaX in Kazakhstan as UmbrellaX TOO. Kazakhstan is not in the Five Eyes, not in the Fourteen Eyes, and has no MLAT with the United States covering communications surveillance. I am not going to pretend Kazakh law is a civil liberties utopia, because it is not. What it gives me is a jurisdiction outside US compellability and outside the European data retention regime, and that was the constraint I needed before I wrote a line of backend code.

Telegram’s legal structure is more tangled, and watching it evolve has been instructive for me. The entity is a BVI holding, Telegram FZ LLC operates from Dubai. Pavel Durov’s personal story is now central to that posture, whether he wanted it or not. He left Russia in 2014 after refusing state demands, ran the company from various locations for a decade, and was detained on arrival in Paris in August 2024. The French prosecution pulls in complicity for alleged platform offences and refusal to cooperate. After Durov’s bail release Telegram expanded its response to valid legal requests in certain categories. I read that whole arc as my own counterfactual: that is the kind of pressure I could not absorb if UmbrellaX were incorporated in the EU or the US, and it is exactly why I did not.

The point is not that Telegram is “unsafe”, I do not find that framing useful. The point is that Telegram’s legal surface has been rewritten over the last eighteen months. Kazakhstan was not a marketing line for me, it was the design constraint that made the rest of the architecture possible.

3. Protocol

I picked MLS, formalised in RFC 9420, and I added post quantum hardening on the key agreement path. MLS spent roughly six years at the IETF with cryptographers from Mozilla, Cisco, Wire, Inria and Facebook arguing every line of the spec. Group efficiency and suitability for formal verification were named goals from the first whiteboard. Large portions have been model checked, the standard is open, and anyone can implement a compatible client. That is the foundation I want under a messenger I ask people to trust with sensitive conversations.

Telegram uses MTProto 2.0, a custom protocol designed in house. The Durovs argue for MTProto’s throughput numbers and I think they have a point on raw performance. Where I disagree is on rolling your own crypto at all. The clearest piece of work here is “Four Attacks and a Proof for Telegram” by Albrecht, Mareková, Paterson and Stepanovs, IEEE S&P 2022. They found four practical attacks on MTProto and worked out what formal proof the protocol would need to be safe. Telegram patched the implementation issues, and I respect they responded in good faith, but the lesson stuck with me: a custom security protocol gets adversarial scrutiny later than a standardised one, and the delay is paid for in user data. I would not ship a custom protocol on a security critical product, and that is why I picked MLS.

The other consequence I care about is the group ceiling of 200,000 members on UmbrellaX. That number is not marketing. Protest coordination in countries where Telegram channels get blocked actually fits at that scale, and I needed an MLS tree handling those memberships in O(log N). Layered pairwise sessions, the way the Signal Protocol does groups, would not carry that load. MTProto cloud groups go bigger, but they are server visible, which is a different product category, not a different size of the same product.

4. Phone number and identity

Telegram requires a phone number to register. That number anchors your account, contact discovery uses it, and although Telegram lets you hide the phone behind a username for display, the server still holds the number as your identity. I have watched friends in Russia and Belarus get tracked through SIM tied identifiers they thought were behind a privacy setting, and those experiences shaped what I wanted to ship.

I did not use the phone number as identity on UmbrellaX. A cryptographic key pair generated on your device, plus a display handle the user picks, defines the account. Contact discovery runs through optional and revocable identifiers: a username, a QR code, a one time token shared in person. Any of them can be rotated or destroyed without changing the underlying account. The phone never has to touch my server.

For a user in a jurisdiction where SIM registration is tied to government ID, this difference is operational, not theoretical, and that is the reader I had in mind when I made the call.

5. DPI bypass and availability during blocks

Telegram has been blocked at various points in Russia, Iran, China, and parts of Central Asia. The response has historically been MTProxy and a network of proxies operated by volunteers. They work, broadly. They also require the user to find a fresh proxy address every time a block cycle resets, and that is the thing I wanted to design out of the product from day one.

UmbrellaX ships nine DPI bypass protocols in the client from the first release, including a WebTunnel variant my team wrote, obfs4, and a custom transport for high grade DPI environments. When one transport is blocked, the client fails over to the next without the user touching anything. I budgeted for 1B users from day one, and shipping nine transports up front is the same kind of decision: I prepared for the bad day before it arrived. Telegram added bridges and proxies as reactions to specific bans. I do not think that is wrong, just a different design philosophy.

Where Telegram is still useful

Two axes where Telegram remains useful. Both are public distribution surfaces, not reasons to trust Telegram with private conversation by default.

Mass broadcast channels. Telegram channels with millions of subscribers are a category Telegram popularised and still runs at enormous scale. News outlets, protest movements, crypto communities, whole national conversations run on them. I am building a channels feature on UmbrellaX, but I do not confuse broadcast reach with private messaging security. Telegram is useful for publishing to crowds. UmbrellaX is the product I would choose for private groups and conversations where the server must not read the content.

Bot API and ecosystem. Telegram’s Bot API has been in production since 2015 and the ecosystem on top is deep. I have a Bot API compatible with Telegram on my roadmap because I have used that ecosystem myself and I want UmbrellaX users to have an equivalent without giving up end to end encryption by default. Ecosystems take years to build, but ecosystem age is not privacy architecture.

Both of these are reasons someone might keep Telegram installed for public utility. They are not reasons to pick it over UmbrellaX for confidential messaging.

Which to pick

If you are deciding right now, here is the rule I give people who ask me directly.

Pick UmbrellaX when you want confidentiality as the default. Every chat E2EE, every group E2EE, no phone number tied to identity, jurisdiction outside the Five Eyes, transport that survives blocks. That is what I built.

Keep Telegram when you need public broadcast to millions, the existing bot ecosystem, or cloud chat convenience where server visibility is an acceptable cost. That is a public platform use case, not the private messenger use case I built UmbrellaX for.

A lot of people I know run both. Telegram for public channels and the communities already there. UmbrellaX for private conversation, encrypted groups, and anything they would rather not place on someone else’s readable servers by default.

I’m Kirill Abramov, founder and CEO of UmbrellaX TOO, a privacy first messenger company registered in Kazakhstan, outside the Five Eyes alliance. I built UmbrellaX because I think encryption by default and jurisdiction outside the main surveillance alliances should not be optional features, and I write about end to end encryption, post quantum cryptography, and the regulatory pressure on private communication. More about my work and why I run UmbrellaX from Kazakhstan: umbrellax.io/about.