Session

End-to-end encrypted, no phone number, no metadata — honestly reviewed.

TL;DR

• What it is: A decentralized, end-to-end encrypted messenger that routes all messages through an onion network of community-run nodes, collecting zero identifying metadata [1][2].
• Who it’s for: Privacy-conscious individuals, journalists, activists, and teams who handle sensitive communications and can’t afford to have their identity or contact graph exposed [1].
• Cost: Free. No SaaS tiers, no subscription. The infrastructure is a community-run network of Oxen Service Nodes [2].
• Key strength: No phone number required — accounts use randomly generated Account IDs. Even Session’s developers can’t link your account to your real identity [1].
• Key weakness: Smaller active user base than Signal or WhatsApp, onion routing adds measurable latency, and the desktop client’s primary GitHub repository was deprecated during an organizational transition — development continues under the Session Technology Foundation [2].

---

What is Session

Session is an end-to-end encrypted messenger that routes all communications through a decentralized onion network. The goal isn’t just to protect message content — it’s to protect the communication graph itself: who you’re talking to, when, and how often [1][2].

The tagline is “Send Messages, Not Metadata.” Most encrypted messengers stop at content encryption. Signal protects your messages but knows your phone number and has fielded government subpoenas about communication timing and frequency. Session’s architecture is designed to remove that exposure at the protocol level.

When you send a message, it’s encrypted and routed through three random Oxen Service Nodes in sequence before reaching the recipient — similar in concept to Tor’s onion routing. No individual node can see both who sent a message and who received it. Messages for offline recipients are stored encrypted on Service Nodes until delivery [2]. Oxen Service Nodes are community-run, with operators bonding Oxen cryptocurrency to participate — a Sybil resistance mechanism that makes it expensive to compromise a meaningful fraction of the network.

The project has a notable governance history. Session originally forked from Signal’s codebase and was developed by the OPTF (Oxen Privacy Tech Foundation), an Australian non-profit. In 2024, stewardship transferred to the Session Technology Foundation, a Swiss-based organization “dedicated to advancing digital rights and innovation” [2]. The original desktop repository at github.com/oxen-io/session-desktop is now deprecated; active development continues at github.com/session-foundation/session-desktop. Anyone doing long-term dependency evaluation should verify they’re tracking the current repository.

The GitHub repository sits at 1,585 stars [merged profile] — modest relative to Signal’s clients or Matrix, which accurately reflects Session’s position as a specialist privacy tool, not a mainstream messenger.

---

Why people choose it

Session’s core differentiator is three properties in combination that no mainstream messenger offers simultaneously: no phone number, onion routing for metadata, and no central server.

No phone number requirement. Signal, WhatsApp, and iMessage all require a phone number — meaning they know your real-world identity, carriers can associate your number with the account, and contacts can find you without your consent. Session generates a random Account ID on installation. You share that ID with people you want to communicate with. Display names are user-set and not identity-verified [1][2].

Metadata protection through onion routing. Most “encrypted” messengers encrypt content but not the communication graph. Your ISP or a compromised relay can still observe that two parties are communicating, even without reading content. Session’s multi-hop routing is designed to prevent this — no single node knows both sender and recipient simultaneously [2].

No central server to subpoena. The Oxen Service Node network is distributed and community-run. There’s no single company holding your message metadata that a government can compel to produce records. The network survives without any single organization’s servers [2].

These properties come at real cost. Onion routing adds latency. Adding a contact requires exchanging a 66-character Account ID out-of-band (QR code, link, or copy-paste) rather than searching by phone number. Group discoverability is limited. For the threat model Session addresses, these are acceptable trade-offs. For a team that wants encrypted Slack, they are not.

---

Features

Based on the official website and repository [1][2]:

Core messaging:

• End-to-end encrypted one-on-one messages
• Disappearing messages with configurable timers
• Voice messages and media sharing
• Message reactions and replies
• Custom themes

Groups and communities:

• Encrypted group chats for close contacts
• Open Community chats supporting 100+ members [1]
• Community moderation tools

Privacy architecture:

• Account IDs — no phone number, no email required to sign up [1]
• Onion routing via Oxen Service Nodes — IP address obfuscated [2]
• No data collection, no trackers [1]
• No metadata retention on Session’s infrastructure [1]
• User-controlled encryption keys [1]

Platform support:

