From encrypted chats to decentralized messaging
Encrypted messaging apps are experiencing a resurgence.
Platforms like WhatsApp, iMessage, and Signal have established end-to-end encryption (E2EE) as a standard expectation. However, many still depend on phone numbers, centralized servers, and extensive metadata, including details like who you communicate with, the timing, originating IP address, and device type.
Vitalik Buterin’s recent X post and donation highlight the future of secure messaging, focusing on permissionless account creation that requires neither phone numbers nor Know Your Customer (KYC) processes, alongside enhanced metadata privacy. In this context, he specifically noted Session and SimpleX, donating 128 Ether (ETH) to each to encourage their progress.
Session serves as a noteworthy example, merging E2E encryption with decentralization. It operates without a central message server, utilizes onion routing for traffic, and replaces phone numbers with user IDs as keys.
Did you know? Forty-three percent of individuals using public WiFi report having encountered a data breach, with common causes including man-in-the-middle attacks and packet sniffing on unencrypted traffic.
How Session stores your messages
Session relies on public key identities for its framework. When you register, the application generates a keypair locally and creates a Session ID from it, negating the need for a phone number or email.
Messages traverse a network of service nodes using onion routing, ensuring that no single node can access both the sender and recipient. (You can check your message’s routing path in the settings.) For asynchronous delivery while offline, messages are saved in small groups of nodes termed “swarms.” Each Session ID is linked to a specific swarm, where messages are encrypted until retrieved by the client.
Historically, messages had a default life span of about two weeks within the swarm. After that, the network copy is lost, and only what is stored on your devices remains.
Moreover, Session maintains a local database of your conversations and attachments, allowing you to scroll through history that spans months or even years. Therefore, while the app download size may be around 60 to 80 MB, the storage usage increases as you send media, cache thumbnails, and keep chat history. Public documentation and independent reviews have outlined this distinction between temporary network storage and enduring local storage.
You can reduce storage consumption by deleting conversations, employing disappearing messages, or clearing media. If a message is retrievable, it exists somewhere on your device.
Fast Mode notifications
Notifications illustrate the privacy and user experience (UX) trade-off vividly.
On iOS, Session provides two operational modes:
Slow Mode entails background polling. The app periodically wakes up to check for new messages via its own network. This method is more private but may result in delays or unreliability, especially if your operating system limits background activities.
Fast Mode employs push notifications. Session utilizes Apple Push Notification Service on iOS and a comparable approach on Android for timely alerts.
The contentious aspect revolves around Fast Mode. According to Session’s support documentation, enabling it means:
Your device’s IP address and push token are shared with an Apple-operated push server.
Your Session Account ID and push token are disclosed to a Session-run push server for notification delivery.
Importantly:
The servers cannot access message content, as they remain E2EE.
Session claims that Apple and Google do not have visibility into your communication partners or specific message timing beyond what their generic push infrastructure logs.
If this information concerns you, Slow Mode is an option, but it may lead to missed or delayed notifications. This choice exemplifies what decentralized messaging requires users to consider.
Jurisdiction, transparency and government requests
Session’s governance has undergone changes.
Initially, the app was managed by the Australian nonprofit Oxen Privacy Tech Foundation (OPTF). In late 2024, a new Swiss entity, the Session Technology Foundation (STF), took over oversight of the project. OPTF’s last transparency report covers Q4 2024; subsequent requests are processed and reported by STF.
Session’s documentation on information requests states:
Given that Session is decentralized and E2EE, the foundation lacks special access to user messages or keys.
The STF issues retrospective transparency reports summarizing how law enforcement requests are handled.
This transparency page likely serves as the reference point for users discussing governmental requests for information. It maintains a public record documenting requests from authorities, their content, and Session’s responses.
What can they realistically provide?
Potentially: Logs from websites, file servers, or infrastructure they operate directly, such as push relays or STUN and TURN servers for calls, subject to Swiss law and any appropriate international requests.
Not: Decrypted messages or master keys for user chats, provided the implementation aligns with the protocol specifications.
Switzerland’s foundation regime offers a relatively lenient approach to transparency compared to other jurisdictions, making voluntary reports and technical limitations on data particularly crucial.
In essence, decentralization doesn’t prevent governments from making requests, but it limits what can be disclosed.
Did you know? When police infiltrated the EncroChat encrypted phone network, they intercepted over 115 million criminal messages from roughly 60,000 users, leading to more than 6,500 arrests and nearly 900 million euros in assets seized globally.
Quantum resistance, calls and “beta forever?”
The concern is to harvest now and decrypt later. Adversaries have the ability to record encrypted traffic today and wait for future quantum computers to break existing public key systems.
Session’s solution involves a significant protocol redesign. In a recent blog post, the team introduced Session Protocol v2, which aims to implement:
Perfect forward secrecy using ephemeral keys
Post-quantum key exchange based on ML-KEM (formerly CRYSTALS-Kyber), a NIST-standardized KEM also utilized in Signal’s PQXDH and Apple’s PQ3.
So, is Session quantum resistant today?
Not in a strict sense. It continues to rely on classical elliptic curve cryptography while v2 development is ongoing. The roadmap indicates a shift towards hybrid post-quantum schemes, but until those are fully integrated, audited, and deployed across all clients, you should assume conventional end-to-end encryption security with plans for future upgrades.
Calls represent another recurring issue. According to Session:
Voice and video calls are available but remain in beta, requiring user activation.
Currently, they use peer-to-peer WebRTC, which discloses your IP address to the other party and to a Session-operated STUN or TURN server for signaling and media relay.
Onion-routed calls over Lokinet are planned to obscure IP addresses more effectively but are not yet the default.
Session’s blog and FAQ explicitly caution that individuals in particularly sensitive situations might prefer to avoid enabling calls for the time being.
Thus, the prolonged beta phase partly reflects the challenges in integrating low-latency calls, onion routing, and robust anonymity safeguards.
What decentralization actually changes for you
Session exemplifies both the potential and the limitations of decentralized secure messaging.
On the positive side:
You can set up an account without a phone number, email, or any form of identification, aligning with Buterin’s vision of permissionless account creation.
Your messages navigate through an onion-routed multi-node network, minimizing the metadata any single operator can access or be forced to log.
The governance shift to Switzerland, coupled with the use of open-source clients and transparency reports, may enhance public scrutiny over modifications to the codebase or infrastructure.
However, decentralization is not a panacea:
Local storage on your device poses a significant risk if your device is seized or compromised.
Fast Mode notifications and WebRTC calls leak IP-level metadata to infrastructure operators, even if they never access your plaintext messages.
Post-quantum defense remains a future goal until Protocol v2 is completed and stabilized.
If you are contemplating using Session, it may be wise to consider Slow Mode as your default if protecting metadata privacy is more critical than receiving instant notifications. Utilize disappearing messages and regularly delete old chats and media to minimize what remains on your devices. The same caution applies to calls. If associating a Session ID with an IP address poses a risk in your situation, it might be safer to keep voice and video options disabled until the calling functionality is refined.
More broadly, E2EE alone no longer suffices. As governments intensify scrutiny of messaging platforms and quantum threats evolve from theoretical concepts to actionable roadmaps, decentralization, metadata minimization, and post-quantum enhancements are becoming integral components of secure messaging. Session is among several initiatives striving to tackle these challenges, each presenting its own trade-offs, advantages, and constraints.
