| |
“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:
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 …
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.
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 |
| 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).
Both systems can be scaled server-side for large installations:
The server [ejabberd] is known for its scalability and can be clustered across multiple instances. (Wikipedia (external))
Best-known example / island system: WhatsApp
Best known example / island system: Tchap (French government)
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:
… and to the theoretically possible:
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):
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 Matrix.org 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 (Matrix.org) and service company (New Vector Inc.) |
| Regulations/Sources: | Bylaws (external) | Official Articles” (external; PDF) and Rules (external; PDF) at „Legal Details“ |
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!
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.
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”)?
… 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.
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: https://matrix.org/faq/#what-is-the-difference-between-matrix-and-xmpp? (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.
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. |