UmbrellaX vs Session: two answers to the no phone number question

I built UmbrellaX and I respect Session. Both projects refused to take a phone number for account identity, and that is the place the two systems agree. Session picked random Curve25519 Account IDs, a decentralised network using onion routing, and Switzerland for the foundation. UmbrellaX picked MLS with post quantum hardening, a centralised infrastructure with nine DPI bypass protocols, and Kazakhstan outside the Five Eyes. We agreed on the question. The rest of this piece is the five places we landed differently.

Below: the five places UmbrellaX and Session land differently, identity, key freshness, network, groups, jurisdiction, then the narrow Session advantages that do not change my default recommendation for UmbrellaX’s target user.

Where each project sits

UmbrellaX is the messenger I built. It runs MLS as the core group messaging protocol with a hybrid X25519 plus ML KEM 768 layer for post quantum key agreement, registered as UmbrellaX TOO in Kazakhstan. The backend is 167 Rust microservices on 6 nodes at launch, three dedicated machines in Europe and three cloud edge nodes across four regions, around 160 euros per month. Nine DPI bypass protocols ship from the first release rather than as a reaction to the first ban. There is no phone number field on registration. Identity is a cryptographic key pair plus a display handle the user picks.

Session is the messenger I respect for refusing the phone number model six years before I shipped a competing answer. The Session Technology Foundation, headquartered in Switzerland since October 2024 after the Australian Federal Police visited a staff member’s home, runs the project. Identity is an Account ID with 33 characters derived from a long term Curve25519 keypair, displayed to the user as a hex string beginning with 05. The network is decentralised across more than 1,500 Session Nodes operated by the community and organised into swarms of five to seven, with messages routed through three onion layers.

Both projects publish their source. Both encrypt content end to end. Both reject the phone number. The rest of this article is the five axes where we landed differently.

1. Identity

Session went radical on identity. The Account ID is the long term Curve25519 public key in hex, 33 characters beginning with 05. There is no display name in the protocol. You pick a name in the client and it is local to your device. Two users wanting to talk exchange Account IDs out of band, by QR code, copy and paste, a postcard, whichever channel they like. The protocol gives the network no way to associate an Account ID with a phone number, an email, or a real world identity. That is the design.

I went a step less radical. UmbrellaX identity is a cryptographic key pair plus a display handle the user picks. The handle is not the protocol identity, the key is, but the handle exists from day one and is the thing the user types when they want to find a contact. Optional rotatable usernames and QR codes layer on top. You can also share nothing tied to your phone or any persistent identifier and the account still works.

When I made that call I went through Session’s design line by line. The honest argument for the random Account ID model is that a display handle is itself a metadata vector. Once you pick a memorable handle you tie the account to that string forever, and a state level adversary can build a graph from there. The honest counterargument is that humans need handles to find each other. The alternative is friction, and friction kills adoption among the people whose threat models we are actually designing for.

I land on the side of the handle being worth the metadata cost when the cost is bounded and the user has the option to rotate or destroy it. I respect Alex Linton and the Session Technology Foundation’s call here. I think it is the more conservative one in the metadata sense and the less practical one in the field. The tradeoff is real, but for the product I am building I still pick bounded operator knowledge plus daily usability over anonymous account fragments.

2. Forward secrecy and post quantum

This is where the comparison gets technically interesting. Until December 2025 it was also where the comparison was most lopsided.

Session Protocol V1 does not have perfect forward secrecy. By design. The protocol is stateless in one to one conversations. Every message encrypts to the long term Curve25519 public key. If an attacker exfiltrates that long term key, every past message ever sent to that account is decryptable, given access to the ciphertexts. Session has been clear in its FAQ that this was a deliberate trade for account portability and sync stability across multiple devices, and that “fully anonymous account creation, onion routing, and metadata minimisation” was the intended replacement defence. Privacy Guides has been clear, in turn, that this was not enough. Session has not been on Privacy Guides’ recommendation list for years, and PFS was the load bearing reason.

On 3 December 2025, Session announced Session Protocol V2: rotating device keys plus account keys synchronised across linked devices, with old keys deleted after a deletion window. Plus ML KEM, NIST’s post quantum key encapsulation mechanism. As of today the V2 protocol is “currently under development” with details expected through 2026.

I think the V2 work is honest and overdue. I would also not have shipped V1 without PFS in the first place, and that is a real disagreement. When I sat down to pick a protocol for UmbrellaX in 2024 the question of forward secrecy was settled for me by the threat model, not by the engineering convenience. A messenger that lets a future server compromise decrypt yesterday’s conversations does not survive a state level adversary, and a state level adversary is the threat model I sized for.

