Why We Abandoned Matrix (2024)

Original Article ↗ Hacker News Discussion ↗

Matrix metadata, security, and protocol design

  • Original article’s claims about Matrix metadata and “central servers” are strongly disputed by Matrix contributors; some details (like unauthenticated media) are outdated.
  • Matrix admits metadata protection lagged behind E2EE, citing focus on getting decentralized encryption stable and limited funding.
  • New work aims to encrypt more room state (e.g. MSC4362, MLS-based proposals that hide sender IDs), with more improvements planned for 2026.
  • Critics say the underlying protocol is overcomplicated (state DAGs, state groups, custom resolution algorithms) and fundamentally flawed for secure group messaging; Nebuchadnezzar is cited as a key critique.
  • Some argue secure + federated group messaging may be inherently very hard or impossible; others think Matrix is just “doing it on hard mode,” constrained by backward compatibility.

Performance, state resolution, and server operations

  • Many admins report Matrix homeservers as resource-heavy versus XMPP, with large room state and state groups consuming gigabytes.
  • State resolution used to brick rooms; the Hydra project is said to have fixed the worst issues, though skeptics doubt all edge cases are gone.
  • Synapse’s storage inefficiencies are acknowledged; attempts to rewrite in Go (Dendrite) stalled due to funding, leading instead to multi-process and Rust-worker approaches within Synapse.

Client UX, keys, and onboarding

  • Element Web/desktop is widely criticized as slow, memory-hungry, and buggy, with confusing login/auth flows and key management (e.g. cookies/local storage holding encryption keys; users who clear them break sessions).
  • Some users find basic features (custom emoji, statuses, bios, simple invite links) still missing or arriving very late.
  • Others report smooth experiences, especially on newer Element X clients and private/self-hosted setups; they suspect many horror stories come from older clients or overloaded public servers.

Federation vs full decentralization

  • Several commenters reject the article’s “Why Federation Must Die” stance. They view federation as crucial for censorship resistance and resistance to state control, even if it leaks more metadata.
  • Others argue P2P/fully decentralized designs are preferable, though they note real-world tradeoffs: mobile battery use, latency, and the need for relay/edge servers that reintroduce federation-like trust issues.
  • Some reference earlier critiques of federation (e.g. from Signal’s founder) about coordination friction and slow evolution, but see those as tradeoffs rather than fatal flaws.

Alternatives: XMPP, SimpleX, and others

  • XMPP is repeatedly praised: extremely lightweight to host, mature, “just works” for many families and communities, though it lacks some of Matrix’s modern features (cross-signing, rich rooms, video, etc. without extensions).
  • A few wish the ecosystem had doubled down on XMPP instead; they blame “hatred of XML” and shifting investment for its stagnation.
  • SimpleX is the article’s preferred alternative, but commenters enumerate drawbacks:
    • No native multi-device, time-limited undelivered messages, unclear queue durability.
    • Harder onboarding (sharing large links/QR codes out-of-band).
    • Heavy VC funding and unclear incentives for queue operators.
    • Claims of “no identifiers” viewed as misleading because queue IDs still function as identifiers; IPs leak to hosting providers.
    • Plans for blockchain-based “vouchers” are seen by some as “crypto creep,” though the project insists they are non-tradable service credits, not coins.
  • Some mention other P2P tools (Keet, Cwtch, Scuttlebutt), but note issues like closed source, no Tor integration, or immature UX.

Moderation, abuse, and legal risk

  • A major fear is liability for illegal content (especially CSAM) on federated servers: operators can’t easily prevent their caches from being used to distribute abusive media.
  • Examples are given of slow or ineffective moderation on public Matrix and ActivityPub instances, leading some admins to advise defederation or shutting down.
  • Matrix points to newer “policy servers” and a larger trust & safety team as progress, but critics say tooling remains weak for public-internet abuse scenarios.

Divergent experiences and community priorities

  • Some long-time users report Matrix as stable, secure “enough,” featureful, and uniquely positioned (bridges, self-hosting, E2EE, cross-platform) — good enough to replace Slack/Discord for many teams.
  • Others have abandoned Matrix after repeated bugs, lost messages, complex self-hosting, and UX friction, arguing its existence “crowds out” potentially better OSS chat systems.
  • A meta-thread notes a split in the “anti–big tech” world:
    • One camp prioritizes federation/self-hosting and control over infrastructure.
    • Another prioritizes maximal privacy, minimal metadata, and robust E2EE above all.
  • Commenters suggest recognizing these divergent goals makes it easier to understand why some see Matrix as “almost there” and others see it as fundamentally wrong for their threat model.