Signal, Session, SimpleX, Keet, Cwtch, Briar: Which Private Chat App Fits Your Threat Model?

The Spectrum of Commitment: Demystifying the Six Eras of Private Messaging

We have been conditioned to believe a comforting lie: that end-to-end encryption (E2EE) is synonymous with privacy.

When an app boasts that your messages are encrypted, it is offering a digital padlock. If a hostile party intercepts your data stream, they see only ciphertext—gibberish. But this padlock is placed inside a glass box. Passersby cannot read your letter, but they can see exactly who sent it, who received it, at what minute, from which IP address, how frequently you correspond, and the size of the payload.

This peripheral data is called metadata. In modern threat environments, the content of your messages is often the least interesting thing to an adversary. Metadata is what gets people mapped, profiled, fired, or arrested. It reveals associations, habits, and physical locations.

While the consumer tech world has largely settled on Signal as the gold standard of secure communication, a quiet architectural race is occurring beneath the surface. A handful of projects are attempting to solve the metadata problem, each making different structural sacrifices to do so.

To understand these tools, we must look at them not merely as utility apps, but as a spectrum of commitment to privacy. This spectrum represents a gradual escalation of trade-offs:

Signal encrypts your content.
Session removes your identity.
SimpleX erases your existence as a user.
Keet removes the centralized server.
Cwtch removes the metadata.
Briar removes the internet itself.

The Evaluative Framework: The LINDDUN Lens

To evaluate these platforms without relying on vague marketing terms like “unbreakable,” we can look to the LINDDUN threat-modeling framework. Developed by researchers to identify privacy threats in software architecture, we will focus on three of its core pillars:

Identifiability: Can an observer or the system itself link a digital identity (like an account) to a real-world human being (via phone numbers, emails, or IP addresses)?
Linkability: Can an observer connect two or more actions, messages, or sessions to the same user profile over time, even if that profile is pseudonymous?
Detectability: Can an outside party—such as an internet service provider (ISP) or a nation-state firewall—detect that a communication is taking place at all?

Every privacy tool is an exercise in managing these three vectors. There is no silver bullet; choosing one app over another is not a choice between “secure” and “insecure,” but a conscious decision about which threat model you are prioritizing.

                       THE SPECTRUM OF COMMITMENT
                       
  Signal  ------->  Session  ------->  SimpleX  ------->  Keet  ------->  Cwtch  ------->  Briar
 [Encrypts        [Removes Phone     [Erases User       [Removes the    [Removes the     [Removes the
  Content]         Number/ID]         Identifiers]        Server]        Metadata]        Internet]

1. Signal: The Gateway Drug

The Origin and the Irony

Signal is the bedrock of modern secure messaging, and its existence is inseparable from its eccentric co-founder, Moxie Marlinspike. Marlinspike—a sailor, anarchist, and computer scientist—concocted a cryptographic protocol that eventually became the industry standard.

The great irony of Marlinspike’s work is that the Signal Protocol now runs silently inside the machinery of the very surveillance capitalists he sought to bypass: it secures WhatsApp, Google Messages, Skype, and Facebook Messenger.

┌────────────────────────────────────────────────────────┐
│               The Signal Architecture                  │
│                                                        │
│  [User A] ───(E2EE Signal Protocol)───► [Signal Cloud] │
│                                         (Centralized)  │
│                                               │        │
│  [User B] ◄───────────────────────────────────┘        │
└────────────────────────────────────────────────────────┘

Under the current leadership of Meredith Whittaker, a former Google researcher and prominent critic of artificial intelligence and data monopoly, Signal has pivoted into an explicitly political force. Whittaker has positioned the app as a defensive bulwark against state-level surveillance and commercial data scraping.

The Technical Core and the Centralization Debate

Signal operates on a double-ratchet cryptographic algorithm that ensures perfect forward secrecy (if a key is compromised today, past messages remain secure) and break-in recovery (future messages return to being secure).

However, Signal’s defining architectural choice is centralization. Marlinspike famously argued that decentralization breeds stagnation. In his essay “The Ecosystem is Moving,” he asserted that decentralized networks (like email or XMPP) are sluggish because changing them requires consensus from a fragmented community.