UmbrellaX runs MLS as the core protocol. MLS has tree rooted forward secrecy by construction. Every commit in a group, every membership change, every key update, produces a new root key and destroys the previous one. In one to one conversations the same property holds. The mathematics are documented in RFC 9420 and a sizeable body of formal verification work cleared the protocol for this property before any production implementation existed.

On post quantum: I shipped a hybrid X25519 plus ML KEM 768 layer on top of MLS from the first release. Hybrid because pure post quantum still spooks me on key sizes and field history. An attacker has to break both the classical and the lattice cryptography to break a session. Session V2 is heading to a similar end point with ML KEM, but on a longer timeline. Today, May 2026, UmbrellaX has post quantum key agreement in production and Session does not. By the end of 2026 that may equalise.

The honest framing: both teams arrived at “we need PFS and post quantum”. We picked different starting points. Session’s came after six years of field deployment and is being retrofitted onto a stateless V1 design. UmbrellaX’s came first, and the protocol was picked to support these properties from day one.

3. Network

Session’s network model is its most distinctive surface. Messages travel through three Session Nodes using onion routing. Each node knows only the previous and next hop, sender and recipient IPs are concealed from any single observer, and the operator (Session Technology Foundation in Geneva) holds no central database of routing decisions. There are more than 1,500 Session Nodes operated by the community and organised into swarms of five to seven. A user’s messages live distributed across that network, not on a foundation server.

That creates a property UmbrellaX does not try to copy. There is no central operator to compel for a routing log. A subpoena addressed to the Session Technology Foundation cannot produce a routing log for a user, because the foundation does not write the routing logs.

I went the other way for a specific reason. Centralised infrastructure is faster, more predictable under hostile network conditions, and easier to harden against a particular set of attacks I take seriously. UmbrellaX runs 167 Rust microservices across 6 nodes day one. The same code scales to 6,000 nodes at a billion users without a rewrite. Nine DPI bypass protocols ship at the transport layer including a WebTunnel variant my team wrote, so when one transport is blocked the client fails over without the user seeing it. I targeted p99 message send under 50 ms and chat open time under 200 ms, end to end including cryptographic operations. Onion routing through three independent operators on Session is, by physics, slower than a direct route through my own infrastructure.

Where my choice has its honest cost: a sufficiently powerful adversary can compel UmbrellaX TOO to hand over what UmbrellaX TOO knows. The defence is that UmbrellaX TOO knows almost nothing. Message content is end to end encrypted, contact graphs are not stored, IP addresses at connection are not retained beyond what is required to route the next message. The defence is data minimisation plus jurisdiction, not a node network. That is a deliberate trade: I give up the no operator story to gain predictable performance, simpler accountability, large encrypted groups, and transport that survives blocks without asking the user to understand the routing layer.

Where Session’s choice has its honest cost: in April 2026 Yu and Haines published a paper reviewed by academic peers at EuroS&P documenting seven vulnerabilities in Session and the Oxen blockchain underneath it, including flaws in the Oxen consensus protocol that allow network takeover in a realistic setting. A successful network takeover undermines the anonymity layer Session leans on. The Session and Oxen teams have responded and mitigations are being shipped. The lesson generalises: a decentralised consensus is a different attack surface to a centralised operator, not a strictly better one. Whether you prefer one or the other depends on which adversary you are sized for.

I would put the Yu and Haines paper on every reader’s desk before they pick decentralised over centralised. Reading it does not push me away from Session. It pushes me toward respect for how complicated the design actually is. The point I want a reader to land on is this: there are two coherent answers to “who routes the bytes”, not one.

4. Group scaling

Session V1 caps groups at 100 members. The group protocol used in V1 had documented vulnerabilities at the time of the Yu and Haines 2026 paper, and Session has been redesigning groups in V2.

I sized UmbrellaX for groups of 200,000 members. The MLS tree handles this with O(log N) key operations per membership change. Adding or removing a member updates the path from the new leaf to the root, which on a tree with 200,000 members is roughly 18 internal node updates. The Signal Protocol approach of layering pairwise sessions for groups would be O(N), which at 200,000 members is impossible. That is why MLS exists.

