The Complete SimpleX Chat Hardening Guide (2025–2026)

• SimpleX is the only mainstream messenger with no user identifiers of any kind — no phone number, username, or even a random/cryptographic ID — which is its single biggest privacy advantage over Signal; harden it by setting a database passphrase, enabling SimpleX Lock with a self-destruct passcode, enabling multiple server operators (SimpleX Chat + Flux), and using Incognito or hidden profiles plus Tor where your threat model demands it.
• Its strongest property is metadata resistance: relays see disposable per-queue identifiers, not who-talks-to-whom; post-quantum hybrid encryption is on by default in direct chats (v5.7+) and private message routing (2-hop onion) protects your IP by default since v6.0.
• Its biggest gaps are adoption (your contacts must be on it), no secure multi-device sync, the fact that contacts/devices you trust can still betray you, and that a powerful adversary watching both endpoints can still do timing correlation — SimpleX is decision-ready for high-metadata-privacy use cases but is not magic against endpoint compromise.

Key Findings

1. No identifiers is the architecture, not a feature. SimpleX assigns no identity layer. Connections are bootstrapped out-of-band via one-time invitation links, QR codes, or optional long-term contact addresses. Each conversation uses two unidirectional ("simplex") message queues with separate anonymous credentials, so no global address space exists.
2. Defaults are already strong but not maximal. The database is encrypted at rest with a random key in Keychain/Keystore; private message routing and post-quantum encryption are enabled by default. But the database passphrase is stored on-device by default; SimpleX Lock is opt-in; Tor is opt-in; and Flux servers may need to be enabled.
3. Current version line is v6.4.x stable (late 2025) moving to v6.5.x (2026) with public Channels, non-profit governance (SimpleX Network Consortium/Foundation), and link-safety features.
4. Two independent Trail of Bits reviews — a November 2022 implementation review of the simplexmq library that found 2 medium and 2 low severity issues (all high-difficulty to exploit), and a July 2024 cryptographic design review that found 3 medium and 1 low severity findings plus 3 informational — with a further implementation assessment scheduled for June 2026 (per SimpleX's official Security Policy page).
5. Known limits: no secure multi-device; targeted endpoint surveillance and global timing correlation are out of scope; contacts can retain/screenshot; groups are not post-quantum yet.

Details

1. Architecture — why SimpleX is fundamentally different

Every other messenger, even privacy-focused ones, identifies you with something: Signal uses a phone number, Matrix a username, Session a long-term public key. SimpleX is the first network with no user profile identifiers at all — not even random numbers or keys. Instead it uses temporary, pairwise per-queue identifiers: for each contact you maintain a separate set of unidirectional queues, each with distinct credentials for sender and recipient. For n users there can be up to n·(n-1) queues, which makes building a social graph at the application layer extremely hard.

The transport is SMP (SimpleX Messaging Protocol) running over TLS 1.2/1.3 (restricted to ChaCha20-Poly1305, Ed25519/Ed448, Curve25519/Curve448). SMP relays are dumb pipes: they hold end-to-end-encrypted messages in memory only until delivered — and undelivered messages are auto-deleted after exactly 21 days on preset messaging servers (per SimpleX's official PRIVACY.md: "Undelivered messages are also marked as delivered after the time that is configured in the messaging servers you use (21 days for preset messaging servers)") — store no user accounts, and do not talk to each other. There is no shared application-level address space and no central authority — only shared transport-level addresses (relay hostnames). File transfer uses a separate protocol, XFTP, which chunks and end-to-end-encrypts files (up to 1GB) across file relays; preset XFTP relays hold file chunks for 48 hours, per SimpleX's official XFTP server docs ("it is stored on XFTP relays for a limited time (currently, it is 48 hours) or until deleted by the sender").

A full two-way conversation = two unidirectional queues, typically on different servers chosen by each recipient. Four different servers are used across a typical connection. Connections are established out-of-band, which non-optionally protects the key exchange against man-in-the-middle: you share a one-time invitation link, a contact address, or a QR code through some other channel. Since v6.4 (the "new connection experience," blog 3 Jul 2025), short links carry encrypted link data on the server so the keys and queue address are no longer exposed in the link itself, the first message can be PQ-encrypted, and you see your contact's profile before connecting.

2. Onboarding & setup best practices

Do this (first run):

1. Install only from an authoritative source: App Store, Google Play, the official F-Droid repo, or GitHub releases (builds are reproducible since v6.3 for servers and Linux/desktop; APKs added later — verify checksums signed with PGP key FB44AF81A45BDE327319797C85107E357D4A17FC).
2. Create your first profile. No phone/email is requested. Use a pseudonym for your main profile name if you don't want contacts to see a real name (the network never sees it — profile names are e2e-encrypted — but your contacts do).
3. Set a database passphrase. Settings → Database passphrase & export. By default the DB is encrypted with a random key stored in Keychain (iOS)/Keystore (Android, using the TPM/hardware keystore when available). For higher assurance, set your own passphrase and consider not storing it on the device, so it must be entered on every start (note: this limits background notifications). There is no passphrase recovery — store it in a password manager.
4. During onboarding, tap Configure server operators and enable Flux servers, in addition to SimpleX Chat servers, before accepting the conditions (improves decentralization — see §4).

3. Privacy & Security settings — exact paths

Open Settings: tap your profile avatar (top-left) → choose Settings.

SimpleX Lock (app passcode / biometric). Settings → Privacy & security → toggle SimpleX Lock. Choose lock mode:

• System (device authentication / biometric), or
• Passcode (an app PIN independent of the device PIN). After enabling, the app requires authentication on open/resume after 30 seconds in background.

Self-destruct passcode (duress wipe). Settings → Privacy & security → set SimpleX Lock mode to Passcode → enable lock → Self-destruct passcode becomes available → enable it, enter the main passcode, then set and confirm the self-destruct code. Optionally set the display name of the empty profile created after the wipe. Entering this code under coercion erases the app data.

Protect app screen. Settings → Privacy & security → Protect app screen (on by default). Hides the app in the recent-apps switcher and, on Android, blocks screenshots.

Incognito mode. Settings → enable Incognito. Generates a new random profile name for each new contact/group, so no two contacts share any common profile data — while keeping everything in one profile. Use it when connecting to someone you don't fully trust.

Auto-accept images. Settings → Privacy & security → Auto-accept images is best left OFF for privacy: auto-downloading tells the sender you're online. Low-res previews still show; senders can't tell if you received them.

Send link previews. Privacy & security → Send link previews OFF: leaving it on causes your app to fetch the URL (leaking your IP/online status to that website).

SimpleX Links display. Privacy & security → SimpleX links: choose description (default, safest), full link, or via browser. Keep it at description; "via browser" will flag non-simplex.chat domains in red.

Security code verification (anti-MITM). Open a contact → tap their name → Verify security code → scan their code or compare visually / read aloud over a voice call → mark verified. Do this for security-critical contacts and for direct connections to group members (those invitations passed through another member).

Disappearing messages. Per-conversation: tap contact/group name → Contact preferences (or Group preferences) → enable Disappearing messages and set a timer (1 second to 3 months; both sides must allow). You can also set a custom timer per message by holding the Send button. Note there is no single global timer that auto-applies to all contacts — you enable it per conversation (since v6.4.1 you can set a default delete time for new contacts).

Delete for everyone. Conversation preferences → Delete for everyone (Yes/Always). Caveat: this is not a security guarantee — a contact running a one-line-modified client can ignore the deletion request.

4. Network & server configuration

Preset servers, operators, and Flux. Settings → Network & servers. Preset SimpleX Chat mobile relays are smp11/smp12/smp14.simplex.im. Since v6.2 (Dec 2024) the app also ships Flux-operated relays. Do this: enable both SimpleX Chat and Flux operators. When two independent operators are enabled, the app deliberately picks servers of different operators for each connection, so no single company can correlate who-talks-to-whom from its own server metadata. Before v6.2, all four random servers in a connection were operated by SimpleX Chat Ltd alone.

Private message routing (2-hop onion). On by default since v6.0. Each 16KB message packet is sent to a forwarding server (chosen by the sender) that relays it to the destination server (chosen by the recipient). The forwarding server sees your IP but not the destination queue/contents (e2e-encrypted to the destination); the destination server sees the queue but not your IP/session. This is per-packet anonymity, akin to a mixnet, and is distinct from Tor. You can optionally extend private routing to known servers too in Advanced network settings.

Tor via Orbot.

• Android: install Orbot, run it as a SOCKS proxy on port 9050, then Network & servers → enable Use SOCKS proxy.
• iOS: iOS has no SOCKS support; run Orbot as a VPN provider and enable the VPN.
• Use .onion hosts: set to when available (default with SOCKS on) or required to refuse any non-onion connection. On iOS, "required" lets you enable "Disable Orbot for non-onion traffic" in Orbot. Caveat: iOS VPN can leak some traffic if the VPN app crashes.

Transport isolation (BETA). Enable Developer tools first (Settings → Developer tools → Show developer options), then Network & servers → Transport isolation. Default isolates traffic by profile; the per-connection mode uses a separate TCP connection (and Tor circuit) for each contact, frustrating correlation by transport session.

File-download IP protection. When SOCKS/Tor is off, the app asks for confirmation before downloading files from unknown XFTP servers, to protect your IP.

5. Operational security (OPSEC) practices

• One profile per context. Use separate chat profiles (Settings → Your chat profiles) to wall off identities, or Incognito mode for per-contact random names.
• Hidden profiles. Settings → Your chat profiles → long-press a profile → Hide. A hidden profile is invisible and silent until you enter its passcode in the search field. Caveat: hidden profiles remain in the local database — anyone with the database passphrase or chat console access can access them and reset their passwords. They protect against shoulder-surfing/casual inspection, not forensic extraction.
• One-time invitation links vs. contact addresses. Use a one-time invitation link for each individual you connect with (single-use, most private; becomes inaccessible if intercepted in transit — alerting you to compromise). Use a long-term contact address only when you must publish a reusable connection point (e.g., on social media); you can delete/rotate it at any time without losing existing connections, and it can be spammed with requests.
• Verify security codes for anyone whose communication is sensitive.
• Group privacy. SimpleX groups are decentralized "secret groups" with no server-side membership list, but every member sees every other member's profile, and any member's modified client can leak content. There's no built-in global group discovery. v6.3/v6.4 added a "knocking" member feature (review before joining), a captcha for public groups, a Moderator role, and private member reports.
• Avoid metadata leakage: keep auto-accept images and link previews off; use Tor for IP protection; rotate the receiving address ("Change receiving address" in contact info) to move a conversation to a new server/queue.

6. Threat model, audits, and known limitations

Audits. Trail of Bits performed an implementation security assessment of the simplexmq cryptography/networking library in November 2022, finding 2 medium and 2 low severity issues (all high-difficulty to exploit; this included an X3DH key-derivation mistake fixed in v4.2), and a cryptographic protocol design review in July 2024, which found 3 medium and 1 low severity findings plus 3 informational. A further, larger implementation assessment is scheduled for June 2026, per SimpleX's official Security Policy page.

Post-quantum status. SimpleX added a hybrid post-quantum scheme to the Signal double-ratchet using Streamlined NTRU Prime (sntrup761) combined with X25519 (v5.6 beta, Mar 2024). It is on by default for all direct chats since v5.7. Groups do NOT yet have PQ encryption (planned for small groups). This is "hybrid" — PQ is layered on top of, not replacing, classical crypto, per cryptographer guidance, to defend against "record now, decrypt later."

What the double ratchet provides: forward secrecy and post-compromise (break-in) recovery, plus repudiation/deniability (no signatures in the client-client protocol).

What SimpleX protects against (from the official threat model in overview-tjr.md). Note the threat model carries the global assumptions that your client uses 2-hop onion routing, your local database/keys and app are uncompromised, and the crypto primitives aren't broken. Under those:

• A passive adversary monitoring one user can identify that and when they use SimpleX and which servers they receive from, but cannot see who sends them messages, who they message, or their contacts' servers.
• A compromised SMP relay cannot learn message contents or type, cannot compromise e2e encryption with an active attack, and cannot undetectably add, drop, duplicate, or corrupt individual messages (so long as a subsequent message is delivered).
• A forwarding (proxy) server cannot learn the destination queues, message contents, or which messages trigger notifications, and cannot perform queue correlation without extra info from the destination server.
• A contact cannot cryptographically prove to a third party that a message came from you, and cannot collude with another of your contacts to prove they're talking to the same person.

What it does NOT protect against — be explicit with readers:

• A recipient's relay can learn that recipient's IP (if Tor isn't used), when a queue recipient is online, and roughly how many messages flow through a queue; it can correlate multiple queues to one user via reused transport connections, IP addresses, or timing.
• Targeted attacks on known users: per the whitepaper, "the protocol does not protect against attacks targeted at particular users with known identities — e.g., if the attacker wants to prove that two known users are communicating, they can achieve it by observing their local traffic."
• A passive adversary monitoring both senders and recipients can perform traffic-correlation/timing attacks, correlating senders and recipients within the monitored set (frustrated, not prevented, by the number of users on the servers).
• An attacker who obtains your decrypted database can read all message history, and can surreptitiously receive new messages until queues rotate or the ratchet advances — but cannot impersonate a sender to you without also compromising the server or device.
• Out of scope entirely (per the Security Policy): CPU/hardware flaws, physical observation side channels (power consumption, EM emissions), and any on-device data accessible with user/root privileges (files, the encrypted DB, and the DB key if stored on device) — i.e., endpoint compromise (malware like Pegasus reads messages before encryption).
• A contact can retain or screenshot your messages forever, and "Delete for everyone" is not enforceable.
• No secure multi-device sync: using the same database on two devices simultaneously breaks the ratchet; the only secure options are linking a mobile profile to desktop over the local network (XRCP protocol) or small groups.

Comparison to Signal. Signal has a far larger user base, audited Signal Protocol, sealed sender, and easy multi-device, but ties identity to a phone number and a central US server, exposing more metadata (who/when). SimpleX trades adoption and convenience for radically better metadata privacy and decentralization.

7. Current state (2025–2026)

• Stable line: v6.4.x through late 2025 (v6.4.1 Jul 2025 added profile bios/welcome messages, member review/knocking, Moderator role, default delete-time for new contacts; later 6.4.x added markdown hyperlinks and tracking-parameter removal). v6.5.x (2026) introduced public Channels (one-to-many publishing with multiple relays per channel, owner-held keys, participation privacy), easier invites, opt-in link previews, anti-phishing/link-tracking removal.
• Governance & funding: a non-profit SimpleX Network Consortium/Foundation is being established in 2026 to steward the protocols. The project raised a $1.3M pre-seed round led by Jack Dorsey with Asymmetric Capital Partners, announced Aug 14, 2024 (the SimpleX blog notes it came "without control or board seat provisions"). On Nov 26, 2025, Vitalik Buterin donated 128 ETH (~$760,000) each to SimpleX Chat and Session, posting: "Session app and SimpleX Chat are two messaging apps pushing these directions forward… I've donated 128 ETH to each" (reported by Cointelegraph).
• Platform differences: Android supports background operation and SOCKS proxy natively; iOS requires Orbot-as-VPN for Tor and a notification server that can observe some metadata (a privacy/convenience compromise). Desktop (Windows/macOS/Linux) links to a mobile profile over the local network and requires an open firewall port; desktop calls run through browser WebRTC.
• Recommendation on servers: enable multiple operators (SimpleX Chat + Flux), or self-host (§8). Decentralization is opt-in and requires deliberate configuration.

8. Self-hosting your own SMP and XFTP servers

Why. Running your own relays gives you control of the infrastructure your messages transit and lets you keep contacts even if a preset server disappears. Trade-off: a server with few users leaks more to a passive observer (less crowd to hide in), so self-hosting is best combined with Tor and/or keeping preset operators enabled for the crowd effect.

Requirements. A VPS (any Linux), a domain pointed at it (e.g., smp.example.com), basic Linux skills, and Docker. SMP listens on 5223 (and 443); XFTP on 443.

Do this (Docker quick path):

1. Initialize the server offline to protect the CA private key (deploy locally in Docker, then move ca.key to safe offline storage and delete it from the server).
2. Run the SMP container: docker run -d -e "ADDR=your_domain" -p 5223:5223 -v $HOME/simplex/smp/config:/etc/opt/simplex:z -v $HOME/simplex/smp/logs:/var/opt/simplex:z simplexchat/smp-server:latest
3. Run the XFTP container similarly with simplexchat/xftp-server:latest (ports/volumes per the official XFTP guide, including a /srv/xftp files volume).
4. Optionally add a Tor hidden service so your relay is reachable as an .onion; preset servers will forward to onion-only relays via private routing.
5. Note the server address (starts smp://fingerprint@domain) from the logs.

Point the app at it. Network & servers → SMP servers → add your server address and test the connection. Changing servers only affects new contacts; move existing ones with "Change receiving address" in contact info. Operators should rotate the online certificate (~every 3 months) using the offline CA key. Server software is AGPLv3 — if you modify it you must publish source to your users.

Recommendations

Baseline (every user), in order:

1. Set a database passphrase (store it in a password manager; decide whether to keep it off-device).
2. Enable SimpleX Lock (Passcode mode) and add a self-destruct passcode if you face device-seizure risk.
3. Keep the Protect app screen on; turn auto-accept images and link previews off.
4. Enable both SimpleX Chat and Flux operators.
5. Verify security codes with important contacts.

Elevated (activists, journalists, sources): 6. Route through Tor (Orbot SOCKS on Android / VPN on iOS); set .onion hosts to "required." 7. Use Incognito mode or per-context profiles; use hidden profiles for compartmentalization (understanding their forensic limits). 8. Use one-time invitation links exclusively; never publish a long-term address. 9. Enable per-connection transport isolation. 10. Set disappearing messages with short timers.

Maximal (high-risk targets): 11. Self-host SMP + XFTP relays on a VPS in a friendly jurisdiction, reachable over Tor, while keeping preset operators enabled for crowd cover. 12. Treat the endpoint as the weak link: use a hardened OS (e.g., GrapheneOS), assume screenshots/retention by contacts, and remember timing-correlation and endpoint malware are out of SimpleX's scope.

Thresholds that change the advice: If your contacts won't migrate, SimpleX can't be your primary app — pair it with Signal. If you need reliable multi-device or large-group PQ encryption, those aren't ready yet. If the June 2026 implementation audit surfaces serious findings, re-evaluate and update promptly.

Caveats

• SimpleX evolves quickly; settings, labels, and defaults shift between versions. Paths here reflect the v6.3–v6.5 (2025–2026) UI; re-check after major updates.
• Several cited third-party comparison sites describe SimpleX as "blockchain-based" or "P2P with onion routing like Tor" — these are inaccurate; SimpleX is a client-server network with disposable relays and 2-hop private routing, not a blockchain or DHT-based P2P system. Rely on official docs for architecture claims.
• Battery use of instant notifications is high; Android requires disabling battery optimization (and vendor-specific autostart on Xiaomi/MIUI).
• "100% private by design" is the project's marketing; the threat model is more nuanced — targeted endpoint and global timing attacks remain real.