Session is a free, open-source, and decentralized end-to-end encrypted instant messenger focused on user privacy, anonymity, and metadata minimization. The application allows users to create accounts and communicate without requiring a phone number, email address, or any other personally identifiable information. Developed and maintained by the Session Foundation, it is built upon the Session Network, a decentralized network of community-operated nodes. The project's guiding principle is summarized by its slogan, "Send Messages, Not Metadata." ^[1]​

History and Governance

Session was initiated by the Loki Foundation, an Australian non-profit organization dedicated to developing privacy technology. The foundation was later rebranded as the Oxen Privacy Tech Foundation (OPTF) and served as the initial steward of the project starting in 2018. The technical whitepaper detailing Session's protocol and architecture was published on arXiv in February 2020. ^{[2] [3]}​

In October 2024, stewardship of the Session project transitioned from the OPTF to the newly formed Session Technology Foundation (STF), a non-profit foundation based in Switzerland. The STF was established to oversee the ongoing development, governance, and promotion of the Session messenger and its ecosystem. The choice of Switzerland as a base was due to the country's strong personal privacy laws and sophisticated regulations concerning decentralized technologies. ^[4]​

The Session project is built on years of open-source development, supported by a global community of contributors and the operators of the nodes that form its network infrastructure. ^[5]​

Technical Architecture

Session's architecture is a multi-layered system designed for decentralization and anonymity, combining a user-facing application with a distributed backend network. It does not use central servers for message delivery or data storage. ^[6]​

The Session Network

The application's backend is the Session Network, a decentralized peer-to-peer system consisting of over 1,500 community-operated "Session Nodes" distributed across more than 50 countries. These nodes are responsible for message validation, routing, and temporary storage. The network operates on a Proof-of-Stake (PoS) consensus mechanism. To run a Session Node, an operator must stake a significant amount of the Session Token ($SESH). This financial requirement provides Sybil resistance, making it prohibitively expensive for a malicious actor to control a large portion of the network, and incentivizes reliable service through block rewards. ^[7]​

To handle the performance demands of a modern messenger, the network offloads certain tasks to a low-fee sidechain, utilizing Arbitrum One, an Ethereum Layer 2 scaling solution. This "appchain" is designed for high throughput for tasks like name registrations. ^{[3] [7]}​

Anonymity and Routing

Session employs a custom onion routing system called "onion requests" to protect user metadata and obfuscate IP addresses. When a user sends a message, it is wrapped in multiple layers of encryption and routed through a path of three randomly selected Session Nodes before reaching its destination. ^[4]​

The routing process ensures that:

• The first node (entry) knows the sender's IP address but not the final destination.
• The second node (middle) only knows the identity of the entry and exit nodes.
• The third node (exit) knows the destination (the recipient's message swarm) but not the original sender's IP.

This design effectively dissociates a user's IP address from their message, making it difficult for any single node or an external observer to trace the communication's origin. The project has stated one of its goals is integrating Lokinet, a low-latency onion router, to enable more complex anonymous communications like voice and video calls in the future. ^{[3] [7]}​

Message Storage and Swarms

For asynchronous messaging, Session uses a decentralized storage system based on "swarms." A swarm is a small, distributed, and redundant group of 5 to 10 Session Nodes responsible for storing offline messages for a specific range of Session IDs. When a message is sent to an offline user, it is delivered to their designated swarm and held until the recipient's device comes online to retrieve it. Messages are stored with a fixed Time-to-Live (TTL) and are deleted after being delivered or after the TTL expires, minimizing the data retention footprint. This swarm-based architecture provides fault tolerance and ensures message availability even if some nodes in the network go offline. ^{[6] [3]}​

Encryption and The Session Protocol

All one-on-one and group conversations in Session are end-to-end encrypted using the Session Protocol, which is a custom protocol derived from the Signal Protocol but heavily modified for a decentralized, asynchronous environment. It utilizes a highly audited, open-source cryptographic library, libsodium, for its cryptographic primitives. ^[4]​

Unlike the Signal Protocol, the Session Protocol for one-on-one chats is stateless and does not use key ratcheting. A message is signed with the sender's long-term private key and then encrypted for the recipient's public key. This design decision means Session does not implement Perfect Forward Secrecy (PFS). The developers argue that PFS primarily mitigates the risk of a compromised long-term key being used to decrypt past intercepted messages. They contend Session's architecture addresses this threat more comprehensively through its core design, which includes anonymous accounts, mandatory onion routing, and minimal metadata exposure, making targeted interception significantly more difficult. ^{[4] [3]}​

Because messages are signed with a long-term key, they are technically attributable. However, the client software is designed to delete the signature immediately after validation, meaning an unmodified client cannot prove message origin to a third party. This provides a form of plausible deniability at the application level. ^[3]​

Identity and Accounts

Session's identity system is designed to be completely anonymous and decoupled from real-world identifiers. ^[4]

Session ID

Upon first use, the application generates a unique, 66-character alphanumeric Session ID on the user's device. This ID is an Ed25519 public key that serves as the user's public address on the network for receiving messages. No phone number, email, or other personal data is required to create a Session ID, severing the link to a user's real-world identity. ^[3]

Recovery Password

Along with the Session ID, a mnemonic seed phrase, referred to as a "recovery password," is generated. This phrase represents the account's private key and is the only method to restore a Session ID on a new or different device. Because there are no central servers holding account data, losing the recovery password results in the permanent loss of the associated account. Multi-device support is achieved by sharing this recovery password across devices. ^[4]

Session Name Service (SNS)

To simplify adding contacts, Session offers the Session Name Service (SNS), a decentralized naming system built on smart contracts. It allows users to register a permanent, human-readable username (e.g., "JohnDoe") and map it to their Session ID. These names can be purchased with the Session Token (SESH) and are registered on the blockchain to prevent squatting and ensure uniqueness. ^[7]

Tokenomics

The Session ecosystem is supported by the Session Token ($SESH), its native utility token. Using the Session Messenger app is free and does not require owning or interacting with the token. ^[4]​

SESH is an EVM-compatible token issued on the Ethereum and Arbitrum One blockchains. Its primary purposes are to provide economic security for the Session Network and to facilitate value transfer within the application's ecosystem. ^[8]​

The utility of the $SESH token includes:

• Network Security & Staking: A substantial amount of SESH must be staked by operators to run a Session Node. This serves as collateral, securing the network against attacks and ensuring node operators are invested in the network's health.
• Incentivization: Session Node operators are rewarded with SESH for contributing bandwidth, storage, and computational resources to the network.
• Application-Layer Features: SESH is used to purchase premium features, such as registering a username via the Session Name Service (SNS). It is also intended for future features like "Session Pro," which may provide advanced functionalities. ^{[1] [8]}

Features

Session provides a range of communication and privacy features across its clients for desktop (Windows, macOS, Linux) and mobile (Android, iOS). ^[1]

Communication

• Private and Group Chats: Session supports standard one-to-one chats and end-to-end encrypted group chats for up to 100 members. Group messages are multicast to the swarms of all members, avoiding a central server for management. ^[4]
• Communities: For larger-scale discussions (100+ members), Session offers "Communities." These are public channels that are centrally hosted on a user-run, open-source server. Communications with the server are onion-routed to protect member IP addresses, but the messages themselves are not end-to-end encrypted among all members, only transport-encrypted to the server. This offers a lower level of privacy than groups. ^[3]
• Voice and Video Calls: The application supports end-to-end encrypted voice and video calls. This feature is in beta and currently uses a peer-to-peer (P2P) connection via WebRTC. This implementation may expose the user's IP address to their call partner and an STF-operated STUN/TURN server. Future development aims to implement onion-routed calls to conceal IP addresses. ^[4]

Messaging and Privacy

• Attachments: Users can send files and images up to 10MB. Attachments are symmetrically encrypted on-device before being uploaded via an onion request to an STF-operated "Session File Server." The decryption key and file link are then sent to the contact in a standard end-to-end encrypted Session message, ensuring the file server cannot view the contents. ^[4]
• Disappearing Messages: Users can set messages to automatically delete from all devices and the network swarm after a timer expires. Options include "Disappear after Send" and "Disappear after Read." ^[4]
• Push Notifications (Mobile): Session offers two modes for notifications on mobile devices:
  • Fast Mode (Default): Uses Google’s FCM or Apple’s APNs. This standard method may expose the device's IP to Google or Apple but protects message content and sender identity from them.
  • Slow Mode (Polling): The app runs in the background and periodically polls the network for new messages. This mode avoids Google/Apple services, offering higher privacy at the cost of increased battery consumption and slower notification delivery. ^[4]
• Message Requests: Messages from unknown contacts are filtered into a separate request folder, allowing users to accept, delete, or block the contact to prevent spam. ^[9]

Development and Security

Session is developed as open-source software, with its code publicly available for audit and contribution. ^[1]

Open Source

The client applications for Android (Kotlin), iOS (Swift), and Desktop (TypeScript), along with core libraries, are available on the Session Foundation's GitHub organization. The software is primarily licensed under the GNU General Public License v3.0 (GPL-3.0). ^[2]

Security Audits

The Session desktop, Android, and iOS clients have undergone a security audit by the third-party firm Quarkslab. The results of this audit are publicly available. ^[4]

Threat Model

Session is designed to protect against surveillance from corporate and state-level actors by minimizing metadata. Its primary protections include obscuring user IP addresses, preventing the creation of a social graph (who is talking to whom), and securing message content with end-to-end encryption. The project acknowledges that its low-latency onion router is vulnerable to traffic correlation attacks from a Global Passive Adversary (GPA)—an entity capable of monitoring traffic at both the user's entry point and the network's exit point. Future research goals include investigating the implementation of a Mixnet to provide stronger protection against such threats. ^[3]