By keeping Signal’s servers centralized, his team could rapidly deploy security updates, cryptographic improvements, and features like video calling without waiting for a distributed network to catch up.

The Weakness: Identifiability and the Phone Number

For all its cryptographic strength, Signal has historically suffered from a glaring vulnerability in the identifiability domain: it required a phone number to register. While Signal recently introduced usernames to allow users to hide their phone numbers from daily contacts, your account remains fundamentally tied to a SIM card at the database level.

Furthermore, because Signal’s infrastructure is centralized and hosted on commercial cloud providers (like Amazon Web Services and Google Cloud), an adversary observing network traffic can easily detect when you are connecting to Signal’s servers.

Funding Model: Funded by the non-profit Signal Technology Foundation, kickstarted by a $50 million interest-free loan from WhatsApp co-founder Brian Acton (who left Meta in protest of their data monetization plans).
Target Demographic: Journalists, political campaigns, and everyday citizens seeking a drop-in replacement for SMS or WhatsApp.
The Limitation: High identifiability at registration; metadata (who is talking to whom) remains visible to observers monitoring the centralized network endpoints, even if the server itself cannot read the content.

2. Session: The Onion-Routed Ledger

The Origin: From Blockchain to Messaging

If Signal is a centralized sanctuary, Session is an exercise in distributed trust. Session emerged from the Loki Project in Australia—a privacy-centric cryptocurrency project modeled on Monero.

The developers realized that the infrastructure they were building to route financial transactions could be adapted to route messages. They spun off the Open Privacy Technology Foundation (OPTF) to manage Session as an independent entity, stripping away direct blockchain requirements for the end-user while retaining the underlying decentralized architecture.

┌─────────────────────────────────────────────────────────────────┐
│                    The Session Architecture                     │
│                                                                 │
│  [User A] ───► [Service Node 1] ───► [Service Node 2] ───┐      │
│                     (Layered Onion Encryption)           │      │
│                                                          ▼      │
│  [User B] ◄─────────────────────────────────────── [Service Node 3]
└─────────────────────────────────────────────────────────────────┘

The Technical Core: Decoupling Identity

Session targets the identifiability issue by completely eliminating registration credentials. There are no phone numbers, emails, or usernames linked to real-world identities.

When you open Session, your device generates a public-private key pair. Your public key is a 66-character hexadecimal string—this is your Session ID.

Example Session ID: 05a1b3...[60 characters]...f4e2

To route messages without a central server knowing who you are, Session uses a custom onion-routing network called Lokinet.

When you send a message, it is wrapped in multiple layers of encryption and bounced through three decentralized “service nodes”—servers operated by independent actors who stake cryptocurrency to participate in the network. Each node only knows the hop immediately preceding it and the hop immediately following it. No single node knows both the sender’s IP address and the recipient’s identity.

The Debate: The Node Pool and Ledger Integrity

Session’s primary trade-off lies in the nature of its node network. Unlike Tor, which relies on volunteer nodes, Session’s routing network is run by economically incentivized actors.

This raises an architectural question: Does onion-routing through a known, relatively small, and enumerable set of cryptocurrency service nodes provide the same long-term anonymity guarantees as Tor’s larger, organically distributed volunteer network?

If an adversary were to buy up or compromise a significant portion of these service nodes, they could theoretically perform traffic analysis to link senders and receivers.

Funding Model: Supported by the OPTF, backed by the utility of the Sentinel/OXEN blockchain ecosystem, and sustained by premium features.
Target Demographic: Users seeking high anonymity without giving up modern conveniences like group chats and voice messages, especially those migrating away from platform crackdowns (as seen during Telegram’s policy shifts in late 2024).
The Limitation: Increased latency due to onion routing; potential risk of node sybil attacks if a single actor acquires dominant control over the staking nodes.

3. SimpleX: The Erasure of Identity

The Radical Premise: What if “You” Don’t Exist?

SimpleX introduces a radical design shift: the complete elimination of user identifiers.

