Thoughts

- Reading time: 46 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 specification 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..

The matrix ecosystem 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:

  1. Neutrality
  2. Funding/Licensing
  3. Translation
  4. Data protection/privacy
  5. Blind-recommendations
  6. Internetstandard
  7. Monolithic protocol
  8. Federation
  9. Free-vendor-choice
  10. Resource requirements
  11. Encryption
  12. User numbers
  13. Electron
  14. External Services
  15. VS-NfD
  16. Bridges
  17. Markdown
  18. Reasons for matrix

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

Neutrality

Matrix.org (the foundation) 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.

What many people don’t know: The Matrix.org Foundation is not only responsible for the protocol, but also for software projects, infrastructure and it owns copyrights (https://matrix.org/blog/2023/11/06/future-of-synapse-dendrite) (external):

Its core mission is to maintain the Matrix Specification, but it does much more than that.

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, it is precisely data protection that is used as an argument to justify closed matrix instances and to avoid having 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. So far, no arguments against genuine interoperability have been put forward.

Cross-references: Difference between federation and interoperability and 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 open/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; ‘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 information:

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

Blind recommendations

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, a certain fragmentation is/was already apparent after a few years:

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?

“But so many are using Matrix!”

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 figures is given by Disroot.org (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. It is not the number of users that is the real reason, but the complexity of the matrix space that causes the high memory and CPU consumption.

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

The simplest solution to the resource problem, which Matrix is currently trying to improve with “conduit” (beta status as of Nov. 2024) (external), is restricting the federation. The complexity of federated rooms is limited and thus the resource requirements are reduced. However, this server software only supports rooms from version 6 (external), which leads to incompatibilities (see above).

In order to remain within the existing technical possibilities, some matrix instances are therefore not operated publicly.

Thesis/Question:
For matrix instances without federation, should improved interoperability also be possible in a resource-saving way by using the chat standard and the “XMPP” interface?

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

Security problems

According to Soatok.blog (external), there have been security problems in the Matrix encryption library “Olm” for years. Instead of correcting these, Matrix recommends that client developers implement a different library instead (Addendum dated 14.08.2024 (external))

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 …

  1. 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)
  2. 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).

Rooms can be actively left, but the problem is that users often simply uninstall their Matrix client without either leaving rooms or deactivating their chat accounts first. Deactivating a chat account, on the other hand, causes the user to log out of all Matrix rooms and “leave” them. Server administrators also usually do not shut down their servers properly by shutting down their server without deactivating all accounts first.

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, but only the users who are currently present in the chat are displayed there. 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

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

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

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.

Privacy policy of Element: https://element.io/privacy (external) under “2.10 Who Else Has Access to My Data?”:

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:

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

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

  1. 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. The original Bifröst bridge is not stable and is not actively developed further. For this reason, user forums generally recommend using the Bifröst version from aria-net.org.
  2. 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

The more up-to-date and frequently used Bifröst bridge from aria-net.org has a major disadvantage: since March 2022, it has been modifying content and ‘translating’ XMPP URIs (addresses) into the matrix format. Fortunately, this “functionality” has not yet been integrated into the original (external) Bifröst bridge.

Changing content is an absolute “no-go” for me - because what arrives at the recipient does not correspond to what the sender of the message actually wrote. The content of messages is displayed on the Matrix page in a modified form and quotes are also distorted as a result. Even if this may seem practical for Matrix users - I don’t like it.

Quite apart from the fact that the content of messages from a bridge should not be changed but only transported:

Here, tasks that a client should take over (optional customization in the display of content) are taken over by the bridge. Links deliberately contain the protocol to be considered, which can have many reasons - including security. The context of messages can otherwise be completely distorted in terms of content.

  • Abstract 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?”

  • Concrete example:

    • 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

Even if only content is changed in the direction of the matrix page - when responses are sent back via the bridge, they then appear with changed (falsified) content. So no point in terms of data integrity.

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.

When visiting public chat rooms (XMPP), it is also not clear to Matrix users that they are only “guests” in the other system. Due to the system-side creation of a Matrix chat room as an independent counterpart to the original, there is a constant risk of confusion during conversations as to what (which side of the bridge) is meant by “here in the chat room”, “we here” or “here”.

Unclear positioning

On the one hand, bridges between the Matrix and XMPP protocols are advertised - on the other hand, XMPP is not listed at all in the Matrix bridges (external) or not mentioned at all. At least not on this important page. However, the point of criticism seems to have been taken on board: On another visit to the site in April 2024, I noticed that the XMPP logo with link to description (external) is now also listed.

To find “XMPP”, you previously had to look under “libpurple”, where you were referred to “matrix-bifrost” 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.” was given. It was only on the Github page linked there that “XMPP” was found.

This means that bridges to XMPP are/were 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 were listed: IRC (6x), Slack, Grid and XMPP
In the information on the available bridges on Matrix.org (external), however, there was no mention of the XMPP standard, no logo and no reference to it (the bridge was hided behind “libpurple” under „matrix bifrost“). **The point of criticism seems to have been taken on board, however, because as of April 2024 this is no longer the case.
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 were listed as of April 2022: WhatsApp, Slack, MS Teams, Signal, Gitter, Discord, Telegram und IRC. The official Element.io website therefore lacked a bridge to the international XMPP standard, which was also reflected in the matrix graphic.
(As of April 2024, there are no more bridges to be found on the element.io website.)

