Private Messaging for Bitcoiners: SimpleX, Briar, Signal & Nostr DMs

Strong content encryption is now table stakes. The real differences between SimpleX Chat, Briar, Signal, and Nostr DMs are about metadata: who can see that you talked, to whom, when, and how often. This is a neutral, threat-model-first map of four privacy-respecting messengers, with credit to the engineers behind each.

If you run a node, sign with hardware wallets, hold keys across a multisig, or coordinate non-KYC trades, your communications metadata is part of your attack surface. Chain analysis correlates coins; communications analysis correlates people. A sovereign Bitcoiner who encrypts the content of every message but leaks the social graph has solved the easy half of the problem and ignored the hard half.

None of the projects below is “the best.” Each makes a deliberate, well-documented trade-off, and each stands on decades of work by cryptographers, the Tor Project, and the wider open-source community. The right tool depends entirely on what you are trying to defend against. This guide is part of our broader work on digital sovereignty and sovereign computing.

Three things a messenger can protect

Before comparing apps, separate the three distinct properties they can offer. Most arguments online conflate them.

• Content — what you actually said. End-to-end encryption (E2EE) protects this. All four options here protect content well; the differences are subtle.
• Metadata — the envelope around the message: sender, recipient, timestamp, frequency, IP address, message size. Metadata is often more revealing than content, because it is structured, easy to aggregate, and retained at scale. This is where the four projects diverge sharply.
• Social graph — the persistent map of who knows whom. Even with perfect content and per-message metadata hygiene, a system that maintains a server-side contact list, or binds you to a phone number, can reconstruct your network over time.

A useful mental exercise: assume your counterparty’s device, the network operator, and the messaging server are each potentially adversarial. Which of the three properties survives each compromise? Keep that question in mind through every section below.

SimpleX Chat — engineering metadata out of the protocol

SimpleX Chat describes itself as “the first messaging platform that has no user identifiers of any kind.” That is the central design idea, and it credits Signal’s cryptography openly while attacking a different problem. Instead of accounts, usernames, or phone numbers, SimpleX routes messages through unidirectional message queues hosted on SMP (Simplex Messaging Protocol) servers. Each connection between two people uses pairwise, per-queue identifiers, and each message carries its own random, non-sequential ID, so a server cannot link multiple queues back to a single client.

For content, SimpleX uses the double ratchet algorithm designed by Signal (X3DH key agreement with ephemeral Curve448 keys), layered with additional NaCl crypto_box encryption per queue and a further server-to-recipient layer inside TLS to frustrate ciphertext correlation. As of v5.6 (2024) it added a post-quantum hybrid layer to that double ratchet, and v6.0 introduced private message routing so the destination server cannot observe the client’s IP address.

The honest trade-offs, per SimpleX’s own FAQ: you connect by sharing a one-time invitation link or QR code rather than looking someone up, the project deliberately avoids seamless multi-device sync because it admits multi-device support is done “at a cost of compromising security of end-to-end encryption,” and the relay only holds messages for a limited retention window before deletion. SimpleX runs on iOS, Android, and desktop. If your threat model centers on never building a queryable social graph anywhere, this is the most aggressive answer in this set.

Briar — Tor by default, mesh when the internet dies

Briar takes a different stance: there is no server at all. “Messages are synchronized directly between the users’ devices,” using direct, encrypted, peer-to-peer connections. Online, Briar syncs over Tor hidden services, which hides your IP and protects the relationship graph from network surveillance. When the internet is unavailable or censored, Briar can sync over Bluetooth, Wi-Fi, or even removable storage (USB sticks, memory cards) — the property that makes it relevant during blackouts, protests, or remote operations. This offline, device-to-device behaviour overlaps conceptually with radio approaches we cover in mesh networking protocols and the Meshtastic ecosystem, though Briar runs over local IP/Bluetooth rather than LoRa radio.

Each user’s contact list is encrypted and stored only on their own device, so there is no central place to seize a social graph. Forums and blogs are replicated to every subscriber, so there is “no single point where a post can be deleted.” Briar’s documented threat model assumes an adversary who can comprehensively monitor long-range communications and run unlimited devices, but who cannot break standard cryptographic primitives.

The trade-offs are real and worth stating plainly. Briar is Android-only (a desktop companion exists but pairs to a phone); the project has stated it has no plans for an iOS app. Because there is no store-and-forward server, peer-to-peer delivery historically required both parties to be reachable, with the client retrying until the recipient comes online. To soften that, the project added Briar Mailbox, a separate always-on device that accepts messages for you while you are offline. Briar is the strongest fit when censorship resistance and infrastructure independence outrank convenience.

Signal — the gold-standard cryptography, with a centralized envelope

Signal is the most widely deployed messenger here and the origin of the cryptography the others borrow. The Signal Protocol (Double Ratchet plus X3DH, with the PQXDH post-quantum key agreement added in 2023) is the reference standard for content E2EE, independently audited and reused across the industry. For protecting what you say, Signal is exceptional, and credit for that primitive belongs to Signal’s cryptographers.

The nuance is the envelope. Signal is centralized: a single nonprofit operator (the Signal Foundation / Signal Messenger LLC, US-based) runs the servers, and registration requires a phone number. That phone-number binding is the metadata cost. Signal mitigates it from several angles: sealed sender (2018) encrypts the sender’s identity so the server does not see who sent a given message; private contact discovery uses secure enclaves to avoid uploading your address book in the clear; a registration PIN / Registration Lock protects re-registration; and usernames (added March 2024) let you hide your phone number from other users. But Signal can still link a plaintext username to its account, and you must trust the operator’s no-logs posture and the integrity of its infrastructure.

For most people, most of the time, Signal offers the best usability-to-privacy ratio: it runs on iOS, Android, and desktop, delivers asynchronously, and “just works.” For a Bitcoiner whose specific threat model is avoiding a phone number and a central operator entirely, that same centralization is the property to weigh.

Nostr DMs — sovereign identity, two very different encryption regimes

Many Bitcoiners already carry a Nostr keypair for zaps and the social layer, so Nostr direct messages are appealing: your identity is a self-custodied keypair (npub/nsec), not an account a company issues. But “Nostr DM” means two completely different things depending on the spec, and the gap between them is enormous. For background, see our primer on Nostr for Bitcoiners and why it matters for the sovereignty stack.

NIP-04 (legacy, kind 4) encrypts the message body with AES-256-CBC over an ECDH shared secret — but it leaks almost everything around it. The sender’s public key, the recipient’s public key (in the event’s “p” tag), the timestamp, and the message length are all public on every relay. The spec is blunt about this. It is now marked “unrecommended: deprecated in favor of NIP-17,” and warns it “leaks metadata in the events, therefore it must not be used for anything you really need to keep secret.” Treat NIP-04 as a fully public social graph with a private payload.

NIP-17 (private direct messages) fixes the metadata problem with layered encryption defined in NIP-44 and NIP-59. The flow nests three layers: an unsigned message rumor (kind 14 for chat, kind 15 for files), sealed inside a kind 13 seal signed by your real key and encrypted with NIP-44 (a modern versioned scheme using ChaCha20 with HMAC authentication and message padding), then wrapped in a kind 1059 gift wrap signed by a throwaway random key. Because the gift wrap uses a random keypair and a timestamp randomized up to two days, relays cannot see who sent it, to whom, or precisely when. The recipient still learns your real pubkey inside the seal — which is correct, because they need to know who they are talking to — but the public relay does not.

NIP-17’s documented limits: each message must be sent as a separate gift wrap to every recipient, so the spec notes group chats beyond about ten participants should use a different scheme; relays still observe that some gift-wrapped traffic exists; and a naive implementation is a spam target. Delivery depends on the relays you publish in your kind 10050 DM relay list — choose them deliberately, the same way you would pick any Nostr relay. Critically, NIP-17 support varies by client as of mid-2026, so confirm both you and your counterparty are on NIP-17, not silently falling back to NIP-04.

Side-by-side: what each defends

Choosing by threat model, not by hype

Map the tool to the adversary you actually face, not to a leaderboard.

