Matrix vs XMPP vs IRC: An Honest Technical Comparison

January 20, 2025 — by Marco Pellegrini

There are approximately 47,000 blog posts comparing Matrix, XMPP, and IRC. Most of them are written by someone who uses one of the three and wants to prove the other two are inferior. This is not one of those posts. All three protocols are open, federated, and have legitimate use cases. All three have significant weaknesses. The right choice depends on your requirements, not on protocol tribalism.

Ground Rules for This Comparison

Some clarifications before we start:

I'm comparing the protocols and their reference implementations, not every possible client or server.
"IRC" means the modern IRC ecosystem: IRCv3 extensions, services packages, TLS everywhere. Not 1993 RFC 1459 bare-metal.
"XMPP" means current XMPP with relevant XEPs (extensions). Not base Jabber from 1999.
"Matrix" means the Matrix specification as implemented by Synapse/Dendrite and Element/clients.
I have run servers for all three. I have opinions. I will label them as such.

Architecture: Trees, Graphs, and DAGs

IRC uses a spanning tree topology. Servers link in a tree with no loops. Messages flow through the tree. No message history is stored on the server (by default — some implementations add optional logging). State is ephemeral. If a server restarts, its users reconnect and rejoin channels. Simple, fast, fragile.

XMPP uses a federated model. Each server (domain) is independent. Servers communicate directly with each other using server-to-server (S2S) connections. There is no shared network topology — if user@a.com messages user@b.com, the a.com server connects directly to b.com. Message delivery is point-to-point. Multi-user chat (MUC) uses a single server as the room host.

Matrix uses a federated DAG (Directed Acyclic Graph) for message ordering. Every message is a node in a graph, with edges pointing to the messages it follows. All participating servers (homeservers) in a room maintain a full copy of the room's history. There is no single room host — the room state is distributed across all participating homeservers.

IRC:    Tree topology. Messages flow through tree. No persistence.
XMPP:   Direct S2S federation. MUC hosted on one server. Optional MAM for history.
Matrix:  DAG replication. All servers in a room have full history. Always persistent.

The architectural differences have cascading consequences. IRC's lack of persistence means it uses minimal resources but provides no message history. Matrix's full replication means excellent resilience but significant storage and bandwidth requirements. XMPP's MUC hosting model means room reliability depends on one server, but resource usage is modest.

Resource Usage: The Elephant in the Room

This is where the comparison gets uncomfortable for Matrix advocates.

An IRC server (UnrealIRCd or InspIRCd) handling 5,000 simultaneous users uses approximately 200-400 MB of RAM and negligible disk space. There is no message storage. CPU usage spikes during netsplit recovery bursts but is otherwise minimal.

An XMPP server (Prosody or ejabberd) handling 5,000 users with message archive management (MAM) uses approximately 500 MB - 1 GB of RAM. Message history is stored in a database (typically PostgreSQL or SQLite). Disk usage grows with message volume but remains manageable — a few gigabytes for a busy server over a year.

A Matrix homeserver (Synapse) handling 5,000 users is a different story. Synapse is notoriously resource-hungry. RAM usage of 2-8 GB is typical. The PostgreSQL database grows rapidly — joining a few large public rooms can consume tens of gigabytes of disk space because Matrix replicates the full history of every room to every participating server. A homeserver that participates in the #matrix:matrix.org room is storing every message ever sent there.

Dendrite, Matrix's second-generation server implementation in Go, improves on Synapse's resource usage significantly but is still heavier than IRC or XMPP servers doing comparable work.

Tip: If you're evaluating Matrix for a small community, test with Dendrite rather than Synapse. The resource difference is substantial. If you need to join many large public rooms, be prepared for significant disk usage regardless of implementation.

Feature Comparison

A factual comparison of protocol-level features:

Message history: IRC — none by default (bouncer or server-side logging optional). XMPP — MAM (XEP-0313) provides server-side history. Matrix — always persistent, replicated to all homeservers.
End-to-end encryption: IRC — not protocol-level (OTR or OMEMO via plugins). XMPP — OMEMO (XEP-0384), well-established. Matrix — Megolm/Olm, built into the protocol.
File transfer: IRC — DCC (direct, no NAT traversal). XMPP — HTTP upload (XEP-0363). Matrix — built-in media repository with thumbnailing.
Voice/video: IRC — none. XMPP — Jingle (XEP-0166), uses WebRTC. Matrix — built-in VoIP via WebRTC.
Typing indicators: IRC — none. XMPP — XEP-0085. Matrix — built-in.
Read receipts: IRC — none. XMPP — XEP-0184. Matrix — built-in.
Reactions: IRC — none. XMPP — XEP-0444 (newer). Matrix — built-in.