In Signal, you have a phone number. In Session, you have a 66-character hex ID. In both cases, you possess a persistent identity that exists within the network. If an adversary compromises your device, they can see your ID and try to map your historical network interactions.

Evgeny Poberezkin, the creator of SimpleX, questioned this fundamental assumption. He designed a protocol where there are no user profiles, no global IDs, and no long-term public keys associated with an account.

┌──────────────────────────────────────────────────────────────────────┐
│                      SimpleX Queue Architecture                      │
│                                                                      │
│  [Sender] ───► [Outbox Queue Server] ───► [Inbox Queue Server] ───┐  │
│                     (One-way, rotating cryptographic hops)        │  │
│                                                                   ▼  │
│  [Receiver] ◄─────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────────┘

The Technical Core: Unidirectional Communication Queues

Instead of assigning you an address, SimpleX builds unique, unidirectional communication channels (queues) for every single contact you have.

If you connect with a friend, your app establishes two independent, rotating queues hosted on servers:

Queue A: For you to send messages to your friend.
Queue B: For your friend to send messages to you.

The servers hosting these queues have no idea they are paired. They simply see incoming and outgoing payloads. The cryptographic keys used to read these queues rotate constantly.

To an observer, or even to the servers processing the traffic, there is no way to link the sender of a message at 9:00 AM with the sender of a message at 9:05 AM. A 2024 audit by security firm Trail of Bits confirmed that the SimpleX protocol successfully isolates these connection graphs.

The Trade-off: High Friction and Zero Recovery

This architectural choice drastically reduces linkability. But it comes at a steep price in usability.

Because there is no central database or persistent user key, there is no “account recovery.” If you lose your phone, drop it in water, or delete the app without a manually exported database backup, your network is permanently gone. There is no way to log back in. Your contacts will see your old queues time out, and you will have to exchange out-of-band invitation links (usually QR codes) to establish connections again.

Funding Model: Seed funding from traditional venture capital, including Bessemer Venture Partners—an unusual bet by institutional investors on a deeply ideological, open-source project with no current monetization funnel.
Target Demographic: High-threat individuals, whistleblowers, and security researchers who require maximum resistance to metadata analysis and relationship mapping.
The Limitation: High cognitive load for backup management; no native multi-device sync without manual database exports; severe vulnerability to data loss if physical devices are compromised or lost.

4. Keet: The Peer-to-Peer Runtime

The Heritage: The Distributed Web

Keet departs from the traditional client-server model entirely. It is built on the Hypercore Protocol (formerly the DAT project), an append-only, signed Merkle log system that has been a staple of the decentralized web (DWeb) ecosystem for over a decade.

Using this mature stack, the parent company Holepunch built Pears (Pear Runtime), a peer-to-peer (P2P) application platform. Keet is the flagship application built to demonstrate what this peer-to-peer runtime can do.

┌────────────────────────────────────────────────────────┐
│                 Keet P2P Architecture                  │
│                                                        │
│  [User A (IP: 192.x.x.1)] ◄────► [User B (IP: 192.x.x.2)] │
│         ▲                               ▲              │
│         │         Direct Connection     │              │
│         └───────────(DHT Lookup)────────┘              │
└────────────────────────────────────────────────────────┘

The Technical Core: Serverless Swarms

When you use Signal, Session, or SimpleX, your data eventually lands on a server (even if encrypted or onion-routed) before being forwarded to your recipient. Keet removes the middleman entirely.

When you start a chat, share a file, or launch a video call on Keet, your device uses a Distributed Hash Table (DHT) to locate your peer’s device. Once found, the devices perform a “hole-punching” routine through their respective firewalls and establish a direct connection.

If you send a 10-gigabyte video file, it streams directly from your storage drive to your friend’s drive. There are no file size limits, no storage fees, and no servers hosting your data.

The Funding Reality and the IP Exposure Trade-off

Keet’s development is funded by Tether, the company behind the USDT stablecoin, and championed by its CEO Paolo Ardoino. This relationship gives the project massive engineering runway, but it also invites skepticism from some corners of the privacy community due to Tether’s centralized corporate nature and regulatory profile.

