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 three places Session still wins.

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 and there is no cleanly correct answer.

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 strongest surface and its most novel. 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 gets you something I cannot offer on UmbrellaX. There is no central operator to compel. 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 has to be data minimisation, not “we have nothing to hand over because the foundation does not have the data in the first place”. Session’s defence is genuinely stronger on that one axis.

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 still wins

Three honest places where Session is still the better choice for the right reader.

Field exposure. Session has been live since 2020. Six years of real users sending real messages on V1 produces a kind of cryptographic proof no formal model replaces on the same timescale. UmbrellaX is launching in 2026 with a protocol independently designed and reviewed by external auditors before stable release, but the time in field number today is zero. If your threat model places the highest weight on “this stack has been carrying real traffic for years”, Session is the honest answer.

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 am committed to data minimisation and I publish what we hold, but the trust model is “the operator behaves” rather than “no operator can”. For a reader who specifically cannot trust an operator to hold to that commitment over time, including because operators eventually change hands, get acquired, or fold under pressure, Session’s structural answer is harder to undo than mine.

True IP level anonymity for the message itself. 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. We do not by default route traffic through three independent operators between the user and the recipient. A user whose specific concern is that the IP level traffic graph is the leak, not the content, gets a stronger guarantee on Session.

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.

Pick Session when any of these apply: you specifically cannot trust a single operator and want the network itself to lack a compellable centre, you specifically need IP level anonymity through onion routing as your primary defence, you want a project with six years of field deployment, or your threat model places more weight on field exposure than on protocol level forward secrecy.

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 conversations where IP anonymity is the load bearing property. UmbrellaX for the conversations where group scale, post quantum hardening, and a known operator outside Five Eyes are what matters. Session and UmbrellaX cover different parts of the same threat model, and that is the most honest framing I can offer.

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.