• Android (Google Play and direct APK)
• F-Droid (for de-Googled Android)
• iOS (App Store)
• Desktop: Windows 10+, macOS Monterey (12)+, Linux with glibc 2.28+ (Debian 10, Ubuntu 20.04+) [2]

Open source:

• GPL-3.0 license [merged profile]
• Full codebase auditable; GPG-signed releases with verified signature process documented in README [2]

What’s notably absent from available data: a REST API, bot framework, or developer integration layer. Session is a consumer messaging application, not a programmable platform.

---

Pricing: SaaS vs self-hosted math

Session doesn’t have a pricing page because there’s nothing to pay. The app is free, the Account ID system is free, and the infrastructure is the community-run Oxen network [1].

This makes the “self-hosted vs SaaS” framing structurally different from most tools reviewed on this site. You don’t run a Session server — that function is served by Oxen Service Nodes operated by third parties globally. You install a client.

Encrypted messenger comparison:

Tool	Phone number required	Central server	Cost
Session	No	No (Oxen network)	Free
Signal	Yes	Yes (Signal Foundation)	Free
WhatsApp	Yes	Yes (Meta)	Free (pays with data)
Telegram	Yes	Yes	Free / $5/mo premium
Wire	No (personal)	Yes	Free personal / ~€5.83+/mo business
Matrix/Element	No	Optional (self-host)	Free self-hosted

Session is the only option in this list with no central server at all. If your team is paying for an enterprise communication plan specifically for privacy or compliance, Session’s architecture is worth understanding — though it may not be the right operational fit (see “Who shouldn’t use this”).

---

Deployment reality check

Session is not a self-hosted application in the conventional sense. You don’t provision a server and run an instance. You install a client app, and the decentralized Oxen network handles routing. This is a deliberate architectural choice: there’s no Session server for an adversary to target, and no instance for you to misconfigure.

What installation actually involves:

• Download the app for your platform (Play Store, App Store, Debian package, Windows/macOS installer) [1]
• Generate an Account ID — automatic on first launch
• Share your Account ID with contacts

No server. No domain. No Docker. No SMTP. No database to manage. The operational surface area is close to zero for end users.

For teams evaluating this as self-hosted team chat: Session is not a replacement for Matrix, Rocket.Chat, or Mattermost. It has no threaded channels, no message search, no integrations, and no admin dashboard. It’s a private messenger, not a team workspace.

Operational concerns worth noting:

• Message delivery reliability depends on Oxen Service Node network participation — no public SLA or uptime data available from current sources
• The organizational transition from OPTF to Session Technology Foundation mid-2024 included deprecating the primary codebase repository [2]; evaluate whether the new governance structure meets your continuity requirements
• The oxen-io/session-desktop repository is now marked deprecated — security advisories and updates should be tracked at session-foundation/session-desktop
• GPG-signed releases are available and the verification process is documented in the README [2]; for high-stakes deployments, verify signatures on install

---

Pros and cons

Pros

• No identifying information required. No phone number, no email — just a generated Account ID [1][2]. Signal, WhatsApp, and Telegram all require phone numbers. Session doesn’t, which means your account isn’t tied to your real-world identity at the infrastructure level.
• Metadata protection, not just content protection. Onion routing obscures the communication graph, not just message content [2]. This is the architectural claim that distinguishes Session from every mainstream encrypted messenger.
• Truly decentralized infrastructure. No single server to subpoena, no single point of failure, no organization holding your metadata [2].
• Free with no tiers. No privacy features locked behind a paid plan. No per-message or per-user pricing [1].
• GPL-3.0 licensed with signed releases. The encryption implementation is public and auditable. Release binaries are GPG-signed with a documented verification process [2].
• Multi-platform, including F-Droid. Android, iOS, Windows, macOS, Linux — and the F-Droid availability matters for de-Googled device users who can’t use the Play Store [1][2].
• 100+ member community chats. Supports large open communities without requiring a separate server deployment [1].

Cons