Furthermore, Keet presents an architectural trade-off that many users may not realize: IP exposure.

Because Keet is a direct peer-to-peer application, your device must connect directly to your peer’s device. To do this, both parties must know each other’s IP addresses. If you are chatting with a stranger or an adversary on Keet, they can easily log your public IP address and deduce your approximate physical location or ISP. The Pear Runtime documentation acknowledges this: “If your IP is sensitive, route through a VPN or Tor.”

Funding Model: Heavily funded by Tether, enabling rapid, high-performance engineering.
Target Demographic: Teams needing to share massive datasets, media professionals conducting video calls without server latency, and DWeb advocates.
The Limitation: Native exposure of your IP address to all chat participants; performance is highly dependent on individual network connection speeds and firewall configurations.

5. Cwtch: The Consensual Sanctuary

The Philosophy: Built for Vulnerable Populations

Cwtch is the most obscure app on this list, but it is arguably the most philosophically consistent. Built by the Open Privacy Research Society under the leadership of Sarah Jamie Lewis, Cwtch takes its name from a Welsh word that translates to both a “safe hiding place” and “a hug.”

This is not a sterile tech project; it is an app designed specifically with and for marginalized communities, including domestic abuse survivors, trans youth, and activists operating under high surveillance.

┌────────────────────────────────────────────────────────┐
│                Cwtch Tor Architecture                  │
│                                                        │
│  [User A] ───(Tor Onion Service)───► [Tor Network]     │
│                                            │           │
│  [User B] ◄───(Tor Onion Service)──────────┘           │
└────────────────────────────────────────────────────────┘

The Technical Core: Tor Onion Services by Default

Cwtch makes a uncompromising architectural decision: every byte of traffic must travel over Tor onion services. There is no “clearnet” fallback.

When you add a contact in Cwtch, you exchange Tor onion addresses. The application runs a lightweight Tor node directly on your device. When you send a message, it never leaves the encrypted, multi-hop anonymity network. This virtually eliminates both linkability and detectability.

Cwtch’s group model is equally unique. In traditional apps, group chats are managed by a central server or shared keys. In Cwtch, a group is an ephemeral “server” hosted locally on one participant’s physical device.

If you host a group and shut your laptop, the group goes offline. If you leave a group, the host’s server loses all cryptographic ability to associate your past presence with your identity. It is built to emulate physical spaces: when you walk out of a room, you leave no footprints behind.

The Unpolished Reality

The trade-off for this uncompromising commitment to privacy is performance.

Running a Tor onion service natively on a mobile device is resource-heavy. It drains battery, demands processor cycles, and struggles with standard mobile operating system background limitations. As a result, Cwtch is often slow, notifications can be delayed, and the mobile experience remains unpolished compared to its desktop counterpart.

Funding Model: Funded entirely by public donations, research grants, and non-profit sponsorships.
Target Demographic: Human rights defenders, marginalized individuals in high-risk environments, and privacy purists.
The Limitation: High battery consumption; slow message delivery; interface and performance are less polished than mainstream apps.

6. Briar: The Offline Resister

The Origin: Built for the Blackout

Briar represents the logical conclusion of the spectrum of commitment. Funded by human rights organizations like the Open Technology Fund, Access Now, and NLnet, Briar was not designed for comfortable offices or standard high-speed networks. It was built for the worst-case scenario: a total internet blackout during an uprising, natural disaster, or military occupation.

┌────────────────────────────────────────────────────────┐
│                Briar Multi-Transport Mesh              │
│                                                        │
│             ┌───────► [Tor (Internet)] ───────┐        │
│             │                                 ▼        │
│  [User A] ──┼───────► [Local Wi-Fi] ──────────┼──► [B] │
│             │                                 ▲        │
│             └───────► [Bluetooth (Mesh)] ─────┘        │
└────────────────────────────────────────────────────────┘

The Technical Core: Multi-Transport Mesh Networking

Briar does not rely on servers, cell towers, or centralized fiber backbones. Instead, it operates across three transport layers simultaneously:

