Introduction

The Matrix protocol and its reference implementation (Element) are often (rightfully) criticized for architectural decisions that inherently lead to high-latency communication, resource inefficiency, and broader concerns about its impact on decentralized messaging ecosystems. Here is a detailed analysis of these issues.

Protocol Design

Matrix is designed as a federated protocol inspired by web technologies like HTTP and JSON, making it verbose and computationally expensive. Its design includes the following problematic aspects:

Reliance on JSON

  • JSON is human-readable but suboptimal for high-performance systems. Parsing and serializing JSON increases processing overhead on both clients and servers compared to binary formats like Protocol Buffers or MessagePack.
  • Messages include metadata and history that can be unnecessarily large, exacerbating the payload size.

Global Room State Management

  • Matrix keeps a complete, consistent state for every room (including all users, devices, and history).
  • This results in significant computational and bandwidth overhead during synchronization (e.g., when a new user joins, their client downloads the entire room state).
  • For large rooms, this creates cascading latency effects as servers attempt to reconcile room states.

Federation Complexity

  • Federated design involves inter-server communication to propagate messages across servers hosting room participants.
  • The protocol uses HTTP-based transactions for federation, which are heavyweight, introduce delay, and can fail when federated servers experience load spikes.
  • The use of eventual consistency means clients often deal with state mismatches, requiring additional synchronization rounds and retries.

Reference Implementation Issues (Element)

Element, the most widely used Matrix client/server implementation, compounds latency and inefficiency issues due to its architecture and development choices:

Resource-Intensive Clients

  • The Element client is built on Electron, a framework that bundles a Chromium-based web browser, leading to high resource usage. This slows message rendering and synchronization, particularly on resource-constrained devices.
  • Frequent polling and redundant HTTP requests (e.g., sync endpoints) further tax system resources.

Inefficient Servers

  • Synapse, the primary server implementation, is written in Python. While Python simplifies development, it lacks the performance characteristics of languages like Go or Rust.
  • High memory consumption and CPU usage during message synchronization and history retrieval are common complaints. Scaling horizontally requires substantial infrastructure, which limits accessibility for smaller deployments.

Ineffective Message Delivery

  • Messages undergo multiple processing stages: queuing on the sender’s home server, syncing with recipients’ home servers, and syncing with clients. This leads to delays, especially in federated setups with servers under load or poor network conditions.

High-Latency Communication

The combination of protocol and implementation issues manifests as high latency in several areas:

Message Delivery Delays

  • In larger rooms or federated environments, the time to reconcile room state across servers (e.g., signing and verifying events) introduces noticeable delays.
  • Retries in case of network interruptions or unresponsive servers further delay message delivery.

Typing Notifications and Read Receipts

  • Updates like typing indicators and read receipts require real-time synchronization across all involved servers. These updates are often delayed, breaking the illusion of immediacy expected in modern chat systems.

Initial Sync Overhead

  • When a user logs in or reconnects, the client downloads the entire room state, including history, participants, and room metadata. This can take significant time in rooms with thousands of participants.

Impact on Decentralized Communication

Matrix’s inefficiency harms the broader landscape of decentralized communication:

Barrier to Entry

  • High resource demands for servers and clients deter smaller operators and developers, leading to centralization around well-funded entities like matrix.org.

Poor User Experience

  • End users perceive high latency and unresponsiveness, which is particularly problematic in group chats or real-time use cases (e.g., gaming, live events).

Ecosystem Fragmentation

  • Competing decentralized protocols, such as XMPP or ActivityPub, often avoid Matrix’s issues but struggle to gain traction because Matrix dominates discussions about federated messaging.

Alternative Protocol Comparisons

Matrix’s high-latency and resource-intensive design contrasts sharply with other decentralized messaging systems:

IRC

  • Since IRC is a federated centralized network and not a decentralized messaging system I will not explain it here, but I have released a comparison of IRC, Matrix and XMPP in a seperate document. IRC is worth to mention here because it makes chat and instant messaging available with a low footprint in resource usage. Even on mobile phones it just works and “always on” works when using a client like Irssi over an encrypted SSH connection running in a Screen or Tmux session.

XMPP

  • XMPP is a mature federated protocol optimized for lightweight communication. Binary encodings (e.g., XMPP over WebSocket) and modularity allow better performance.
  • Room synchronization and federation in XMPP are less burdensome due to more efficient state representation.

Signal Protocol

  • While centralized, the Signal Protocol demonstrates how cryptographic efficiency and compact payloads can deliver near-instantaneous communication.

Delta Chat (Autocrypt-based)

  • Delta Chat leverages email infrastructure to provide decentralized messaging. Though not real-time, it avoids Matrix’s heavy synchronization overhead.

Future Outlook and Mitigations

Addressing these issues would require significant changes to both the protocol and implementation:

  • Protocol Evolution: Transition to more efficient data formats (e.g., CBOR) and reconsidering the global room state model.
  • Implementation Overhaul: Moving server-side implementations to faster, more scalable languages like Rust or Go.
  • Decentralization Focus: Reducing reliance on centralized services like matrix.org and fostering lightweight, modular clients.

Without these changes, Matrix risks being perceived as overly complex and unsuitable for real-time, low-latency communication needs. Matrix’s ambitions to unify decentralized messaging is somehow understandable, but its technical shortcomings make it completely unusable for professional and resource-constrained environments.

Conclusion

Matrix just sucks! It isolates people with modern hardware from people with low budget or people just loving their old and working hardware. People with older hardware will not be able to participate in discussions when using Matrix.

XMPP works everywhere with low footprint in resource usage but is not very comfortable for groupchats.

Better for instant chat and messaging is IRC. I use IRC over an SSH connection to my server where Irssi is running in a Tmux session. This is stable and reliable even with constant network changes. It saves battery life on my mobile phone and has no bloated GUI. For best user experience I am running Termux on my Android device for a real terminal feeling like on my desktop and laptop. If you don’t want to use Termux there are some nice SSH clients available for Android and even for iPhone based devices.

For personal and private realtime communication with family and friends I prefer to use the Signal messenger.

All other written communication is perfectly done using Email. Mailinglists are the perfect way of asynchronous communication when it is about hacking and open-source software development.

Thanks

Special thanks go to Armin for the time he spent researching and gathering information to prepare this document.

Comments