Your foundation describes Session as “designed to protect privacy, robustness through decentralization, and choice through interoperability.” Can you walk us through the core architectural decisions that make Session resilient to government blocks and centralized outages?
Session is built from the ground up to avoid single points of failure. Rather than sending messages through a single server, traffic moves across a community-run network of thousands of independent nodes, so there is no centralized “pot” of messages which can be monitored or breached.
Nodes only hold messages temporarily while a user is offline. Content is protected with end-to-end encryption, so even when a node stores a message briefly it can’t read or access it. Messages automatically expire after a set time or are deleted once read, preventing long-term storage anywhere on the network.
Session also uses onion routing (a layered encryption method similar to Tor). Each message is wrapped in multiple encryption layers and relayed through several nodes; each node peels off one layer before forwarding. No single node ever knows both the sender and the recipient, and even a compromised node can’t reveal sender, recipient, or content.
Account creation requires no personal details; no phone numbers or emails. Accounts are generated cryptographically, so there’s no direct link between a Session ID and a real person, protecting users even in the event of an external data breach.
By combining decentralization, short-term storage, strong end-to-end encryption, and anonymous onion-routed delivery, Session remains resilient to government censorship and centralized outages while keeping user privacy intact.
Session uses onion routing and a decentralized network rather than a single server model. What are the biggest technical trade-offs you face between censorship-resistance and user experience (latency, message delivery guarantees, onboarding friction)?
Historically, onion routing is associated with slow connections and long load times. However, Session’s onion routing protocol is relatively lightweight, so you can still send messages in just a few seconds.
However, one of the biggest trade-offs comes with the removal of phone numbers. Lots of messaging apps require a phone number to sign up, which means you can import your contacts list and find friends that are using the platform. Although this can make the process of switching messaging apps faster, phone numbers come with privacy and security risks that open the door to spammers and scammers.
Recent real-world shutdowns and blocks force people to switch tools quickly. How does Session design for discovery and onboarding work in places with heavy censorship, limited bandwidth, or intermittent connectivity?
Session is made widely available, including via default app stores (App Store, Play Store), alternative app stores (such as F-Droid and regional alternatives), and direct download (via website or GitHub). This makes it easier for people to access Session — even if the app stores in their region are censored or shut down.
Beyond this, setting up an account on Session does not require any third party authentication. It is common for SMS-2FA services to be attacked or blocked during shutdowns, preventing users from verifying their phone number and signing up to new services. Session gets around this requirement by removing phone numbers in favour of a secure Account ID system.
Anti-censorship often invites attempts to disrupt a network (DDoS, spam, Sybil attacks). What defensive mechanisms does Session use to preserve privacy while keeping the network usable at scale?
Session’s anti-censorship design makes it naturally resistant to network-level attacks like DDoS, spam, and Sybil exploits, while preserving privacy and usability. The network’s defense mechanisms start with its architecture: Session uses onion routing to anonymize traffic, ensuring that no single node ever knows both the sender and recipient of a message. Each message hops through multiple independently operated nodes, which prevents any entity from tracing communication paths or collecting metadata.
To prevent Sybil attacks and large-scale spam, the Session Network employs a staking and reward mechanism built around the Session Token. Node operators must stake a fixed amount of Session Token to join the network, creating a real economic cost that deters malicious actors from flooding it with fake or hostile nodes. This staking also helps maintain operational reliability, since nodes risk their stake if they fail to perform or act dishonestly. In return, operators earn periodic token rewards for routing messages and maintaining uptime, which incentivizes honest and stable participation across a globally distributed network.
The Session Network upgrade allows it to be more accessible to legitimate operators while making coordinated attacks even more expensive to execute. Combined with decentralized governance through the Session Technology Foundation’s non-profit stewardship and the privacy guarantees of end-to-end encryption, these measures ensure that Session remains resistant to censorship, resilient against disruption, and usable at scale without compromising its core mission of anonymity and freedom.
Funding decentralized infrastructure is hard. Session recently launched a token and moved parts of its stack to new networks. Can you explain how the $SESH token and the Arbitrum migration support long-term resilience and infrastructure funding?
The $SESH token and Arbitrum migration are central to Session’s plan for long-term resilience and sustainable infrastructure funding. The $SESH token makes it possible for Session’s network to operate without relying on a central company or single funding source. Node operators stake $SESH to register their servers and, in return, earn token rewards for maintaining network reliability and performance. This spreads both the cost and responsibility for running the network across a global community rather than concentrating it in one organization. The migration to Arbitrum improves scalability, reduces transaction costs, and enables smoother staking and reward distribution, making participation more efficient and accessible for people around the world. The Session Technology Foundation, which guides the ecosystem, uses its token allocation and staking rewards to support core development, research grants, and infrastructure costs while maintaining strict decentralization limits. Together, these mechanisms ensure that Session remains self-sustaining, community-driven, and resistant to central control over the long term.
The Foundation recently changed its operating posture/jurisdiction amid law-enforcement pressures on privacy projects. How do legal and regulatory risks shape technical choices and governance for Session? How do you balance legal compliance against your mission?
Session’s contributors are always advocating for protections to end-to-end encryption, however, some jurisdictions are becoming increasingly hostile towards secure and encrypted services. It is our firm belief that privacy and encryption can make our online spaces safer and more secure, and that encryption is pivotal for our digital future.
Organisationally, it is important that Session has a robust and diverse community of contributors working on the ecosystem. This prevents the changing winds of any one country or jurisdiction from presenting an existential threat to the future of the project.
The stewarding organisation for Session was moved from Australia to Switzerland because the regulatory and legislative environment in Australia was completely hostile towards building a privacy tool such as an encrypted messaging app. Under Australia’s anti-terrorism law, authorities can compel technical assistance from companies, potentially forcing compromises in encryption.
By relocating to Switzerland, a jurisdiction that understands and supports the kind of technology Session uses, the foundation aligned its governance with a legal framework that is more compatible with its mission of anonymity and metadata protection.
This allows the mission to take priority, while also ensuring that the organisation exists in a jurisdiction where the legal risk of undermining that mission is reduced.
In extreme shutdowns, people also use mesh networks, satellite links, or sneakernet. Do you see Session integrating with alternative transport layers (mesh/LoRa/satellite), or is the focus staying strictly on internet-based decentralization?
Right now, Session requires an internet connection to work. However, I am very excited to see the incredible work being done to keep people connected during periods of complete shutdown.
Metadata often reveals more than message content. What specific metadata protections does Session provide (e.g., avoiding centralized contact discovery, ephemeral metadata, routing obfuscation), and what remaining metadata risks worry you most?
Session protects user metadata through several architectural and design choices that make it impossible to collect or store identifying information. The app does not require a phone number or email address when creating an account. Instead, each user is identified only by a Session ID, which removes any link between the messenger and a real-world identity.
Messages are routed through a decentralized network of independently operated Session Nodes, meaning there is no single entity capable of logging or storing metadata about users or their conversations.
Session also uses an onion routing protocol to hide users’ IP addresses and communication routes. Every message travels through randomly selected nodes, and no single node ever knows both the sender and the recipient. Combined with end-to-end encryption, this ensures that message content and metadata remain private even from the network itself.
As a result, Session collects and retains no metadata that could connect messages, users, or network activity to real-world identities.
Humanitarian actors, journalists, and activists are frequent users of censorship-resistant tools. How do you engage with civil society to ensure Session meets their needs, and how do you avoid becoming a vector for wrongdoing without weakening user privacy?
We connect directly with the most at-risk and in-need communities who can make positive use of Session. This includes regularly updating security trainers and educators with information about Session, conducting user research with these communities, and maintaining relationships with organisations that defend human rights.
Interoperability matters if the next wave of secure messaging is to scale. Do you see Session interoperating with other encrypted protocols (Matrix, Signal protocol, XMTP, etc.)? What standards or bridges would you prioritize?
We are definitely open to interoperability and establishing good standards for messaging. As to which standards would be prioritized, this would depend entirely on the needs of our community, the technical feasibility, and the maturity of the standard. However, it’s also worth noting that having a diversity of solutions is quite valuable when it comes to resisting state-level censorship or interference.
Looking ahead 3–5 years: what single technical or policy change would most improve the global ability for people to communicate freely during state-level blocks, and what is Session doing today to move that needle?
Encrypted services need multilateral support from NGOs and world governments and proper legal protections for the right to encrypt.
Currently, all encrypted services exist under the grey cloud of assistance notices and scanning requirements. Without encryption, the ability to communicate freely—under shutdowns or otherwise—will be removed completely. Hostile states will soon be able to monitor communications (such as of activists or journalists) and subsequently penalize their opponents.
Encryption is the foundation on which most censorship-resilient technology stands. The undermining of encryption or the ability to provide encrypted services would be disastrous for those in less free regions.
