Thoughts

- Reading time: 38 minutes -

My Opinion/Criticism of “Matrix “

Preface

These thoughts are not about the indeed great functionality of Matrix clients or other advantages - but should rather encourage to deal with different topics and to perceive arguments more consciously and to question them. They reflect my personal impression of the “Matrix-Hype” and my private opinion about it.

However, I do not have an opinion set in stone, but see it as a development process. Therefore here again the explicit request for short information, if someone finds outdated information or errors!_

The Matrix protocol is often seen and sold as the solution at the center of the chat universe, with the help of which interoperability could be achieved. I don’t see it that way..

Matrix is not a savior for interoperability but part of the interoperability problem itself. But Matrix installations can support much needed interoperability if the existing interface to the international standard in chat is actually enabled in practice and can be used.

The experience from many conversations shows that often something is picked up and so (or similar) simply passed on in another context - without questioning the statements before. This creates a false positive impression or misunderstandings.

Above all the following points are the reason for my answer to the often asked question to me, how I stand to Matrix - because: I am ambivalent!

Points of criticism

The press and lobby work in the Matrix environment is enviably good and clever - and maybe that was exactly what made me take a closer look:

… are the points, since I noticed. Whether and how one evaluates these as relevant for oneself is up to everyone.

Neutrality

Matrix.org is very closely associated with the company (companies) New Vector. >> more << On the part of the Matrix.org Foundation, this is also openly pointed out here: https://matrix.org/foundation (external)

The Matrix.org Foundation was founded exactly with the purpose of independence - also from New Vector Ltd - to have an independent authority the specifications of the Matrix protocol. This independence is so great/important that New Vector Inc. is even explicitly mentioned in the official rules of the Foundation:

to ensure there is continuity, but also neutrality, between the Foundation and New Vector Ltd.

Does this mean that New Vector is so influential that it is mentioned in the “Rules” in order not to have any special influence?

In the official Matrix-Foundation-Rules it is stated that the existing persons (i.e. at the beginning the two founders) decide about new appointments - and should pay attention to neutrality - which is not specified in more detail. In comparison, the rules of the IETF(XSF) are very clear regarding neutrality: It is clearly defined that …

the actuators must name their employers/interests,
the share of an employer must not be larger than x and
the council/board is otherwise freely chosen by the members.

The way of neutrality can and should in principle also be a criterion for both commercial and governmental decision makers. Even if these things are currently completely lost in the matrix hype and receive no attention.

Funding/Licensing

Is matrix at risk?

Closely related to neutrality is the call published at the end of 2022 in a blog article at Matrix.org (external) to participate in the expensive development (of what specifically?).

However, after reading the article, it is not entirely clear whether the protocol “Matrix” (there is no crypto-messenger “Matrix”!) itself is endangered, or whether “merely” the software company/service provider “Element” (New Vector) is in financial trouble. There are a lot of things mixed up.

The original blog of matrix.org says (machine translated):

… We have even experienced the opposite: commercial providers falsify the protocol and try to dissolve the core team. Matrix tenders were lost to “preferred” vendors who know absolutely nothing about Matrix. Vendors selling Matrix hosting or services without contributing anything at all to the project. Organizations with huge amounts of money (governments, $$B massive corporations) enthusiastically launched proprietary Matrix solutions by building on the freely licensed Apache reference Matrix implementations - and contributing nothing to the project. …

Oops! Hard words.
First touting a free protocol as Matrix.org - and then complaining to/for Element about their own chosen licensing method?

That there might be no donations and no cooperation with commercial implementations is logical with the chosen licensing. You have to expect it and should not whine or make demands. It seems that the clear request for financial participation tends to be understood as a financial injection for the developer. A clarity for which purposes funds are demanded/used would be nice.

… Element is now literally unable to “maintain the entire Matrix Foundation on behalf of everyone else” …
… nor by indirect support in the form of collaboration with the offshoot Element, through which Matrix is currently being significantly advanced. …

