Delta Chat is a decentralized and secure messenger app

Original Article ↗ Hacker News Discussion ↗

Spam, phone numbers, and onboarding

  • Question raised: how does a niche, email-based messenger handle spam as effectively as large platforms?
  • Some argue spam is a low priority until userbase is large; others propose manual approval of new contacts, filters, and rate-limiting.
  • Discussion on phone numbers: some suspect major apps use them to tie accounts to real IDs (especially where SIMs require ID). Others note many SIMs can still be bought without ID.
  • GDPR isn’t seen as requiring collection of phone numbers, but some small businesses end up publishing personal phone numbers for legal “imprint”/contact requirements.
  • Delta Chat can distinguish Delta messages from normal email and let users see only the former.

Security model: PGP, no PFS, downgrade behavior

  • Delta Chat uses email + (Open)PGP/Autocrypt; E2EE is possible but:
    • No perfect forward secrecy; if a long-term private key is compromised, past traffic can be decrypted.
    • It can fall back to plaintext when unencrypted mail is seen from a contact, raising downgrade-attack concerns.
  • Some describe this as “just GPG with better UX” and argue this is below modern secure-messaging baselines (PFS + robust metadata protection).
  • Others think using known crypto and infrastructure is a reasonable tradeoff, especially compared to plain email or non‑E2EE messengers.
  • Forward secrecy is reportedly “under discussion” and DC has experimented with a separate P2P protocol with FS, but this doesn’t yet replace email transport.
  • Project claims multiple independent security audits; several commenters say lack of PFS still makes it unsuitable for high‑risk use.

Metadata, anonymity, and email as a substrate

  • Strong consensus that Delta Chat does not provide anonymity: SMTP/IMAP expose sender/recipient metadata to each party’s provider.
  • Critics say forward secrecy and strong metadata protection are “table stakes” for a secure messenger; by that standard Delta Chat is “not secure.”
  • Defenders argue:
    • Email’s openness and ubiquity matter; users can self-host or choose smaller providers.
    • Compared to mainstream unencrypted email or centralized scanning messengers, encrypting content is still a big improvement.
  • Others counter that in practice email is heavily centralized (Gmail/Outlook/etc.), and subpoenas or provider cooperation make social graph recovery trivial.
  • Newer chatmail servers give random addresses, accept only encrypted mail, and aim to minimize logging, but still can’t hide who talks to whom.

Comparison to Signal, Matrix, Telegram, etc.

  • Many treat Signal as the “gold standard” for average users: PFS, robust E2EE, minimal metadata. Counter‑arguments focus on:
    • Phone number requirement (now partly mitigated by features to hide numbers).
    • Reliance on Intel SGX for private contact discovery, which has known vulnerabilities.
  • Several insist Signal does not have full access to users’ social graph, citing its private contact-discovery design; others remain skeptical.
  • Debate over whether criticizing Signal (e.g., “it has your social graph”) is misinformation that harms adoption of secure tools.
  • Telegram is widely praised for UX but strongly criticized for weak default security and centralization; called a “time bomb.”
  • Matrix is seen as more advanced cryptographically (double ratchet, PFS) and decentralized, but UX and encryption reliability issues are cited (key handling, broken decryptions, complex server blocking).
  • Delta Chat’s niche: no phone number requirement, works on laptops and with ordinary email accounts, federated by construction, but weaker on modern security properties.

Usability, latency, and infrastructure reuse

  • Fans highlight:
    • Reuse of email infra (“war‑proof internet”), ability to self‑host, and no central authority.
    • Webxdc apps enabling games and collaborative tools over Delta Chat.
    • Cross‑platform support, including non‑smartphone scenarios (e.g., children on laptops).
  • Latency tests show ~2 seconds via a self‑hosted mailserver and sub‑second via some public servers; most consider this acceptable for chat.
  • Critics note email headers and status messages create significant per‑message overhead, and using email as a chat transport is a “weird contortion”.

Alternatives and threat models

  • Multiple alternative systems mentioned:
    • 0xchat (Nostr‑based), with questions about audits, DM modes, and metadata on relays.
    • Briar, Ricochet Refresh, Session, Cwtch, SimpleX, Element/Matrix, XMPP+OMEMO.
  • Nostr and SimpleX are discussed as having public or relay‑visible metadata; Cwtch and Tor-based systems offer stronger metadata protection but worse convenience (e.g., no offline delivery).
  • Strong disagreement on “better than nothing”:
    • One camp: insisting on PFS + metadata privacy for everyone is counter‑productive; many will just keep using far worse tools (Gmail, social DMs). DC is an incremental improvement.
    • Other camp: promising “secure messaging” without those properties creates a dangerous false sense of security for activists/dissidents; in some cases “don’t use electronic comms” is better advice than recommending weaker tools.