Why I sized for 200,000. Telegram channels at that size get blocked in countries where I expect UmbrellaX to ship. Protest coordination groups at 5,000 to 50,000 are real. Source protection groups for journalism rarely hit those numbers but the model has to handle them when they do. A ceiling of 100 members is fine for friend groups and small project teams. It is not fine for the kind of broadcast list a country might try to suppress.

Session’s V2 group redesign may close this gap. Today it does not. The cap of 100 members is a fact in the field as of this writing, and the V1 group protocol is the one shipped to users.

5. Jurisdiction

Both UmbrellaX and Session opted out of an Anglosphere jurisdiction for the same reason. We landed in different countries.

Session moved from Australia to Switzerland in October 2024. Alex Linton, president of the new Session Technology Foundation, told 404 Media that “ultimately, we were given the choice between remaining in Australia or relocating to a more privacy friendly jurisdiction”. Switzerland’s data protection regime gives any subject of a subpoena the chance to contest the disclosure before the data is handed over, and the country has been a working home for Proton, Threema, and Nym for similar reasons.

UmbrellaX is incorporated as UmbrellaX TOO in Kazakhstan. Kazakhstan is not in Five Eyes, not in Fourteen Eyes, and has no mutual legal assistance treaty with the United States covering communications surveillance. Kazakh law has its own awkward edges and I am not going to pretend this is a civil liberties utopia. It sits outside the main channels of US, UK, EU, and Australian compellability, and the legal framework on encryption is not openly hostile.

Switzerland and Kazakhstan are different points on the same axis, not a privacy ranking of countries. If the threat model is “an adversary at EU level issues a warrant for the operator”, Switzerland is exposed to that warrant in a way Kazakhstan is not. If the threat model is “the operator’s home jurisdiction unilaterally changes its mind about encryption laws”, Kazakhstan is exposed to that scenario in a way Switzerland is not. I picked one, the Session Technology Foundation picked the other, and a careful reader picks based on which adversary is on their threat model.

Where Session is a narrow specialist

Three places where Session is a narrow specialist. They matter for a specific threat model, but they do not make Session the stronger default private messenger.

Field exposure. Session has been live since 2020. Six years of real users sending real messages on V1 produces operational evidence no formal model replaces on the same timescale. UmbrellaX launches newer in the field, with a protocol designed and reviewed before stable release. I do not hide that difference. I also do not treat field age as a substitute for forward secrecy, post quantum key agreement, and group cryptography designed for the scale I need.

Decentralisation as a structural property. The Session Technology Foundation cannot compel a network of more than 1,500 nodes operated by the community to log routing decisions, because the foundation does not control them. UmbrellaX TOO is one entity that I am responsible for. I chose accountable operation, aggressive data minimisation, and jurisdiction outside the Five Eyes instead of a decentralised routing network. For a reader whose only priority is avoiding any central operator, Session is built around that priority. For the user who also needs speed, group scale, forward secrecy, post quantum, and a clear company to hold responsible, I prefer the UmbrellaX model.

IP level anonymity for the message path. Onion routing through three Session Nodes hides the sender IP from the recipient and the recipient IP from the sender, given a sufficiently large and honest node population. UmbrellaX’s defence is at the application layer plus DPI bypass at transport. I do not route every message through three independent operators by default because I am optimising for reliable delivery, low latency, and usability under censorship. A user whose sole leak concern is the IP level traffic graph may prefer Session for that narrow case. A user who wants private messaging that ordinary people can keep using under pressure gets the stronger overall package from UmbrellaX.

Which to pick

The rule I give people who ask me directly.

Pick UmbrellaX when any of these apply: you need groups larger than 100 people with bounded key operations, you need post quantum and forward secrecy in production today rather than on a roadmap, you want a single accountable operator outside the Five Eyes, you need reliable transport with multiple DPI bypass options, or you want a display handle on top of cryptographic identity.

Use Session when your primary requirement is that the network itself lacks a compellable centre, or when IP level onion routing matters more than forward secrecy, post quantum, group scale, speed, and operational accountability.

A lot of people I know who care about this stuff would run both, the same way they might run both Signal and a Tor browser. Session for the narrow conversations where IP anonymity is the load bearing property. UmbrellaX as the private messenger I would choose for normal sensitive communication, encrypted groups, post quantum hardening, and an accountable operator outside Five Eyes.

I’m Kirill Abramov, founder and CEO of UmbrellaX TOO, a privacy first messenger company registered in Kazakhstan, outside the Five Eyes alliance. I designed UmbrellaX’s cryptographic stack on MLS plus post quantum hardening, 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.