From encrypted chats to decentralized messaging
Encrypted messengers are having a second wave.
Apps like WhatsApp, iMessage and Signal made end-to-end encryption (E2EE) a default expectation. But most still hinge on phone numbers, centralized servers and a lot of metadata, such as who you talk to, when, from which IP and on which device.
That is what Vitalik Buterin is aiming at in his recent X post and donation. He argues the next steps for secure messaging are permissionless account creation with no phone numbers or Know Your Customer (KYC) and much stronger metadata privacy. In that context he highlighted Session and SimpleX and sent 128 Ether (ETH) to each to keep pushing in that direction.
Session is a good case study because it tries to combine E2E encryption with decentralization. There is no central message server, traffic is routed through onion paths, and user IDs are keys instead of phone numbers.
Did you know? Forty-three percent of people who use public WiFi report experiencing a data breach, with man-in-the-middle attacks and packet sniffing against unencrypted traffic among the most common causes.
How Session stores your messages
Session is built around public key identities. When you sign up, the app generates a keypair locally and derives a Session ID from it with no phone number or email required.
Messages travel through a network of service nodes using onion routing so that no single node can see both the sender and the recipient. (You can see your message’s node path in the settings.) For asynchronous delivery when you are offline, messages are stored in small groups of nodes called “swarms.” Each Session ID is mapped to a specific swarm, and your messages are stored there encrypted until your client fetches them.
Historically, messages had a default time-to-live of about two weeks in the swarm. After that the network copy is gone, and only what is on your devices remains.
And yes, Session keeps a local database of your chats and attachments so you can scroll back months or years. That is why the app download might be around 60 to 80 MB, but the installed size grows as you send media, cache thumbnails and maintain chat history. Public documentation and independent reviews have described this split between short-lived network storage and long-lived local storage.
You can trim this by deleting chats, using disappearing messages or clearing media. If you can still see it, it lives somewhere on your device.
Fast Mode notifications
Notifications are where the privacy and user experience (UX) trade-off becomes obvious.
On iOS, Session offers two modes:
-
Slow Mode is background polling. The app wakes up periodically and checks for new messages over its own network. It is more private but can be delayed or unreliable, especially if your OS is aggressive about background activity.
-
Fast Mode uses push notifications. Session uses Apple Push Notification Service on iOS and a similar approach on Android to deliver timely alerts.
The controversial bit is Fast Mode. According to Session’s own support docs, using it means:
-
Your device IP address and push token are exposed to an Apple-operated push server.
-
Your Session Account ID and push token are shared with a Session-run push server so it knows which notifications to send where.
Crucially:
-
The servers do not see message contents because those stay E2EE.
-
Session says Apple and Google also do not see who you are talking to or the exact message timing beyond what their generic push infrastructure necessarily logs.
If that bothers you, Slow Mode exists, but you pay with missed or late notifications. That choice is part of what decentralized messengers now force users to think about.
Jurisdiction, transparency and government requests
Session’s governance has also changed.
The app was originally stewarded by the Australian nonprofit Oxen Privacy Tech Foundation (OPTF). In late 2024, a new Swiss entity, the Session Technology Foundation (STF), took over stewardship of the project. OPTF’s final transparency report covers Q4 2024; later requests are handled and published by STF.
Session’s support documentation on information requests states:
-
Because Session is decentralized and E2EE, the foundation has no special access to user messages or keys.
-
The STF publishes retrospective transparency reports summarizing law enforcement requests and how they were handled.
That transparency page is almost certainly the reference point users have in mind when they talk about a site that shows when governments ask for information. It is the public record the foundation maintains to document when authorities reach out, what they request and how Session responds.
What can they realistically hand over?
-
Potentially: Logs from websites, file servers or infrastructure they directly operate, such as push relays or STUN and TURN servers for calls, subject to Swiss law and any applicable international requests.
-
Not: Decrypted messages or master keys to user chats, assuming the implementation matches the protocol description.
Switzerland’s foundation regime is relatively light touch on transparency compared to some jurisdictions, which makes voluntary reports and technical limits on data especially important.
In other words, decentralization does not stop governments from asking, but it constrains what there is to hand over.
Did you know? When police infiltrated the EncroChat encrypted phone network, they intercepted more than 115 million criminal messages from an estimated 60,000 users, which led to over 6,500 arrests and nearly 900 million euros in seized assets worldwide.
Quantum resistance, calls and “beta forever?”
The worry is harvest now, decrypt later. Adversaries can record encrypted traffic today and wait for future quantum computers to break current public key schemes.
Session’s answer is a major protocol redesign. In a recent blog post, the team unveiled Session Protocol v2, which aims to add:
-
Perfect forward secrecy with ephemeral keys
-
Post-quantum key exchange using ML-KEM (formerly CRYSTALS-Kyber), the NIST-standardized KEM also appearing in Signal’s PQXDH and Apple’s PQ3.
So, is Session quantum resistant today?
Not in the strict sense. It still relies on classical elliptic curve cryptography while v2 is under development. The roadmap points to hybrid post-quantum schemes, but until those are implemented, audited and rolled out across all clients, you should assume standard end-to-end encryption security with a plan to upgrade.
Calls are another recurring concern. According to Session:
-
Voice and video calls are available but are still a beta feature you must opt into.
-
They currently use peer-to-peer WebRTC, which exposes your IP address to the other party and to a Session-run STUN or TURN server for signaling and media relay.
-
Onion-routed calls over Lokinet are planned to hide IPs more thoroughly but are not yet the default.
Session’s own blog and FAQ explicitly warn that people in extremely sensitive situations may want to avoid enabling calls for now.
So, the long beta is partly a reflection of how hard it is to combine low-latency calls, onion routing and serious anonymity guarantees.
What decentralization actually changes for you
Session shows both the promise and the limits of decentralized secure messaging.
On the plus side:
-
You can create an account without a phone number or email (or any ID), which aligns with Buterin’s idea of permissionless account creation.
-
Your messages travel through an onion-routed multi-node network, which reduces the amount of metadata any single operator can see or be compelled to log.
-
The stewardship move to Switzerland and the use of open-source clients and transparency reports may increase public scrutiny of changes to the codebase or infrastructure.
But decentralization is not a cloak of invisibility:
-
Local storage on your phone is still a major risk if your device is seized or compromised.
-
Fast Mode notifications and WebRTC calls leak IP-level metadata to infrastructure providers, even if they never see your plaintext messages.
-
Post-quantum protection remains on a roadmap until Protocol v2 ships and matures.
If you are considering Session, it makes sense to treat Slow Mode as your default if metadata privacy matters more than instant notifications. Use disappearing messages and periodically prune old chats and media so less is left on your devices. The same caution applies to calls. If linking a Session ID to an IP address is a concern in your situation, it may be safer to keep voice and video disabled until the calling stack matures.
More broadly, E2EE on its own is no longer enough. As governments increase pressure on messengers and quantum threats move from theory into roadmaps, decentralization, metadata minimization and post-quantum upgrades are becoming core parts of what secure messaging means. Session is one of several projects attempting to address these challenges, each with its own trade-offs, strengths and limitations.