• Smaller user base than Signal or WhatsApp. Network effects are decisive in messaging. If your contacts aren’t on Session, the privacy properties don’t help you.
• Onion routing adds latency. Multi-hop routing is inherently slower than direct or single-relay connections. Quantified performance data is not available from current sources, but the latency is an architectural consequence.
• Organizational transition adds uncertainty. The OPTF-to-Foundation handoff and repository deprecation in 2024 [2] are governance discontinuities. The project appears actively maintained, but the transition is recent enough to warrant scrutiny for long-term trust.
• 1,585 GitHub stars is modest relative to the security claims. Fewer independent security researchers have audited this codebase than Signal’s or Matrix’s. No independent published security audit was found in available data.
• Not a team collaboration tool. No threads, no channels, no integrations, no search, no admin controls [1]. Evaluating it as a Slack replacement is a category error.
• Account ID UX friction. Exchanging a 66-character hexadecimal string to add a contact is meaningfully less accessible than phone number lookup. Non-technical users will find this confusing.
• Network reliability is opaque. Delivery depends on Oxen Service Node network health, and no data is available on network uptime, node count, or historical reliability.
• Session Token / cryptocurrency entanglement. The Oxen network’s Sybil resistance mechanism relies on cryptocurrency bonding. The homepage prompts visitors about “Session Token.” For organizations with policies against cryptocurrency dependencies, this is worth noting.

---

Who should use this / who shouldn’t

Use Session if:

• Your threat model includes metadata exposure, not just content interception — journalists, lawyers, activists, whistleblowers, security researchers, anyone communicating about sensitive matters under adversarial conditions.
• You need to communicate with contacts who cannot or will not share a phone number.
• You want an encrypted messenger that doesn’t route through any single company’s servers and isn’t legally compellable in a single jurisdiction.
• You’re running de-Googled Android and need an F-Droid-available private messenger.
• You want free, permanent privacy without subscription tiers or usage limits.

Skip it (pick Signal instead) if:

• Your contacts are already on Signal and your threat model doesn’t require metadata protection beyond what Signal provides.
• You need reliable, low-latency voice or video calling.
• You want a larger security research community auditing the implementation.
• Onboarding friction matters — Signal’s phone number discovery has zero setup for new contacts.

Skip it (pick Matrix/Element instead) if:

• You need team collaboration: persistent channels, threaded conversations, search, and bot integrations.
• You want to genuinely control the full server stack and not depend on a third-party network.
• You need federation — encrypted messages across different organizational instances.

Skip it entirely if:

• Your team needs Slack-style workspaces with file search, integrations, and admin dashboards.
• Compliance requirements include message archiving or eDiscovery — Session has no audit trail by design, which is both the feature and the disqualifier.
• You’re evaluating it purely to cut a SaaS messaging bill. The right tool for that is Matrix or Rocket.Chat, not Session.

---

Alternatives worth considering

• Signal — Gold standard encrypted messenger with phone number. Centralized non-profit infrastructure, much larger user base, better voice/video. Phone number requirement is the only meaningful trade-off for most users.
• Matrix / Element — Federated, self-hostable, open standard. Persistent channels, bot integrations, bridges to Slack and Discord. More complex to deploy, but you control the full stack. The right choice for teams escaping SaaS communication bills.
• Wire — End-to-end encrypted, works with email instead of phone number on personal tier. Has a genuine business product. Centralized European servers.
• Briar — Peer-to-peer, works over Tor and Bluetooth/WiFi mesh, zero server dependency. Extreme threat model, extreme friction. For scenarios where Session is still too centralized.
• Threema — Paid (~$5 one-time), no phone number required, centralized Swiss servers, independent security audits published. Good middle ground for users who want pseudonymity without managing onion routing.

For a non-technical founder looking to cut a business communication bill: Matrix self-hosted is almost certainly the right answer. Session solves a different and more specific problem — it’s for people with genuine metadata exposure concerns, not teams looking to replace Slack cheaply.

---

Bottom line

Session’s architecture is technically serious and addresses a threat model that no mainstream messenger handles: protecting not just what you say but who you’re saying it to and when. The combination of no phone number, onion routing, and no central server makes it one of the few messaging tools that can honestly claim to leave no metadata trail. For journalists, activists, legal professionals, and anyone working under genuine adversarial surveillance conditions, Session is worth understanding and deploying.

The trade-offs are equally real. The user base is small, the onion routing adds latency, and a recent organizational transition means the project’s governance continuity deserves scrutiny. Most critically: Session is a private messenger, not a team collaboration tool. If your goal is to cut a SaaS communication bill or replace Slack for your team, you want Matrix — not Session.

For the narrow use case it’s designed for, Session delivers on its core promise. For everyone else, it solves the wrong problem.

---

Sources

1. Session — Official Website — “Send Messages, Not Metadata.” https://getsession.org
2. Session Desktop — GitHub Repository — README, release notes, and repository metadata (oxen-io/session-desktop; active development at session-foundation/session-desktop). https://github.com/oxen-io/session-desktop