Comparison XMPP/Matrix

- Reading time: 14 Minuten -


XMPP or Matrix” - Which is better? This question cannot be answered in this way, as each of the two free and vendor-independent systems has its advantages and disadvantages. The systems are not better or worse, but different in design and therefore not perfect for every use case. The sometimes used formulation “Matrix vs XMPP” is counterproductive for both sides, because it is not about “against each other” but about “with each other”.

Partly the question which app should be used is answered like this:

  • WhatsApp => Conversations (XMPP; Android) et al.
  • Slack => Element (Matrix)

However, this is only a very rough and subjective recommendation.

Different priorities

Depending on the position from which you look, there are sometimes more or sometimes less differences. Also, private individuals, companies, hosters or political representatives have very individual priorities and can evaluate and weight points very differently …

Private users

From the perspective of private users, WhatsApp is the benchmark - or data protection. It is not about teamwork, the server load and performance is not relevant and how the transmission works in the background is equally irrelevant. The main thing is that the app/program (the client) works.

Feature Chat Standard (XMPP) Matrix
Clients for all operating systems yes yes
Uniform user interface for different operating systems (OS) no yes
clients with text-only user interface (TUI) yes yes (all in beta status) (external)
desktop client without Electron yes yes, FluffyChat (Flutter) *
“semi-anonymity” / display of chat address in public chat rooms (other participants) yes / not displayed, can be activated by room administrator no / addresses are always public; disabling is not possible

*) Other Electron-free desktop clients are not recommended, because they are still in development status (alpha/beta) or are not developed further.

User numbers

Large users

Users such as companies or government agencies have completely different needs than private users. Here, functions for group work as well as the integration of different services are more important, which is why “team messengers” are in demand. Differences between protocols:

Protocol Chat Standard (XMPP) Matrix
failover of chatrooms over multiple servers no yes
encryption of chatrooms activatable and deactivatable activatable
storage location of administration data on 1 server for all participants at a time on all servers of participating participants at a time
storage of conversation histories for a configurable retention time and/or until pickup by the user on the server where the chat room is set up / after pickup on the server of the users on all servers of the involved participants
data storage on server for distribution of messages to multiple devices can be deactivated yes, can be deactivated by room administrator; individually by user also for each chat room and contact no, cannot be deactivated

Hoster/server operator

Protocol Chat Standard (XMPP) Matrix
concept base can be supplemented by individual extensions (XEP) monolithic protocol (all in one)
language XML (external) Extensible Markup Language JSON (external) JavaScript Object Notation
focus on flexibility and extensibility chat/chatroom resilience
Resource consumption (CPU, RAM, disk space) lower than Matrix higher than Jabber(XMPP)
location of data storage
(concerns reliability but also privacy)
only on the server where the chatroom is set up on every server of all participating participants
bridges to other systems (much via web API) yes yes
Direct reception if TCP connection is open (both sides can send data without request), otherwise info about message via push message Always push message about new message to client, which then fetches the message from the server (the regular, active polling must be operated, since the protocol HTTP is stateless)
Advantage “Greener” use of IT (less resource consumption) In case of server failure/maintenance, participants can continue writing from other servers without interruption.

Note on “Push”:
Apps from the F-Droid store do not use Google FCM. Therefore there is no “push” here and you have to keep the app in the foreground, which again requires more power and is then again comparable to Matrix apps for Android. More suitable for device control (internet of things / IOT).

Note on “pull”:
By frequently asking for new messages, the power consumption tends to be higher - unless you increase the polling interval accordingly (e.g. to several seconds), which then may no longer correspond to an “instant message”. Less suitable for device control (internet of things / IOT).


  • for users in practice irrelevant
  • relevant for ecologists and theorists (“more computing power and more storage <-> green IT”)
  • important for economists and decision makers: the costs per user/end device to be expected in consequence
  • for server operators (third party/own hosting) very important in terms of hardware for resource requirements and fault tolerance

Both systems can be scaled server-side for large installations:

Scaling XMPP

The server [ejabberd] is known for its scalability and can be clustered across multiple instances. (Wikipedia (external))

Best-known example / island system: WhatsApp

Scaling Matrix

Best known example / island system: Tchap (French government)

Resource requirements

There is a lot of talk about memory requirements, but real-world numbers (which sometimes differ from theoretical values) are few and far between. Here is some collected information first from practice:

  • (external): Matrix 141 GB uso de db 4.6 GB RAM Con 21 usuarixis en linea / XMPP 6 GB uso de db 371 MB RAM con 475 usuarixs en linea
  • (external): Matrix-Synapse (PostgreSQL): 5 GB for 1 user / XMPP (PostgreSQL): 0.4 GB for 200 user
  • (external): Matrix-Server at approx. 100 users = 8 GB RAM
  • - improved CPU performance (external): A big week for performance

… and to the theoretically possible:

  • (external): 2,000,000 devices on one XMPP instance.
  • (extern): XMPP-Server-Test “… And so it went, until we reached fifteen nodes, at over 1.2 million users and 22 thousand messages per second, no limit was in sight. …”
  • ejabberd(extern): 1.500 user (XMPP) = 90 MB
  • Numbers for Matrix still missing here.

Other practical values:

Note: Sources with further actual numbers and gladly corrections are welcome >> Contact <<


XML stands for “Extensible Markup Language”, while JSON stands for “JavaScript Object Notation”.

JSON and XML are both suitable for web services -> there is no real better or worse for the application purpose “chat”.

The main differences are (for information):

  • JSON is an extension of JavaScript, while XML is an extension of SGML
  • JSON is data-oriented, XML is document-oriented
  • JSON does not contain start and end tags, while XML has start and end tags
  • JSON supports data types and arrays, while XML does not support explicit data types and arrays
  • JSON does not support namespaces, while XML supports namespaces
  • JSON is less suitable for configuration files because there is no direct comment syntax

Other comparisons:


One difference is the endorsement of the protocol by an international and independent standards body. In the case of the Internet and the protocols for it, the IETF is responsible here in connection with the XMPP Standard Foundation (XSF). This is to achieve a certain quality of a standard and to ensure independence. Both protocols are open source. That means they are completely visible and verifiable:

Protocol Chat Standard (XMPP) Matrix
IETF standard yes no
public protocol yes yes

How is the independence of the protocol now ensured in practice resp. what are the regulations concerning the acting persons/bodies that can determine and decide about the specifications (the “protocol”)?

Protocol Chat Standard (XMPP) Matrix
Appointment of leadership personnel (Formal process) The board of directors (“board”) and the technical working group (“council”) freely elected by the members
Control and trust: Control lies with the members, who elect the board and technical council annually. There should be “neutrality between Foundation and New Vector Ltd.” “The community should trust them.”
Duty to provide information: Actuaries must name their employers/interests ?
Other: The personal share of an application or consideration in the management body is regulated and limited Personal union of 2 executives in specification body ( and service company (New Vector Inc.)
Regulations/Sources: Bylaws (external) Official Articles” (external; PDF) and Rules (external; PDF)
at „Legal Details“

Explanation of XMPP rules

Sources: General Description of XSF (external) and Rules (“Bylaws”) (external) of XSF

For the members (Members) applies, #2.1:

An applicant for membership may not be admitted if, at the time of application or consideration, fifteen percent (15%) of the Members of the Corporation are employed by or represent the same corporation or organization as that corporation or organization which employs the applicant or is represented by the applicant.

Therefore, “Relevant affiliations” must be specified for membership applications!

Loss of control to third parties

The regulations of the IETF (IETF-RFCs) and the XSF (XSF-Bylaws) should at least clarify that a “takeover” is only possible in a hostile-confrontational way and therefore at least the costs of a conflict are to be expected.

Explanation of rules at Matrix

Sources: Official Articles (external; PDF) and Rules (external; PDF)

In the first document, #17.1 of the “official articles of the Foundation”:

The Guardians shall appoint any individual who is eligible as a Guardian to fill a vacancy or (subject to the maximum number permitted by Article 16.1) as an additional Guardian, subject to any requirements set out in the Rules from time to time, and provided at least 75% of the current Guardians approve the appointment.

For the requirements, reference is made to the second document #3.1.4:

The Founder Guardians shall be joined by additional Guardians (with the Founder Guardians forming a minority of the Board) to ensure there is continuity, but also neutrality, between the Foundation and New Vector Ltd.

And further at #3.1.5 and #3.1.6:

Guardians are typically independent of the commercial Matrix ecosystem and may not even be members of today’s Matrix community, but are deeply aligned with the mission of the project and Guiding Principles. The Guardians are self-appointing […]. However, any Guardian appointed must be respected and trusted by the wider Matrix community to uphold the Guiding Principles and keep the other Guardians honest.

More clarification / questions:
- Why is a distinction made between founding guardians (“Founder guardians”) and normal guardians (“guardians”)?

Loss of control to third parties

  • What if an international corporation like Goolge gets into Matrix like they did with XMPP? Or a big investor who wants to change/expand the protocol for his own purposes?
  • Is there a regulation for such a case or does this make a ‘third party takeover’ possible/facilitated? Do we just have to rely on the Foundation to ensure neutrality?

Other Comparisons

… where unfortunately the question “What is better?” is often asked. But actually I think the question “What is different?” makes more sense, because different requirements can lead to different (other) solutions.

Difference according to Matrix

Matrix itself finds the difference relatively subjective and formulates:

… The whole area of XMPP vs Matrix is quite subjective. Rather than fighting over which open interoperable communication standard works the best, we should just collaborate and bridge everything together. The more federation and interoperability the better.

Source: (external)

… however, different terms like bridges, federation and interoperability are used in one sentence here. Since there is often different understanding about this, a few thoughts are therefore appropriate.

Decision criteria

Jabber(XMPP) and Matrix differ fundamentally in their system architecture. There are also differences in the clients available in each case: On the one hand, there is a large variety with different functions - on the other hand, there is a reference client that offers the same functions for all operating systems.

What is more important for a decision now: system features or client functionality ?

There is no universal answer:
In the long run, it may be better to choose the system that is a better fit for you - regardless of client considerations. In the short term, an all-encompassing client solution may be important. In the case of corporations/organizations, it may also help to consider in which areas (client enhancement/customization or system/protocol enhancement) investments should/could be made.

Cooperation between Matrix and chat standard (XMPP) through functioning [bridges] would be ideal. This would enable a standardized exchange of messages with others - and companies/authorities could still enjoy the advantages of fail-safe chat rooms internally.