• “I never want a queryable record that two parties communicated.” SimpleX’s no-identifier, per-queue design is built precisely for this. The cost is a less familiar connection flow and no seamless multi-device.
• “I need to communicate during an internet shutdown, or off-grid entirely.” Briar’s Bluetooth/Wi-Fi/USB sync and Tor-by-default transport are the standout here, at the cost of Android-only reach and peer-availability constraints.
• “I want strong, audited encryption with maximum usability and I can accept a phone number and a central operator.” Signal is the pragmatic default, and its cryptography is the benchmark the others build on.
• “My identity is already a keypair and I want messaging that lives in the same sovereign stack as my Bitcoin and Nostr keys.” Nostr NIP-17 fits — provided every counterparty is genuinely on NIP-17, never NIP-04.

For high-stakes operational security, many Bitcoiners run more than one of these and never put all their eggs in a single transport. Pairing an out-of-band channel for key exchange with an in-band channel for ongoing chat is a long-standing OPSEC pattern that predates all four apps.

Operational notes for Bitcoiners

A few hygiene points that apply across all four. First, encryption protects the wire, not the endpoints: a compromised phone, a screenshot, or a shoulder-surfer defeats any of these. Second, key and identity reuse is the quiet leak — if you sign public Nostr notes with the same key you use for sensitive DMs, the content of those DMs is hidden but your identity is already public, so reserve a separate context where appropriate. Third, verify safety numbers / connection links out of band; a man-in-the-middle during the initial handshake undermines everything downstream. Finally, treat retention as a feature to understand, not assume: know how long your chosen relay or server holds undelivered messages, and whether disappearing messages are on.

For definitions of the terms used throughout this guide, the D-Central glossary covers Nostr relays, mesh transports, and related sovereignty concepts in plain language. These tools exist because of years of work by the SimpleX, Briar, Signal, Tor, and Nostr communities; the most sovereign move you can make is to read each project’s own documentation before you trust it with anything that matters.

Frequently asked questions

Which of these messengers is the most private?

There is no single answer, because “private” depends on the threat. SimpleX minimizes server-side metadata and social-graph exposure by using no user identifiers; Briar removes the server entirely and adds offline mesh transport; Signal offers benchmark content encryption with a centralized, phone-number-bound envelope; Nostr NIP-17 hides DM metadata from relays while keeping a self-custodied identity. Match the tool to your adversary rather than ranking them.

Is the content of my messages safe with all four?

For content (the actual words), yes — all four provide strong end-to-end encryption, and three of them build on cryptography Signal designed. The major exception is Nostr’s legacy NIP-04, which encrypts the body but publicly leaks sender, recipient, timestamp, and message length; it is officially deprecated in favor of NIP-17. The big differences between the four are in metadata and social-graph protection, not content.

Why is metadata such a big deal if my messages are encrypted?

Metadata — who, to whom, when, how often, from what IP — is structured, easy to aggregate at scale, and frequently retained even when content cannot be read. For a Bitcoiner, a leaked communications graph can be cross-referenced with on-chain activity to deanonymize trades, signers, or operations. Protecting content while leaking the social graph solves only half the problem.

What is the difference between Nostr NIP-04 and NIP-17 DMs?

NIP-04 (kind 4) is the legacy scheme: AES-256-CBC content encryption, but with the sender pubkey, recipient pubkey, timestamp, and message length all public on relays. NIP-17 wraps messages using NIP-44 encryption plus NIP-59 seals and gift wraps, hiding sender, recipient, and timing from relays. NIP-04 is marked “unrecommended” in the spec; confirm your client and your contact’s client both actually use NIP-17.

Can Briar work without the internet?

Yes. Briar’s distinguishing feature is that it syncs directly between devices over Bluetooth, Wi-Fi, or removable storage when no internet is available, and over Tor hidden services when it is. There is no central server. The trade-offs are that Briar is Android-only, peer-to-peer delivery generally needs the other party reachable, and the optional Briar Mailbox (a separate always-on device) is what enables asynchronous delivery while you are offline.

Do I have to give a phone number to use these?

Only Signal requires a phone number to register; its 2024 usernames let you hide that number from other users, but registration still needs one. SimpleX uses no identifiers at all, Briar uses a local username and password with no account, and Nostr uses a self-custodied keypair. For Bitcoiners avoiding any identity binding, that distinction is often the deciding factor.