This is to be questioned, because the mixing of Matrix (protocol) and Element (software & services) expressed in the article or this “cross financing” by Element is not unproblematic: Where is the intended independence?

Wasn’t this the reason why the foundation was established, which is supposed to take care of the further development of the Matrix protocol independently?

Large amounts of venture capital have been invested in Matrix.org as well as Element. In this respect it seems that both the 5 million venture capital and further tens of millions of dollars investment from Element (“Element has put tens of millions of dollars into Matrix”) are used up …

Fortunately international standards like IMAP or XMPP are not as dependent on individual backers and venture capital.

Conclusion: No matter if matrix.org or element.im (New Vector): You should not license under Apache and complain afterwards!

Translation

A very important point for me, because German information about Matrix is rare and almost everything is only available in English:

Neither the page of Matrix.org (external)
nor the page of Element (external) is in German language.

An important question is: Are English terms and conditions sufficient in the German-speaking area (D/A/CH) or where are German terms and conditions (=general terms and conditions) of the involved companies/organizations (New Vector Limited, New vector SARL, ELEMENT SOFTWARE INC. and The Matrix.org Foundation) to be found?

There is also very little about licensing on the page of [matrix.org](https://matrix.org/legal/privacy-notice (external) and even less in German:

The Matrix protocol is licensed by the Matrix Foundation which makes it available to third parties who set up their own homeserver.

Privacy

Matrix was not developed with a focus on privacy (probably this is the reason for the many isolated solutions and the non use of the interface to standardized chat. It is also not advertised that users have full control over their communication - instead the advantage according to Matrix is:

There is no single point of control or failure in a Matrix conversation which spans multiple servers: the act of communication with someone elsewhere in Matrix shares ownership of the conversation equally with them.

Source: Privacyhandbuch (extern)

Strangely enough, exactly the point of data protection is listed as an argument to justify closed matrix instances and to not have to have an interface to the outside (=interoperability). From an e-mail at the state level:

…, which is explicitly not desired by us for data protection reasons.

However, when asked to specify the alleged data protection concerns, no information is received from any company or authority, despite specific inquiries. It cannot be substantiated.

Cross-reference: public role model.

The basic concept of Matrix is the replication of chat rooms (also 1:1 chats) to all servers involved in the respective chat. And exactly this not only leads to higher resource consumption (see below), but is also problematic in terms of data protection in public federation. Presumably the order for data processing would have to be extended in each case, which is hardly possible in practice. One solution here is only to use standardized interfaces for communication with other systems that do not require replication of databases.

Data Economy

The generally required data economy is difficult to achieve with regard to unnecessarily stored usernames and profile pictures in view of partly giant chat rooms.

Identity-server

Actually, Matrix co-founder Matthew Hodgson tells us in conversation, Matrix IDs should no longer be visible to the outside world at all. Instead, users should be able to find new contacts via known characteristics such as their e-mail address. It is already possible to voluntarily link one’s own Matrix ID with an e-mail address. Later, telephone numbers or other known features such as Skype or Facebook names will also be added.

However, merging such sensitive information in a federated network like Matrix is a (data protection) technical challenge. Currently, Matrix stores the information associated with Matrix accounts on a central identity server. “That’s a disaster,” Hodgson says. On a federated network, “you shouldn’t be forced to trust a central ID server.”

Hodgson and his team are on the lookout, he says: “We need to solve this this year.” A hierarchical approach, similar to the way the Domain Name System (DNS) works, is being considered. A quick solution to the problem seems unlikely, however, as the Matrix team is busy with more pressing work: Currently, the identity information of the central server is not even hashed.

Source: golem.de (extern)

Amdocs

The company Amdocs is Matrix’ father/mother: “The original project was created within Amdocs …” (external; Wikipedia)

Im Jahr 2016[20] wurde eine Tochtergesellschaft von Amdocs mit dem Namen “Vector Creations Limited” gegründet, die das Team beschäftigte, das an dem Matrix-Protokoll und der Software arbeitete.[21] Im Juli 2017 wurde bekannt, dass die Finanzierung durch Amdocs gekürzt wurde, was dazu führte, dass das Matrix-Kernteam sein eigenes Unternehmen mit Sitz in Großbritannien gründete, “New Vector Limited”.

Source: https://en.wikipedia.org/wiki/Matrix_(protocol) (external; English - on the German Wikipedia page the connection to Matrix is not apparent and much information is missing there).

Amdocs has more than 26,000 employees and creates mobile phone accounts in about 85 countries and for more than half of the world’s population. That means they know since the 1980s who is in contact with whom, how often, how long and at what time … that is metadata. In this context the hint that Element openly points out that they store and evaluate metadata for profiling the users:

”… we might profile metadata…“](https://element.io/privacy) (external; English ‘privacy policy’).

There were also contacts with Amdocs after 2017. For example, Matthew Hodgeson was a guest of Avishai Sharlin (Division President of Amdocs Technology) in August 2020 and there was a podcast

More info: - Amdocs fact sheet on Amdocs (external; English; PDF)

Collected Comments

Infinite storage < (click here to open the section)

Note: It is so that databases can be cleaned up at least by the respective server administrator.

An opinion about private or partially private IRC rooms.

If the irc channel is intended to be private then I’m sure it’s best not to bridge to matrix. Heads up if you have a semi-private IRC channel with bridged #Matrix users in it. Once the channel logs arrive at the Matrix server hosting the bridge, every Matrix user can join this channel and the Matrix sever will happily provide the complete channel logs without anyone on the IRC side ever noticing. (tested with matrix.org & freenode) This is a HUGE privacy concern and I don’t understand why anyone would consider using Matrix.

I would be interested to know if this is indeed the case >> contact <<.

The communication system “Matrix” with the reference client element is increasingly used or considered by large entities (organizations, administrations, companies) as an alternative to proprietary (closed, in-house) systems. This in itself is nothing special, as the trend is towards open source systems for workgroups, which have undisputed advantages.

Often the fact “Even organization XY uses matrix” is taken as a (blind) recommendation without knowing the background or context. But except matrix(.org) almost all really big instances like …

“BW-Messenger” (German Federal Armed Forces)
“Tchap” (French government/administration)
“TI-Messenger” (gematik) or also
many (not all!) instances in the education sector

… for a purely internal communication and configured in a way that no public federation is allowed. Not to mention real interoperability, because theoretically possible bridges to other systems such as the standard “XMPP” protocol are/will often not be enabled in practice.

Interoperability is thus not possible. And blind trust in such recommendations is not advisable - personal responsibility is required.

Not an Internet standard

The Matrix protocol itself is owned by the Matrix.org-Foundation (external) and is merely an exposed interface description. Matrix is not a protocol tested, legitimized, or standardized by the IETF (external). The Matrix.org foundation licenses the protocol to others:

The Matrix protocol is licensed by the Matrix Foundation which makes it available to third parties who set up their own homeserver.

Source: Matrix.org Homeserver Privacy Notice.

If/when the standardization process will be initiated is currently unknown. However, there is a relatively well working interface to the chat standard “XMPP” in the meantime, which is called a bridge.

A bit strange about this is the following self-assessment from Matrix.org:

„… a final positive: matrix.org/foundation is a pretty solid foundation (hah) in terms of governance structure - protecting the protocol as much as we can from being sabotaged by our future selves (or anyone else).“

Source: https://twitter.com/matrixdotorg/status/1197297411300958208 (external)

Matrix’s criticism of the IETF standardization process for XMPP is not factually justified. There are a couple of IETF RFCs that specify the core of the XMPP protocol (and also already have a complete revision behind them in 2011) - with all the guarantees/securities that entails. Plus, thanks to the modularity of the protocol, the XEPs, which can dynamically evolve the protocol as desired and be supported by the XSF which is not only formally completely independent. Structurally, therefore, the best prerequisites. If available, an Internet standard is preferable to an individual “REST-API”. Furthermore, the matrix interface could also be standardized by the IETF … if one wanted to.

Monolithic protocol

Matrix aims to combine all the functions required for modern chat into one protocol. It is monolithic. Technically, Matrix does not use modularity (i.e., the ‘X’ in XMPP). This is to avoid fragmentation. Own quote on this from 2018:

The problem is that ‘necessary functions’ today do not have to correspond to those of the future - development continues. Future use cases need other features and no one knows what instant messaging will look like in 5 years. The protocol lacks the mechanisms to be able to adapt it accordingly. So at some point it will be updated and as a result old servers will have difficulties or not work at all. This is to avoid fragmentation. This is controversial (“illusory”). On the contrary - it will be so much harder to get fragmentation under control. The problem is that ‘necessary functions’ today need not correspond to those of the future; development continues. Future use cases need other features and no one knows what instant messaging will look like in 5 years.The protocol lacks the mechanisms to adapt accordingly. So at some point it will be updated and as a result it will struggle with old servers or not work at all.

The approach to do without modularity in order to avoid fragmentation worked wonderfully at the beginning. However, as of today (2022), a certain fragmentation can already be seen:

There are matrix servers with the most diverse versions (external) as well as the most diverse clients in use.
Also an example of this are the ever-changing specifications for rooms, for which there are currently 9 different versions (external) as room specifications evolve (as expected).

The supposed advantage over the chat standard XMPP of yesteryear has vanished into thin air.

Flexibility of the protocol.

For modern IM requirements, the Matrix protocol is suitable (it would be bad if it wasn’t) - but for other things like the Internet of Things (IoT) or new developments, not really. So separate solutions are needed for that, which is a pity.

Federation & Interoperability

With the Matrix protocol, different Matrix servers can federate with each other, which is a big advantage over other open source team messengers. Hence my recommendation in the system comparison.

Due to the federation of Matrix servers, fail-safety is achieved for chat rooms. When Matrix talks about federation, this can mean different things:

In an internal federation, there are several servers within the organization that are connected but cannot communicate to/from the outside.
In a public federation, communication is also possible with (from/to) other matrix providers.

So it is always important to question whether an actual communication with any matrix instances (federation) is possible or not!.

Because it is to be noted that in advertising promises federation (which one?) is referred to again and again and alleged interoperability is promised and diligently advertised. But: Federation is not to be confused with interoperability!

So you have not only one big matrix world, but also many individual matrix islands, which are a great solution in themselves - but just not federate and thus not interoperable. This is like being able to send/receive e-mails only internally!

This constellation would become interesting if compulsory interoperability were made mandatory politically (-> sector inquiry by the German Federal Cartel Office). What then about the public role model aus?

Yes, undisputed - but again: “Matrix is not equal to Matrix” and especially not to be equated a priori with public federation or even interoperability. Closed Matrix instances do not detract from the open federation of other installations - just as there are sometimes extremely large, closed instances of other systems.

Rather, the point here is to raise awareness of whether or not public interoperability can be achieved with Matrix. After all, this is a key issue, especially for the question of its use by public institutions and in citizen communication.

Does the Matrix bridge to standardized chat (“Bifröst”) contribute to interoperability with messengers or not?

Theoretically, yes, because this allows messages to be exchanged across the board.
In practice, however, a great many matrix instances are configured for purely internal communication and in such a way that no public federation is allowed. Not to mention true interoperability. Theoretically possible bridges to other systems, such as in particular the standard “XMPP” protocol, are/are often not enabled in practice. Out of fears that cannot be factually and concretely justified?

Internal matrix federation, however, does not bring about the interoperability of messenger systems called for in policy and also does not help to achieve this goal.

If, for example, France would also offer non-government employees to communicate with them (i.e. with users of other Matrix servers=Federation), then the Matrix chat addresses would consequently have to be communicated and published somewhere: On a website, on business cards, in emails, in conversations, …. Since this is not done, it has nothing to do with public interoperability in practice.

Theory (what is technically feasible as well as marketing promises) and practice (actual server settings) thus often diverge.

Free choice of provider

A free choice of provider is possible without any problems on the part of the protocol - but is somewhat restricted in practice, since small providers reach their capacity limits much more quickly due to the increased resource requirements for main memory, CPU and “disk” memory. This makes self-hosting (running your own Matrix server) for private individuals more difficult. Of course, you can also run a private Matrix instance on a Raspberry PI - but there are certain differences …

Resource requirements

An example with concrete numbers (external): It makes a difference whether 140 GB database and 4.5 GB main memory are required for approx. 20 users (Matrix) or only 6 GB database and less than 400 MB main memory (XMPP) for approx. 450 users.

Further examples with concrete figures can be found in System comparison XMPP-Matrix.

The simplest solution for the resource problem, which Matrix is currently trying to improve with “conduit” (beta status) (external), is restriction at the federation. To stay within the existing technical possibilities, some Matrix instances are therefore not operated publicly.

The realtively high hardware requirements do not promote (public) interoperability.

Encryption

Even with Matrix, it’s not like the protocol mandates encryption (that wouldn’t make sense either). Instead, this is a matter for the clients (external):

This guide is intended for authors of Matrix clients who wish to add support for end-to-end encryption.

Nevertheless, it is always claimed that everything is automatically encrypted in Matrix. This is not true.

Another point is the lack of flexibility in the available encryption types. There is only the device-related OLM/MEGOLM - user-related encryption types like PGP are not even possible as an alternative.

Note on “device-related”: Matrix talks about “device keys” (external) - but which are actually client-keys (on one device several clients can work with the same chat account).

User numbers

As with Telegram, user numbers are growing by counting former and sometime users in chat rooms. They should not be confused with users who are currently online. The partly huge user numbers stated for Matrix chat rooms should therefore be taken with a grain of salt and questioned, because …

users of other systems to which is bridged are incorporated and find themselves in the “user statistics” of Matrix (e.g. connected IRC users are seen as part of the Matrix network)
also a Matrix server does not simply forget the former users of a chat, but lets them continue to “exist” in the chat room - although they are no longer online. So all former members (no matter if still current or not) will be listed in the chatrooms - of course also the users mentioned under point 1 (who were online from chatrooms “tapped” by bridges of other systems). That can under the viewpoint of unnecessarily stored user names and profile pictures also a data protection topic (data economy).

So sometimes clearly more users are displayed than actually “available” - and these are then also often interpreted as active Matrix users and “sold” as such in conversations.

“Number of users” is not to be equated with “number of users currently logged in” or even “number of users with an account at Matrix”!

“At Matrix, public chat rooms are many larger!”

People often ask “Aren’t there any chatrooms in System X/Y that are as big as in Matrix?” - Yes, there are - but there, only the users who are currently present in the chat are shown. Nevertheless, some people think that it would be a sign of quality if chat rooms had thousands of members who were authorized to write.

Electron

There is no native Element desktop client for Windows or Linux.

To explain: If an application runs “natively”, it was created directly for the operating system environment (technical term: compiled) and can therefore also be executed and interpreted directly by the operating system. If an application does not run “natively”, it can only be executed in an emulated mode (or within a browser environment).

The reference client element for Desktop is an Electron application and therefore a (in)security factor for some. The application is embedded in its own browser and would also need to be updated with every browser security update. In addition, Electron applications require more memory resources than native programs/apps. However, this is not a specific Matrix phenomenon but is the case with all Electron applications.

External Services

Element.io offers “Element Matrix Services”, the world’s largest hosting platform for Matrix (infrastructure for hosting Matrix instances). This hosting service also uses the external services Cloudflare and “AWS “ (Amazon Server), which have come under criticism from data protectionists. So in the case of matrix.org, AWS servers are used, whose domains are behind Cloudflare. Also, for each file upload (even from other instances, unless the admin has changed the default there), everything goes through element.io, again on AWS and behind Cloudflare.

Critics say: Cloudflare is the plague of the internet. No one needs it, but everyone uses it because they think they need it. (From a comment).

Indeed, one can find a contradiction in terms when a system designed for decentralization like Matrix uses centralized systems in the background that can be abused for surveillance purposes and are not subject to EU law.

We host the Element Matrix Services on Amazon Web Services (AWS), specifically: Our admin server is hosted in an AWS data centre in Amsterdam; Our deployment server is hosted in an AWS data centre in Stockholm; Customer deployments have the option to select the geographical location which is the most convenient for them; We also host the Gitter.im app on AWS, in a datacenter based in the East of the US. Amazon employees may have access to this data. Here’s Amazon’s privacy policy. Amazon controls physical access to their locations.

We use Cloudflare to mitigate the risk of DDoS attacks. Here’s CloudFlare’s privacy policy.

For Cloudflare, see the documentation Integration Manager Privacy Notice (external) at “3.9 Who Else Has Access to My Data?”:

We host the majority of the Service in UpCloud data centres. Here’s UpCloud’s privacy policy. UpCloud controls physical access to their locations. We use Cloudflare to mitigate the risk of DDoS attacks. …

Requests on Github to stop external service usage were handled with the note to prevent DDoS attacks:

„Please don’t use CloudFlare“ (extern)
„Stop using Cloudflare“ (extern)

The Element Matrix Services EMS Server With Custom Domain documentation (external) describes how to use the reference to Cloudflare - the “report-uri”.

Information: https://www.kuketz-blog.de/the-great-cloudwall-weshalb-cloudflare-ein-krebsgeschwuer-ist/ (external)
A lot of information collected: https://mypdns.org/dCF/deCloudflare/-/blob/master/readme/de.md (external)

„VS-NfD“

A supposedly official classification of the matrix protocol as a secure means of communication is also a misunderstanding that keeps cropping up. It is a matter of “classified information - for official use only (VS-NfD)”. The privacy handbook tries to clarify this:

There is a rumor circulating that [matrix] is approved by the BSI for classified communication of the classification VS-NfD in the Bundeswehr due to secure crypto. This is a legend or misleading advertising, i.e. Fake News. The same rules apply to the use of bwmessenger in the Bundeswehr as to unencrypted e-mails.

To infer from this that the protocol itself is designed/approved for “VS NfD” or particularly secure is wrong - even if the train of thought is obvious. If that were so, most (all?) island systems could be classified as “secure”.

On the subject of “VS NfD”, I would appreciate more official information: >> Contakt <<

Sources:
- Privacyhandbuch (external)
- Pressemitteilung der Bundeswehr (external)
- Information des BWI (IT-Dinstleister der Bundeswehr) vom 16.11.2021 (external)

Bridges

Generally speaking:
If two structurally different systems are connected by auxiliary constructs such as bridges, the disadvantages of the involved messengers add up and the unique advantages of each are discarded in the collaborative communication.

Fundamentals

the Matrix-Bifröst bridge has not yet progressed beyond experimental status (external) (“This bridge is in very active development currently and intended mainly for experimentation and evaluation purposes.”) - obviously more potential for value creation is seen in other bridges.
exchange only via matrix
Matrix bridges are only bridges from/to matrix - a direct exchange between other systems is not possible. Consequently, bridges are part of the interoperability problem and not the problem solver (the same is true for bridges (“transports”) that exist in XMPP).

Matrix graphic with matrix as cenral point to provide for overlapping communication (=/= interoperability) - which is also discussed in corresponding press releases (e.g. at t3n.de (external)).
However, the diagram may suggest that communication between systems and across systems can be done without problems and with full functionality (which would be wrong).
Source: t3n.de (external)

Legality and future-proof

Matrix advertises that it has many bridges to closed messenger services such as Discord, Facebook Messenger, Instagram, Signal, Threema, WeChat and also WhatsApp: https://matrix.org/bridges (external).

However, it is not clear whether there are any contracts with the respective owners of central services (e.g. Facebook, Microsoft, Apple or Google - to name the big ones) or not. Because using clients other than your own is not desired. Perhaps it is worthwhile to take a look at the general terms and conditions of the respective providers …!

If bridges to central services are offered as working, this should also be ensured by visible and transparent contracts of the own service provider with the respective target system. Everything else is hot air and not really future-proof.

In the past, at least, all bridges from other systems created to WhatsApp or to Signal, for example, were only tolerated for a certain time. If the usage becomes too intensive and affects business interests too much, chat accounts created for this purpose are quickly blocked/deleted by the provider.

Regarding the use of bridges between different messenger systems there are critical voices like the one of Mike Kuketz (external). Here, however, it probably makes sense not to make a blanket judgment, but to question which type of chat (individual chat, group or public chat rooms) should be connected how (by federation or by bridge) and whether or not data protection issues/problems actually arise in these different cases.

Data integrity

Since March 2022 the Matrix Bridge (Bifröst) changes content and translates XMPP URIs (addresses). For me an absolute “no-go”, because what arrives at the recipient is not what the sender of the message actually wrote. Contents of messages are displayed changed on matrix page and as a consequence also quotes are falsified. I don’t like this - even if it may seem “convenient” for Matrix users.

Quite apart from the fact that messages from a bridge should not be changed in content: Why is the change of links in messages exclusively in the direction of the matrix syntax and in the other direction no matrix address is “translated” - why?

Here, tasks that a client should take over (optional customization in content display) are taken over by the bridge. Links deliberately include the protocol to be taken into account, which can have many reasons - among others security. The context of messages can otherwise be totally distorted in terms of content.
Examples:

“The addresses xmpp-address and matrix-address concern different systems!” becomes:
“The addresses matrix-address and matrix-address concern different systems!”
“Who administrates the chatroom xmpp-chatroom?” becomes:
“Who administrates the chatroom matrix-chatroom?”
Examples:
- The invitation at Matrix side #matrixistsuper:matrix.org is not changed by the bridge towards XMPP (as is correct). But …
- The invitation xmpp:testchatraum@conference.irgendeinserver.tls?join will be changed in Matrix to: https://matrix.to/#/#_bifrost_testchatraum_conference.irgendeinserver.tls:aria-net.org

A developer of the Bifröst bridge aptly notes that this is merely my opinion:

I assume this is your opinion as opposed to others who may actually be using XMPP and developing for it, e.g. https://github.com/matrix-org/matrix-bifrost/issues/308 (external)

… and fully stands by this “functionality”: “And I fully agree with that, hence the change.”

Practical shortcomings

Especially when connecting and bridging public chat rooms, misunderstandings and problems due to “messages not displayed in the other chat room” occur again and again. The reason for this is the lack of synchronization of permissions. So neither the roles of the participants (owners, moderators, members, participants) nor blocked and thus actually locked out chat addresses are not bridged automatically. This is bad.

Also it is not obvious that one is quasi “as a guest” in the other system. Thus there is constantly danger of confusion, which is common with “here/there in the chatroom”.

Unclear positioning

On the one hand, bridges between the protocols Matrix and XMPP are advertised - on the other hand, XMPP is not listed at all at the Matrix bridges (external) or not mentioned with a word. At least not on this important page.

To find “XMPP” you have to look under “libpurple”, where again “matrix-bifrost” is referenced and the note “General purpose puppeting bridges using libpurple and other backends. This bridge is in very active development currently and intended mainly for experimentation and evaluation purposes.” is given. Only on the linked Github page you can find “XMPP”.

So bridges to XMPP are sometimes advertised - but interoperability based on international protocols is not actively pursued. This supposed contradiction probably results from the business model.

It is also generally not so easy to understand why different bridges are advertised or in use - or not:

At Matrix.org (external) a bridge (despite experimental status) to standardized chat is operated - as of April 2022 listed: IRC (6x), Slack, Grid and XMPP
In the information about the available bridges, however, one finds on Matrix.org (external) no word about the standard XMPP, no logo and no hint. (Solution: The bridge hides behind “libpurple” under „matrix bifrost“!)
Sources:
https://element.io/element-matrix-store#bridges (external) or
https://element.io/enterprise/matrix-bridging-services (external) or
https://element.io/matrix-services/hosted-bridges (external)

In contrast, if the hosting service of element.io (external) is used as the world’s largest matrix hoster, the following 8 different bridges are listed as of April 2022: WhatsApp, Slack, MS Teams, Signal, Gitter, Discord, Telegram und IRC. The official website of Element.io thus lacks the bridge to the international standard XMPP, which is also reflected in the matrix graphic there.

In addition, connections between your individual ‘target systems’ are drawn in here (highlighted in the margin more clearly than in the original), from which one could deduce a direct communication between them (and without matrix in the middle) (which would be wrong).
Interoperability can be viewed in different ways.

Markdown

Markdown is a simple way to display and highlight text in a formatted way - including for displaying links. In the chat standard XMPP it is not possible to create fake links, because there is no way to explicitly call a formatting code to start and end a link. In Matrix, on the other hand, you have the ability to create fake links and you leave it up to the client software to decide what to do.

Example:
Imagine you have an account at bank ‘XY’ and also a Matrix chat account. One day you get the message: “Unexpected money received on account at bank XY - please check: https://bankXY.tld” (feel free to test it!).

Formatted text via Markdown is good for text data in a context where you have time to read and can spare some time to examine the link as well. But for a means of communication that is characterized by “instant “ as a main property, it is problematic at the protocol level.

Reasons for Matrix

The decision to a new protocol and the emergence of Matrix was justified in 2012 by various arguments. These points could have been improved/added directly to the criticized protocol (XMPP) instead of creating a new protocol:

… it is better to improve the existing instead of reinventing the wheel …

However, investors usually expect a return of investment (ROI) after a certain period of time. The investments should of course be profitable and this is not possible with the improvement of a public standard.

Nevertheless, many points of the then (rightly) criticized standard XMPP have improved and “settled” - although no millions of dollars have flowed:

Multiple devices,
usable on mobile devices,
multiple devices are possible,
history synchronization,
there are bridges to other systems

And: The fragmentation that was criticized at that time is now also occurs with Matrix, as is natural for both centralized systems.

Summary / Conclusion

Matrix is a very good solution for distributed work in organizations, companies or authorities! Unlike some other groupware such as Slack, the complete source code is open and therefore verifiable.

From today’s perspective and with this background knowledge, the standard protocol that can actually replace WhatsApp in the broad in the medium term is not the protocol Matrix but vendor-independent chat (based on the standard XMPP).

That there is an interface (bridge) to standardized chat, however, is a great advantage of Matrix, which should not be underestimated. However, this interface should be:

more clearly communicated,
absolutely also activated,
still improved in some places,
implemented without any changes to the content of messages, and
be used in practice

… from a general interoperability point of view, this bridge is even more important than matrix-internal federation. Not by a public federation of matrix servers but by activating and using the important bridge to standardized chat - i.e. by adhering to international standards - actual interoperability is supported and enabled.

More opinions

Why I don’t use Matrix (external)
Fehler in der Matrix (external; 02.06.2022)

Supplementary information:

Date: 01.02.2023
Rights: CC BY-SA
Autors: Diverse (Initiative Freie Messenger)

All articles/thoughts about Messenger: