Running My Own XMPP Server

Original Article ↗ Hacker News Discussion ↗

Self‑hosted XMPP servers are gaining renewed interest as an alternative to centralized messaging platforms like Signal, Telegram, Matrix, and WhatsApp. Commenters compare protocol design, security, resource usage, and federation, noting that XMPP is lightweight and mature but hampered by fragmented extensions and uneven client quality—especially on mobile—while Matrix offers richer features at much higher complexity and cost. A recurring theme is the tension between usability and privacy: people value open standards and control over their infrastructure, yet network effects and polished UX keep most users on proprietary services.

Choosing a Messaging Platform: UX vs Security vs Control

  • Several commenters recount moving from self-hosted Matrix/XMPP to Telegram or Signal because of poor UX, accessibility, or mobile/desktop sync issues.
  • Telegram is praised for UX, stickers, and feature richness, but heavily criticized as “deeply insecure” (home-rolled crypto, E2EE not default, no group E2EE, scams/ads).
  • Signal is seen as more secure but criticized for: phone-number requirement, mobile-first account model, weak desktop integration, and non-federated, single-operator control.
  • Some explicitly want something “like Signal but federated,” others accept centralization for convenience.

Matrix vs XMPP: Complexity and Resource Usage

  • Multiple experiences: Matrix/Synapse is resource-hungry, fragile on upgrades, and dominates VPS resources; some abandon self-hosting Matrix for lighter XMPP.
  • One detailed comparison:
    • XMPP: simple core, many optional XEPs → fragmentation and feature mismatch across clients.
    • Matrix: heavy complexity in the core (DAG event graph, full room history) → good consistency guarantees but expensive to run.
  • Question raised why “we ditched XMPP” for Matrix; responses say big tech abandoned federated XMPP for business reasons, not because it was technically worse.

XMPP Self-Hosting and Tooling

  • Long-term XMPP admins report ejabberd/Prosody “just work” for years with minimal resources.
  • ejabberd seen as more monolithic and admin-friendly (bundled TURN, ACME), Prosody as flexible but needing more protocol knowledge.
  • Snikket is highlighted as a preconfigured Prosody-based stack aimed at “self-hosted WhatsApp/Signal for family,” with invites, bundled TURN/STUN, and branded, tested clients.
  • Bridges like slidge (Signal/WhatsApp/Telegram → XMPP) and jmp.chat (phone ↔ XMPP) are suggested, with explicit warnings that bridging can nullify E2EE.

Client Quality and Mobile Pain Points

  • Matrix: clients often buggy; some report months-long broken image sending in FluffyChat and heavy Synapse; Linux Matrix clients described as poor.
  • XMPP: Android’s Conversations strongly praised; Movim liked for web, GIFs, and AV calls; Dino and Gajim noted as improving.
  • iOS XMPP clients (Monal, Siskin) criticized for UI bugs and especially unreliable notifications, making them unusable as primary phone/SMS replacement for some.

Encryption and Trust

  • OMEMO is described in the article as “Signal-like”; commenters share links criticizing OMEMO’s design and warning that similarities to Signal are overstated.
  • Others argue those critiques are opinionated and partially corrected, but agree that current XMPP+OMEMO ecosystem is not a drop-in “Signal competitor.”
  • Signal’s explicit hostility to federation and third‑party clients is viewed by some as a trust and longevity concern compared to open protocols like XMPP.