Frequently Asked Questions
Intro
Session is a private messaging app that protects your metadata, encrypts your communications, and makes sure your messaging activities leave no digital trail behind.
Due to the privacy-focused nature of Session, many users choose not to enable auto-updates through the App or Play stores.
The most common solution to issues with Session is to make sure your app is running the latest version.
You can always find the latest version of Session here: https://getsession.org/download
If you require more support you can find the support portal here: https://sessionapp.zendesk.com/hc/en-us
Security
No, Session does not roll its own cryptography. Session uses Libsodium, a highly tested, widely used, and highly-regarded crypto library.
Libsodium is completely open-source.
Conversations in Session are end-to-end encrypted, just as in most private messengers. However, when you use Session, the identities of the people communicating are also protected. Session keeps your communication private, secure, and anonymous.
When using Session, your messages are sent to their destinations through a decentralised onion routing network similar to Tor (with a few key differences), using a system we call onion requests. Onion requests protect user privacy by ensuring that no single server ever knows a message’s origin and destination. For more on this, check out What is an onion routing network? below. For more technical details, you can read this blog on onion requests.
Session’s code is open-source and can be independently audited at any time. Session is stewarded by the Session Technology Foundation, whose mission is to to promote digital rights and innovation.
Session has also undergone a security audit by Quarkslab, the results of which can be found here.
Session encrypts your messages using the Session Protocol, a cutting-edge end-to-end encryption protocol built on libsodium, a highly-audited and widely trusted cryptographic library.
A technical description of the Session Protocol can be found in this technical deep-dive blog.
Session’s desktop, Android, and iOS clients have been audited by Quarkslab. The results of this audit can be found here.
Session allows users to encrypt their local Session database with a PIN code or password on Desktop. With this feature turned on, your messages cannot be accessed without knowing your PIN or password. Learn more here.
Because Session doesn’t have a central server storing information about your identity, restoring your account using the traditional username and password method is not possible. Your recovery password is a mnemonic seed which can be used to restore your existing Account ID to a new device.
Make sure you store it in a safe place!
Your recovery password is like the master key to your Account ID — it’s important to store it safely and securely, and to ensure that only you have access to it. Here are a few options for keeping your recovery phrase safe:
Write your recovery password on a piece of paper, then store it in a safe location.
Consider further securing your recovery password by splitting it into sections using a technique like Shamir’s Secret Sharing.
Remember — the order of the words in your recovery password is crucial. However you store it, ensure that you can reconstruct it in the same order in which it was provided.
Using your recovery password, you can restore your Session Account ID on any device with Session installed. This allows you to keep messaging with your contacts using the same Account ID, rather than having to create a new one. On Desktop Download and install Session on your new computer. Open the Session app, but instead of creating a new Account ID, click I have an account. Enter your recovery password and choose your display name if one had not been previously set. Done!
On Mobile
At the startup screen, tap Continue your Session. Enter your recovery phrase. Enter a new display name and tap Continue. Select your preferred push notification setting and tap Continue. Your Account ID is recovered.
When you restore using your recovery password Session will retrieve any messages sent during the last 14 days. If your messages are not being restored it is most likely because they are more than 14 days old. Contacts and groups are managed by a configuration message which expires after 30 days. If none of your devices have been online for more than 30 days you will be unable to recover your contacts.
Simply put, Session mitigates the same risks that PFS does in other ways.
Through fully anonymous account creation, onion routing, and metadata minimisation, Session provides just as effective protection in real-world scenarios as PFS does, and in some cases even better protection.
For more information check out this blog about the removal of PFS: https://getsession.org/session-protocol-explained
Privacy
You don’t need a mobile number or an email to make an account with Session. Your display name can be your real name, an alias, or anything else you like.
Session does not collect any geolocation data, metadata, or any other data about the device or network you are using. At launch, Session used proxy routing to ensure nobody can see who you’re messaging or the contents of those messages. Shortly after launch, Session moved to an onion routing system, which is called onion requests, for additional privacy protection. For more on Session’s secure message routing, check out What is an onion routing network? and What is proxy routing?
In messaging apps, metadata is the information created when you send a message — everything about the message besides the actual contents of the message itself. This can include information like your IP address, the IP addresses of your contacts, who your messages are sent to, and the time and date that messages are sent.
It’s impossible for Session to track users’ IP addresses because the app uses onion requests to send messages. Because Session doesn’t use central servers to route messages from person to person, it doesn't know when you send messages, or who you send them to. Session lets you send messages — not metadata.
Android
Session’s Android client has two options for notifications: background polling (slow mode), and Firebase Cloud Messaging (fast mode).
If you choose slow mode, the Session application runs in the background and periodically polls its swarm (see What is a swarm) for new messages. If a new message is found, it is presented to you as a local notification on your device.
If you choose fast mode, Session will use Google’s FCM push notification service to deliver push notifications to your device. This requires that your device IP address and unique push notification token are exposed to a Google operated push notification server. Additionally, you will expose your Account ID and unique push notification token to an STF operated push notification server, for the purpose of providing the actual notifications to the Google FCM server.
These exposures are fairly minimal, Google will likely already know your device’s IP address through telemetry data or other applications on your device using push notifications. Registration of your Account ID and unique push notification token to the STF push notification server is necessary for detection and signalling of new messages and is low impact as registration occurs using onion requests, meaning your Account ID and push notification token are never tied to any real world identifier (such as your IP address).
When using fast mode neither Google nor the STF can see the contents of your messages, who you’re talking to, or exactly when messages are sent or received.
iOS
Session’s iOS client has two options for notifications: background polling (slow mode), and Apple Push Notification Service (APNs) (fast mode).
If you choose slow mode, the Session application runs in the background and periodically polls its swarm (see What is a swarm) for new messages. If a new message is found, it is presented to you as a notification on your device.
If you choose fast mode, Session will use APNs push notification service to deliver push notifications to your device. This requires your device IP address and unique push notification token are exposed to an Apple operated push notification server. Additionally, you will expose your Account ID and unique push notification token to an STF operated push notification server, for the purpose of providing notifications to the APNs server.
These exposures are fairly minimal, because Apple will likely already know your device’s IP address through telemetry data or other applications on your device using push notifications. Registration of your Account ID and unique push notification token to the STF push notification server is necessary for detection and signalling of new messages and is low impact as registration occurs using onion requests meaning your Account ID and push notification token are never tied to any real world identifier (such as your IP address).
When using fast mode neither Apple nor the STF can see the contents of your messages, who you’re talking to, or exactly when messages are sent or received.
Session has an F-Droid repo for everyone who wants to avoid the Google Play Store.
Simply head to this address on an Android device with F-Droid installed to add the repo.
Your metadata is not visible to the Session Technology Foundation or Session File Server when sending attachments. However, if you want to prevent your chat partner from seeing file metadata, consider stripping the metadata before sending the file. Here is a how-to article.
Session uses onion routing to hide your IP address when uploading or downloading attachments from the Session File Server. All attachments stored on the server are encrypted, and can only be decrypted by your chat partner(s) — so the Session File Server cannot view your files’ metadata.
In addition to this, EXIF metadata is stripped when sending a file (except videos) sent from Desktop (but not mobile platforms).
Calls
Both voice calls and video calls are currently available as a beta feature in Session.
Calls are currently a beta feature which is turned off by default. In order to opt-in, you'll have to enable calls in your app settings. Here is how you can do it:
Open your app settings
Tap or click on ‘Privacy’
Enable the Voice and video calls option at the bottom of the menu
Calls in Session are end-to-end encrypted and offer a good level of privacy. Unlike messages (which use onion-routed networking), the current implementation of calls uses peer-to-peer networking. This means your IP will be shared with your call partner as well as an STF operated STUN/TURN server. Although this is acceptable for most people, you should always make sure to assess your own personal situation to determine whether the risk of exposing your IP is worth it. If you're in an extremely high-risk situation, consider not enabling peer-to-peer calls — onion-routed calls are on the way.
In order to prevent spam and protect privacy, you can only send and receive calls with people in your contacts list — not unknown Account IDs or people in your message requests.
Session doesn't have group call functionality just yet. Currently you can have a voice or video call between two people.
All calls are made using the webRTC protocol and are end-to-end encrypted. Voice and video calls are facilitated through a peer-to-peer connection, meaning that you and your call partner share the data with each other directly as opposed to routing data through Session's decentralised network.
In order for a call to succeed, both call participants need to enable calls in their settings; the call participants must be in each other's contacts lists. If these conditions aren't met, the call will fail.
If you're expecting a call, make sure you check to see if you have enabled calls in your app settings.
If you are using Slow Mode notifications, you will also need to have Session open and in the foreground in order to successfully receive a call — otherwise you will not get a notification someone is ringing you.
Contacts
On Android or iOS, tap the green plus button at the bottom of the main Messages screen, then tap the chat bubble icon that appears above the plus button. Paste or type your contact’s Account ID into the Account ID field, tap Next, then send your contact a message. Easy as that!
On desktop platforms, click New Session on the main Messages screen, paste or type your contact’s Account ID into the Session ID field, click Next, then send your contact a message.
Note: on desktop, you can also add a contact by clicking Add Contact in the Contacts section of the app.
One challenge with truly anonymous communications systems like Session is that sometimes you do need to verify the identity of the person you’re talking to! In cases like these, it’s best to use a secure secondary channel of communication to confirm with the other person that you’re both who you say you are.
You can delete a contact on Session. This will also delete your conversation, including all messages and attachments. It will not delete your contact or your conversation from your contact's devices. Future messages from this contact will appear as a message request. The other user will not be notified if you delete their contact, and they won't know that their messages to you are taking the form of a message request. If you delete a contact, it will be deleted across all synced devices. On iOS, search for the conversation, swipe left, and select "Delete Contact". Or, open the conversation with the contact you want to delete. Tap the display picture icon in the top-right hand corner to open the conversation settings. Scroll down and select "Delete Contact". On Android, from your list of conversations, press and hold on the profile picture of the contact you want to remove. Tap "Delete". Or, open the conversation with the contact you want to delete. Tap the display picture icon in the top-right hand corner to open the conversation settings. Scroll down and select "Delete Contact". Alternatively, long press on the conversation and select "Delete Contact". Or search for the conversation, tap the conversation, and select "Delete Contact" on the pop-up menu.
On Desktop, right-click on the conversation and select "Delete Contact". Or, open the conversation with the contact you want to delete. Click the display picture icon in the top-right hand corner to open the conversation settings. Scroll down and select "Delete Contact".
Messaging
Session Nodes are the community-operated nodes which make up the Session Network. There are currently over 1,500 nodes on the network. Session Nodes are responsible for validating transactions and data (such as messages) for the Session Network. You can read more about Session Nodes here.
When you send a message, it is sent to your recipient’s swarm. A swarm is a group of Session Nodes tasked with temporarily storing messages for retrieval by the recipient at a later point.
No, your messages are not stored on a blockchain. Messages are stored by swarms, and are deleted after a fixed amount of time (called the “time-to-live”, or TTL).
All of your messages are encrypted, and can only be decrypted using the private key which is stored locally on your device.
Session usernames are permanent alphanumeric names that were previously able to be purchased using the anonymous Oxen cryptocurrency and attached to an Account ID. If you have a Session username attached to your Account ID, others will be able to add you on Session using that name, instead of having to use your full Account ID. Usernames make adding contacts quick and convenient. New Session usernames will be able to be purchased using Session Token ($SESH) in the future, following the launch of the new Session Name Service. Learn more here.
Session Usernames are permanent names which can be purchased and attached to an Account ID. Once purchased and linked, you can give others your Session username and they can add you on Session using that name — much more convenient than dealing with a long, complicated Account ID.
Session nicknames are the names you can set for yourself in Session when you create an Account ID. Nicknames can be changed at any time, but you can’t use a nickname to add someone on Session.
Session can send files, images and other attachments up to 10MB in both person-to-person conversations and group chats. By default, Session uses the Session File Server for attachment sending and storage. The Session File Server is an open-source file server run by the Session Technology Foundation — the stewards of Session. When you send an attachment, the file is symmetrically encrypted on the device and then sent to the Session File Server. To send the attachment to a friend, Session sends them an encrypted message containing the link, plus the decryption key for the file. This ensures that the Session File Server can never see the contents of files being uploaded to it.
A swarm is a collection of 5 – 7 Service Nodes which are responsible for the storage of messages for a predefined range of Account IDs. Swarms ensure that your messages are replicated across multiple servers on the network so that if one Service Node goes offline, your messages are not lost. Swarms make Session’s decentralised network backend much more robust and fault-tolerant.
Disappearing messages have two options: Disappear after Send and Disappear after Read. Both options allow you to set a "time to live" or TTL for the message.
When you send a disappearing message with disappear after send, it is sent to the recipient with a secret instruction to change the default TTL of the message to the time you have selected. Once this time has passed the message will automatically delete from both your device and the recipient's device, as well as from your 'swarm'.
The same is true of disappear after read, with the caveat that the timer for deletion from the recipient's device begins only once they read the message.
Groups
Groups are fully end-to-end encrypted group chats. Up to 100 people can participate in a group chat. Group messages are stored on Session’s decentralised network, without using any central server(s).
The short answer: communities are not as private as person-to-person messages or groups.
The long answer: communities are large public channels where Session users can congregate and discuss anything they want. Communities, unlike other services in Session, are self-hosted and thus not fully decentralised. Someone has to run a server which stores the community’s message history. Additionally, because community servers can serve thousands of users, messages are only encrypted in transit to the server rather than being fully end-to-end encrypted.
For smaller group chats with a higher degree of privacy, users are encouraged to use groups.
Onion Routing
An onion routing network is a network of nodes over which users can send anonymous encrypted messages. Onion networks encrypt messages with multiple layers of encryption, then send them through a number of nodes. Each node ‘unwraps’ (decrypts) a layer of encryption, meaning that no single node ever knows both the destination and origin of the message. Session uses onion routing to ensure that a server which receives a message never knows the IP address of the sender.
Proxy routing was an interim routing solution which Session used at launch while working to implement onion requests. When proxy routing was in use, instead of connecting directly to a Session Node to send or receive messages, Session clients connected to a service node which then connects to a second service node on behalf of the Session client. The first service node then sends or requests messages from the second node on behalf of the mobile device.
This proxy routing system ensured that the client device’s IP address was never known by the Session Node which fetches or sends the messages. However, proxy routing did provide weaker privacy than the onion request system Session now uses.
Lokinet is a powerful onion router that is fast enough to handle real-time voice communications, making it a crucial part of the goal of adding real-time end-to-end encrypted voice calls to Session without relying on central servers.
Contact/Support
If you need assistance or would like to report an issue with Session, please submit a support request here. Session Support will respond to you as soon as possible.
You can hop into the Session community (join the Session Community in Session).
If you are technically minded, you can submit an 'issue' in Session's Github repository.
Alternatively, you can submit a ticket in the help centre.
For the best possible troubleshooting, you can include a debug log from your Session app. You can do this by going to the Settings menu on your device and tapping/clicking 'Debug Log' to generate a log. This will create a log file that you can share when requesting support.
Session welcomes community feedback and feature suggestions!
You can hop into the Session community (join the Session Community in Session).
Alternatively, you can submit a ticket in the help centre to give feedback.
To join a beta branch, check out the instructions for your device below:
Android:
Head to the Play Store and install Session normally
After installing Session, under “Join the beta,” tap Join and then follow the prompts
You can also join from this web page if you are signed into your Google account in your browser.
Note: if ‘Join the beta’ section does not appear, try restarting the Play Store app on your device
or
Download and install any available pre-release APK here.
iOS:
To join the beta on iOS, follow these steps:
Install TestFlight on your device
Opt-in to testing our beta release here
Tap Install or Update
or
Download and sideload the pre-release IPA here.
Desktop
To join the beta on desktop, simply download the relevant executable file from the pre-release here.
Note: It is not currently possible to downgrade versions from the beta branch to an older official version. If your device encounters issues with the beta version, you may need to wait for the next official release or un-install and restore using your recovery password. Restoring will result in the loss of messaging content that is older than 14 days.
Session Token
Session Token ($SESH) is the native cryptocurrency of the Session ecosystem. Session Token can be used to stake to Session Nodes, reward nodes for validating transactions and storage for Session messenger, and soon, to access with advanced features within Session messenger.
It is the core of the Session ecosystem, enabling the decentralized network that powers Session messenger. Session Token offers a new model for bootstrapping and growing a communications overlay network which prioritizes user privacy while remaining sustainable. Learn more here.
Session uses cryptocurrency to provide Sybil resistance to the decentralised network of servers known as the Session Network. For more information check out this blog: https://getsession.org/how-session-protects-your-anonymity-with-blockchain-and-crypto
Nope, Session will always remain free to use. In the future Session may add premium features that provide additional functionality, and access to these features will be activated using either Session Token or traditional payment methods. Note that Session is stewarded by the Session Technology Foundation, a Swiss foundation. Fees for ‘Session Pro’ exist to support the Session Network and ecosystem.
Foundation
The Session Technology Foundation (STF) is a Swiss foundation which stewards Session and its related projects.
In its role as steward, the STF contributes code to Session (including client and node software) and publicly advocates for Session and other privacy-enhancing technologies.
Because Session is decentralised, the Session Technology Foundation’s role is quite different to a standard technology company. Although nobody can truly ‘own’ Session, the STF is the entity responsible for managing core GitHub repositories, app store publishing, and the Session website — because these duties cannot currently be decentralised.
If you would like to learn more about the Session Technology Foundation’s purpose, you can read the President’s founding letter.
Session’s steward, the Session Technology Foundation, is a Swiss foundation with a strong non-profit orientation.
It is constitutionally bound to its mission of promoting digital innovation and rights through contributions to projects like Session. The foundation has no external beneficiaries, and is steered by a dedicated board with extensive experience in decentralised and private technologies.
If you would like to find out more about the foundation and its setup, you can view its Public Deed here.
While Session itself is a decentralised, global ecosystem, its steward is based in Switzerland. Switzerland was chosen as a home jurisdiction for its legal protections regarding personal privacy, world-class cybersecurity and computer science industry, and sophisticated regulation relating to decentralised technologies.
Switzerland’s long history of remaining politically neutral and constitutional right to privacy make it an excellent base for contributing to privacy software. Swiss companies are not allowed to share information with foreign law enforcement, and they cannot be compelled to engage in bulk surveillance.
These Swiss protections strongly reflect the core principles and mission of Session itself, making Switzerland a suitable jurisdiction for its steward, the Session Technology Foundation.
The OPTF is an Australian non-profit organisation which previously stewarded Session. After guiding Session since 2018, the OPTF ended its stewardship of the project in October 2024.
The OPTF remains dedicated to the advocacy and protection of digital privacy. You can read more about the OPTF and Session here.