The pattern is clear. Matrix was designed as a full-featured modern messaging protocol. XMPP achieves similar features through extensions (XEPs), with varying levels of client support. IRC intentionally stays minimal — it's a text relay protocol and doesn't pretend to be anything else.

Federation: Theory and Practice

All three protocols support federation — independent servers communicating with each other. But the quality of federation varies enormously.

IRC federation is within a single network. Servers in one network link together. There is no cross-network federation. If you're on Libera.Chat, you can't message someone on OFTC without connecting to both networks. IRC "federation" is really just multi-server clustering.

XMPP federation is true inter-domain federation. user@a.com can message user@b.com with zero coordination between the server operators. It works like email — anyone can run a server and federate automatically. In practice, federation works well for 1:1 messaging. Multi-user chat federation has historically been weaker, with MUCs being hosted on a single server.

Matrix federation is also true inter-domain federation. A room can span dozens of homeservers, with each server maintaining a full copy. This provides excellent resilience — a room survives even if several participating servers go offline. The downside is that joining a large federated room triggers a massive state download, and rooms with many homeservers have higher latency for message delivery due to replication overhead.

Client Ecosystem

IRC has the most mature client ecosystem — decades of development across every platform. WeeChat, Irssi, HexChat, Konversation, Revolution IRC, Goguma. The downside: most IRC clients have a learning curve. The upside: they're incredibly customizable and resource-efficient.

XMPP's client situation has improved but remains fragmented. Conversations (Android), Monal (iOS), Dino (Linux), and Gajim (cross-platform) are the current front-runners. Client quality varies significantly, and feature support for specific XEPs is inconsistent. The "XMPP client lottery" — where your experience depends heavily on which client you choose — is a real problem.

Matrix has fewer clients but more polished ones. Element (web, desktop, mobile) is the flagship and covers most use cases. FluffyChat, SchildiChat, and Nheko are alternatives. The focus on Element as the "default" client has pros (consistent experience) and cons (monoculture risk).

Which Protocol for Which Use Case

Choose IRC if: You need lightweight, real-time text communication. Your community is technical. You don't need message history, file sharing, or multimedia. You want minimal server resources. You're an open-source project with a culture of IRC usage.

Choose XMPP if: You need 1:1 messaging with good E2E encryption (OMEMO). You want true federation without replicating room history everywhere. You need voice/video calls. Your users will install a dedicated client. You want a protocol that's been battle-tested for 20+ years.

Choose Matrix if: You need a "Discord/Slack replacement" with modern features. Message history and persistence are important. You want built-in E2E encryption for group chats. You need bridges to other platforms (IRC, Slack, Discord). You have the server resources to run a homeserver.

There's an uncomfortable truth buried in these recommendations: for most non-technical communities in 2025, the answer is probably "just use Discord/Signal/WhatsApp." Open protocols win on philosophy. Proprietary platforms win on UX. The gap is closing, but it's still there. Anyone who tells you otherwise is selling something — possibly a Matrix homeserver hosting plan.

FAQ

Can I bridge IRC, XMPP, and Matrix together?

Yes. Matrix has official bridges for both IRC and XMPP. Biboumi bridges XMPP to IRC. Matterbridge connects multiple protocols. Bridge quality varies — Matrix-IRC bridges (like Heisenbridge or the matrix.org bridge) are the most mature. Bridging adds latency and can lose formatting or features that don't translate between protocols.

Which protocol uses the least server resources?

IRC, by a wide margin. A server handling thousands of users needs a few hundred megabytes of RAM and virtually no disk. XMPP is middle-ground. Matrix (especially Synapse) is the most resource-intensive due to full room history replication and database requirements.

Is IRC dying?

IRC's user count has declined significantly from its peak. But "dying" implies a trajectory toward zero, which doesn't match reality. IRC has stabilized around a core of technical communities, open-source projects, and long-time users. It fills a specific niche — lightweight, real-time text chat — and nothing else fills that niche as well.