Tor Network: When the internet is functioning, Briar routes messages over Tor onion services, mimicking Cwtch’s metadata protection.
Local Wi-Fi: If the local ISP cuts connection to the wider web but the local router is still powered, Briar routes messages across the local intranet.
Bluetooth Mesh: If cell towers are down and power grids fail, Briar turns your device into a physical mesh node. Messages are transmitted directly from phone to phone via Bluetooth.

If you are in a crowd of protestors during an internet shutdown, your message can hop from your phone, to a stranger’s phone, to a third phone via Bluetooth, until it physically reaches the intended recipient—all without ever touching the global internet.

To solve the asynchronous messaging problem (where peer-to-peer networks require both parties to be online simultaneously), Briar introduced the Briar Mailbox. This allows users to set up a low-power, spare Android device at home to act as an offline store-and-forward relay. It buffers encrypted messages for contacts and delivers them when they come online, without the mailbox owner having the cryptographic keys to read the content.

The Trade-off: Range and Power

Briar is designed to operate in close physical proximity when the internet is cut off. This means its primary trade-off is geographic range.

If your contact is in another country and the internet is shut down, Briar cannot reach them. Additionally, keeping Bluetooth and local Wi-Fi radios constantly polling for peers is incredibly battery-intensive, making Briar impractical as a daily driver for casual communication.

Funding Model: Supported by grants from public interest technology funds and civil liberties foundations.
Target Demographic: Citizens in active conflict zones, environmental activists, journalists, and survivalists preparing for infrastructure failures.
The Limitation: Heavy battery drain; limited range when operating in offline mode; both devices must periodically connect to sync data.

Comparative Matrix

Feature	Signal	Session	SimpleX	Keet	Cwtch	Briar
Primary Focus	Content Encryption	Identity Obfuscation	Metadata Minimization	Serverless P2P	Consent & Sanctuary	Offline Resilience
Registration Required	Phone Number	None	None	None	None	None
Routing Protocol	Centralized Server	Lokinet (Onion)	Unidirectional Queues	Direct P2P (DHT)	Tor Onion Services	Tor / Bluetooth Mesh
Funding Source	Non-Profit / Loans	Crypto Foundation	Venture Capital	Tether (Corporate)	Grants / Donations	Grants
LINDDUN Strength	Content Privacy	Low Identifiability	Low Linkability	Serverless	Low Detectability	Offline Intangibility
Primary Trade-off	Metadata Visible	Lower Node Pool	No Account Recovery	IP Address Exposed	High Latency / Power	Battery / Geo-limits

Threat Model Alignment: Who Should Use What?

The variety of options on this spectrum shows that there is no single “best” app. Security is defined by your threat model:

If your threat model is standard cybercrime and corporate data brokers: Signal is your logical choice. It has the lowest friction, your family and friends will actually use it, and its protocol is peerless for basic content encryption.
If you want to communicate online without revealing your phone number or identity: Session provides a comfortable balance of onion-routed anonymity and modern messaging features.
If your concern is targeted metadata surveillance or relationship mapping by state or institutional actors: SimpleX offers the most robust digital isolation, provided you are willing to take responsibility for your own manual backups.
If you need to share huge files and collaborate in real-time without hosting data on servers: Keet provides high-speed peer-to-peer transfer, though you should route it through a VPN to protect your IP address.
If you are part of a highly vulnerable group requiring a metadata-resistant, consensual space: Cwtch is designed specifically to keep you safe, even if it requires tolerating some performance friction.
If you are preparing for civil unrest, internet censorship, or infrastructure collapse: Briar is an essential utility to keep installed and configured on your devices.

The evolution of these tools shows a clear shift. The privacy movement began by trying to secure centralized conduits (Signal). Today, it is increasingly focused on decentralizing routing (Session), erasing persistent identities (SimpleX), and building alternative physical networks (Briar).

Ultimately, private communication is not about finding an app that promises absolute safety. It is about understanding the boundaries of each digital tool, acknowledging the trade-offs, and choosing the platform that matches your specific needs.