In addition, connections between the individual ‘target systems’ were also marked there (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.

Security problems

Libera.Chat identified various security and data protection issues with regard to the Matrix Bridge. Here is the summary from Libera.Chat from 10.08.2023:

We asked for portalling to be disabled due to compounding concerns such as abuse mitigation workload, various privacy and security issues, and overall stability. We escalated to the temporary shutdown due to a recurring privacy issue where Matrix users not connected to Libera.Chat could see channel content. The issue could not be addressed quickly or limited to opted-in channels. Third party bridges remain welcome and will be judged individually if concerns arise.

Chronicle of Matrix’ misbehavior towards libera.chat and the problems it caused during 2023:

  • 07.06.2023 / Libera.Chat: Updates on the matrix<>IRC bridge (external)
    “We are aware that the Libera.Chat matrix<>IRC bridge (operated by Element Matrix Services, ‘EMS’) has experienced a number of issues as of late, including silently dropping messages, dropping connections, and leaking information about the existence of +s (secret) channels to users not in those channels. …”

  • 03.07.2023 / Libera.Chat: Disabling Matrix Portalling (external)
    ”… Libera.Chat will request that EMS disable Portalled channels, and that EMS do this by 31st July 2023 but not before 25th July 2023. If disabling Portalled Channels is not possible, Libera.Chat will ask that EMS to disable the full Matrix bridge in the same timeframe. …”

  • 28.07.2023 / Libera.Chat: Delays in Disabling Matrix Portalling ”… Given the nature of the issues, we have agreed to extend the deadline to the 11th of August, 2023, providing an additional 2 weeks to address these high priority issues and improve the plumbing situation. …”

  • 28.07.2023: Matrix.org: Postponing the Libera.Chat deportalling (external)
    ”… However, at this point, we do not believe the plumbed mode can be considered sufficiently stable yet. Additionally, as part of the project we have been made aware of several new bridge security issues. These issues must be patched ahead of the plumbing stability work thereby increasing the overall scope of the project. The limited resources of the Matrix.org Foundation didn’t allow us to meet the deadline in time.”

    (Here the question may be asked why Matrix.org as the neutral organization responsible for the protocol, does programming work?)

  • 05.08.2023 / Libera.Chat: Temporarily disabling the Matrix Bridge (external)
    ”… In order to protect our users and our IRC-first communities from mounting stability, security, and privacy issues, we requested that EMS remove the Matrix bridge from Libera.Chat until this serious regression can be fixed, and all other outstanding issues are likewise resolved. EMS agreed to shut the bridge down by 1400UTC Saturday August 5th. …”

  • 10.08.2023 / Libera.Chat: Matrix Bridge Temporary Shutdown, a Retrospective (external)
    ”… Some people have requested transparency into how Libera came to the conclusion that we needed to take the drastic action of requesting that Element Matrix Services (EMS) deactivate the portalling bouncer-like feature of the Matrix bridge and limit it to explicitly opted-in plumbed rooms, and then escalate to more serious action in requesting the bridge be disabled fully. …”

  • 28.11.2023: Matrix.org: Shutting down the Matrix bridge to Libera Chat (external)
    “Today we are sorry to announce that we are not able to bring the Libera Chat bridge back online. …”
    ”… People who need a bridge for their community can run their own: the matrix-appservice-irc software is still maintained. Only its Libera Chat instance, which was configured to persist connections across restarts, is being shut down. …”

Additional information: https://libera.chat/guides/matrix (external)

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.

However, the fact that there are interfaces (bridges) to standardized chat is a great advantage of Matrix that should not be underestimated. However, this interface should:

  • 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 (but not between!) organizations, companies or authorities!** Unlike some other groupware such as Slack, the complete source code is open and therefore verifiable. In my opinion, interoperability with Matrix is not possible through open federation with other Matrix instances, but only through the use of the interface to the XMPP chat standard.

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

Even though some points in the following (critical) articles may have been rectified in the meantime, they should not be demonized as a whole:

  • koehntopp.info: The Matrix Trashfire (external)
    The co-founder of Matrix has responded to the article at lobste.rs (external).

  • telegra.ph: Why not matrix? / 2023 (external)
    Regarding to their points 11 and 12: According to Matrix specifications (from room version 6), these should have been resolved by now, as reported in a forum. I would be interested in more specific information here. Please let me know if you have any expertise: [>> contact <<][/en/kontakt]
    Regarding to their point 17: Switching off the server is actually not enough, but that is the intention according to the specification. However, a room can be closed in a federation by the admin of the room (or its server admin) - either by kicking everyone in the room or revoking their permissions. All well-meaning federating servers will respect this.

  • cr-online.de: Fehler in der Matrix / 2022 (external)

  • nuegia.net: Why I don’t use Matrix / 2020? (external)

  • hackea.org: Matrix? No, thanks / 2020 (extern)
    When asked whether there was any feedback on the content of the article, the following response was sent by email (31.03.2024⁄02.04.2024):
    „We have had some few messages about that, they basically said they did not like the article, but none could prove there was something incorrect or inaccurate.“ and
    „According to the report, you did not need to have any conversation or chat room with a user at matrix.org to have your self-hosted instance sending all those loads of metadata to matrix.org and vector.im, your self-hosted instance was sending it anyway.“

Further corrections are welcome! >> Contact <<

Supplementary information

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

All articles/thoughts about Messenger: