Comparison XMPP/Matrix

- Reading time: 14 Minuten -

Preface

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.

client features standard chat(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) *
display of chat address in public chat rooms (other participants) not displayed, can be activated by room administrator 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 Standard Chat(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 Standardchat(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).

Server/Performance

  • for users in practice irrellevant.
  • 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.

Matrix server performance can be scaled:

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:

  • Disroot.org (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
  • blog.windfluechter.net (external): Matrix-Synapse (PostgreSQL): 5 GB for 1 user / XMPP (PostgreSQL): 0.4 GB for 200 user
  • mastodon.social (external): Matrix-Server at feneas.org approx. 100 users = 8 GB RAM
  • matrix.org - improved CPU performance (external): A big week for matrix.org performance

… and to the theoretically possible:

  • process-one.net (external): 2,000,000 devices on one XMPP instance.
  • erlang-solutions.com (external): XMPP server over 1,500 users = 1 GB RAM.
  • Numbers for Matrix still missing here.

Other practical values:

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

JSON und XML

XML stands for “Extensible Markup Language”, while JSON stands for “JavaScript Object Notation”. The main differences are:

  • JSON is an extension of JavaScript, while XML is an extension of SGML.
  • The syntax of JSON is simpler than that of XML
  • JSON does not contain start and end tags, while XML has start and end tags.
  • JSON supports data types and arrays, while XML supports no data types and no arrays.
  • XML supports namespaces, while JSON does not.
  • JSON is better suited for web services, while XML is better suited for configuration.
  • JSON data cannot be converted to other formats, while XML data can be converted to other formats such as plain text or JSON.
  • Mapping is easier in JSON than in XML because JSON is data-oriented while XML is document-oriented.

Source: https://www.difference.wiki/xml-vs-json (external)

Other comparisons:

Protocol/Policy

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 Standard Chat(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 Standard Chat(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“

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: 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.

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 standard chat (XMPP) through functioning [bridges](/en/sys_matrix/gedanken/#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.