Matrix

- Reading time: 48 minutes / whole rubric: 91 minutes -

Provider-independent chat based on the protocol “Matrix” is a recommendation in the Quick Overview!

“Matrix” has been under development since 2014 and, like XMPP, is a federated messenger protocol. However, it is not an Internet standard defined by the IETF but is owned by the Matrix.org Foundation. It is not known whether Matrix.org is seeking public standardization of communication protocols.

Table of contents:

Matrix as ‘the’ solution

Matrix sees itself as the central solution for interoperability - and part of its business model is to reach as many other systems (external) as possible through different bridges (see below):

An important idea in Matrix is Interoperability. … We refer to the connection to other platforms as bridging.

Following this world of thought, Matrix formulates this, for example, as follows:

“With the Matrix communication protocol, users - independent of the respective app - should be able to communicate with each other.” (“Web3 Summit” in May 2020)

That sounds great, but what does it actually mean and in practice?

There is always a redirection via Matrix, there is no direct message exchange between the connected “target” systems. As a consequence, depending on the execution of the bridge (see below), there is an enrichment of metadata in the Matrix universe, although users have not opened chat accounts there at all. And as soon as the term “interoperability” is used in marketing, it should be asked what is actually meant by it.

Cross-references: Thoughts on “interoperability “ and Matrix opinion

Reasons for the development of Matrix

The Matrix team used XMPP (Openfire, ejabberd, spectrum, asmack, XMPPFramework) for IM before starting to experiment with open HTTP APIs as an alternative in around 2012 …

The main issues with XMPP that drove us in this direction as of 2012 were:

  • Not particularly web-friendly - you can’t easily speak XMPP from a web browser. N.B. Nowadays you have options like XMPP-FTW and Stanza.io that help loads with letting browsers talk XMPP. Single logical server per MUC is a single point of control and availability. MUCs can be distributed over multiple physical servers, but they still sit behind a single logical JID and domain. FMUC improves this with a similar approach to Matrix, but as of Oct 2015 there are no open source implementations. The MIX XMPP extension also aims to address this limitation.
  • History synchronisation is very much a second class citizen feature
  • Bridging to other protocols and defragmenting existing communication apps and networks is very much a second class citizen feature
  • Stanzas aren’t framed or reliably delivered without extensions. See wiki.xmpp.org for an XMPP take on this
  • Multiple device support is limited. Carbons and MAM aim to resolve this
  • Baseline feature set is so minimal that fragmentation of features between clients and servers is common, especially as interoperability profiles for features have fallen behind (as of July 2015)
  • No strong identity system (i.e. no standard E2E PKI, unless you count X.509 certs, which are questionable)
  • Not particularly well designed for mobile use cases: push; bandwidth-efficient transports. Since the time of writing a Push XEP has appeared, and wiki.xmpp.org states that XMPP is usable over a 9600bps + 30s latency link.

This said, 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.

We think of Matrix and XMPP as being quite different; at its core Matrix can be thought of as an eventually consistent global JSON db with an HTTP API and pubsub semantics - whilst XMPP can be thought of as a message passing protocol. You can use them both to build chat systems; you can use them both to build pubsub systems; each comes with different tradeoffs. Matrix has a deliberately extensive ‘kitchen sink’ baseline of functionality; XMPP has a deliberately minimal baseline set of functionality. If XMPP does what you need it to do, then we’re genuinely happy for you :) Meanwhile, rather than competing, an XMPP Bridge like Skaverat’s xmpptrix beta or jfred’s matrix-xmpp-bridge or Matrix.org’s own purple-matrix has potential to let both environments coexist and make the most of each other’s benefits.

Source: https://web.archive.org/web/20180711050333/https://matrix.org/docs/guides/faq.html (external)
Cross reference: Criticism

Concept

In Matrix, data is stored not only by one server but by all servers of the people involved in the group or conversation. Furthermore, the provision of “bridges” to other systems is an essential point with which Matrix contributes to interoperability.

Due to the distributed data on all participating servers, there is a certain failure safety of chat rooms.

Every conversation (no matter if 1:1, group or bridge to any other protocol) is a room. This makes it possible to turn a 1:1 chat into a group or vice versa. You can also open as many rooms as you like with one contact.

Chat rooms are synchronized among all participating servers of the participants (on each participating server all messages of the room are stored). This means that in case of a server failure, all participants from other servers can continue to use the chat room normally. In terms of the “git” version control system, you could think of this roughly as “chatting via git”. Of course this is not actually “git” - but the principle is the same and therefore helpful for understanding.

Chatroom resilience comes at the price of higher resource requirements. Fail-safe chat rooms are especially interesting for companies, enterprises, authorities.

Regarding the concept or resources required, founder/co-developer/director Hodgson personally stated in a blog comment (external) thus:

The fact that Matrix is using so much resources for a single user is because it’s a message store, not a messaging protocol like XMPP. If you join loads of busy rooms, the rooms get replicated onto your server. So a single busy user can easily use gigabytes of disk space. We’re improving the efficiency, but in the end one enthusiastic user can use way more space than thousands of users who just DM each other.

The protocol is monolithic (from one cast) and does not consist of different or extendable modules. In case of new or changed requirements, the protocol is modified/extended as a unit. The server implementation can consist of several parts as long as the server as a whole completely supports the matrix specification.

For telephony (audio/video telephony), the protocol uses “WebRTC” - for video conferencing, on the other hand, the very well integrated “Jitsi” and BigBlueButton (BBB). Jitsi in turn uses the XMPP extension “Jingle” to signal the video streams between clients and bridge. In addition, “XMPP MUC” is used to manage the conference rooms.

In Matrix’s philosophy, basically every chat is a room - even if 2-person chats are not marked that way. So for a chat with no matter how many users (also in own chats for oneself, e.g. to send notes to oneself over several clients) a room is created. Due to this circumstance, a personal conversation can therefore be added to at any time.

In July 2020 the Matrix reference client “Riot” (the messenger), New Vector (the company behind Riot) and Modular (web hosting for Matrix servers) was renamed to “Element”.

The matrix protocol here (very compressed) to read: https://github.com/matrix-construct (external)
And here is an overview of documents on security topics: https://github.com/jryans/awesome-matrix#research (external)

Sources:

End-to-end encryption

Matrix end-to-end encryption does not provide so-called “perfect forward secrecy” (PFS; see Limits of matrix encryption. It left the beta stage in May 2020 and is enabled in private chat rooms.
Source: https://github.com/vector-im/riot-web/issues/6779#issuecomment-624140449

Technically, the encryption is based on “Olm” or “Megolm”. It is an implementation of the Double Ratchet method, which is also the basis of the OMEMO encryption known from Jabber. 2016 the Olm implementation was tested by the ncc group. >> Review report dated 11/01/2016 << (PDF file)
Source: nccgroup (external)

However, the rollout of encryption in live operation was rushed and many users were unaware of the “beta” stage (which was not completed until May 2020):

„negatives: the python server impl (synapse) was rushed & we are still paying off tech debt; it’s still a bit of a resource hog. E2EE is still not force-enabled until we have full parity with non-E2EE. The SS API is fairly subtle (there are few alt impls). The groups API sucks.“

Source: Twitter 21.11.2019 (external)

For the encryption protocol of Matrix there is a good Execution/Description (external; English) in the blog of jabberhead.tk.

Disable encryption?
In some cases it can be useful to disable encryption if needed. For example, if bridges are to be used to communicate with users of other systems, or if internal company regulations make this necessary.

Limits of matrix encryption

The following points describe the limits of Megolm (external):

  • Message Replays
    A message can be decrypted successfully multiple times. This means that an attacker can re-send a copy of an old message, and the recipient will treat it as a new message.
    To mitigate this it is recommended that applications track the ratchet indices they have received and that they reject messages with a ratchet index that they have already decrypted.

  • Lack of Transcript Consistency
    In a group conversation, there is no guarantee that all recipients have received the same messages. For example, if Alice is in a conversation with Bob and Charlie, she could send different messages to Bob and Charlie, or could send some messages to Bob but not Charlie, or vice versa.
    Solving this is, in general, a hard problem, particularly in a protocol which does not guarantee in-order message delivery. For now it remains the subject of future research.

  • Lack of Backward Secrecy
    Backward secrecy (also called ‘future secrecy’ or ‘post-compromise security’) is the property that if current private keys are compromised, an attacker cannot decrypt future messages in a given session. In other words, when looking backwards in time at a compromise which has already happened, current messages are still secret. By itself, Megolm does not possess this property: Once the key to a Megolm session is compromised, the attacker can decrypt any message that was encrypted using a key derived from the compromised or subsequent ratchet values.
    In order to mitigate this, the application should ensure that Megolm sessions are not used indefinitely. Instead it should periodically start a new session, with new keys shared over a secure channel.

  • Partial Forward Secrecy
    Forward secrecy (also called ‘perfect forward secrecy’/‘PFS’) is the property that if the current private keys are compromised, an attacker cannot decrypt past messages in a given session. In other words, when looking forwards in time towards a potential future compromise, current messages will be secret. In Megolm, each recipient maintains a record of the ratchet value which allows them to decrypt any messages sent in the session after the corresponding point in the conversation. If this value is compromised, an attacker can similarly decrypt past messages which were encrypted by a key derived from the compromised or subsequent ratchet values. This gives ‘partial’ forward secrecy.
    To mitigate this issue, the application should offer the user the option to discard historical conversations, by winding forward any stored ratchet values, or discarding sessions altogether.

  • Dependency on secure channel for key exchange
    The design of the Megolm ratchet relies on the availability of a secure peer-to-peer channel for the exchange of session keys. Any vulnerabilities in the underlying channel are likely to be amplified when applied to Megolm session setup.
    For example, if the peer-to-peer channel is vulnerable to an unknown key-share attack, the entire Megolm session become similarly vulnerable. For example: Alice starts a group chat with Eve, and shares the session keys with Eve. Eve uses the unknown key-share attack to forward the session keys to Bob, who believes Alice is starting the session with him. Eve then forwards messages from the Megolm session to Bob, who again believes they are coming from Alice. Provided the peer-to-peer channel is not vulnerable to this attack, Bob will realise that the key-sharing message was forwarded by Eve, and can treat the Megolm session as a forgery. A second example: if the peer-to-peer channel is vulnerable to a replay attack, this can be extended to entire Megolm sessions.

Data protection

Currently there are no German General Terms and Conditions (AGB). However, in the “privacy notice” (external) you can read:

“2.1.2 Right to Erasure - “We therefore share state events sent by your account with all non-essential data removed (‘redacted’), even after we have processed your request to be forgotten. This means that your username will continue to be publicly associated with rooms in which you have participated, even after we have processed your request to be forgotten.”

This means that the relationship of persons to rooms cannot be deleted, which may need to be checked in connection with the DSGVO.

By the recommendation to enter the phone number (identity server), these are kept in a central directory.

Matrix.org Privacy and Data Collection Notice:

  • Part 1 (external): Focusing on the software stack and the privacy impact of its default configuration.
  • Part 2 (external): Focusing on GDPR compliance, example of a GDPR Information and Data request, and disclosure of a Personal Data Breach by Matrix.org

The Grid

With “The Grid” (external) there is a Matrix spin-off from a few former Matrix developers that aims for more freedom and privacy. Some of the points listed there are true, but they have been mostly fixed: https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 (external).

„The Grid’s data collection papers contained some valid points, which were mostly fixed.“

Source: From forwarded information by e-mail

“The Grid” strives to achieve the following goals:

  • Solve the problem originally identified by the Matrix protocol, fragmented communication, incorporate a social view
  • Simple client implementations, and federated server communications that bear the main burden
  • Decentralized data storage, distributed among participating servers
  • Designed to avoid centralization and/or monopolization

“Matrix’s ideals are Openness, Decentralization and Encryption while The Grid’s ideals are Freedom, Privacy and Security.”

Source: https://gitlab.com/thegridprotocol/home/blob/master/docs/overview.md (external)

Bridges

For Matrix, bridges (“Matrix-Bridges”) are elementary and a part of the business basis (where this applies to all teammessenger - so also Mattermost, Rocket.Chat and Zulip).

There are various bridges to exchange messages with other systems and the intention is to provide interoperability. So it is tried - like with different languages - to translate between them. It would be ideal for the users if they would not notice this process at all and could use all functions as usual. However, it is very difficult and time-consuming to make two different systems with all their respective rules (“protocols”) completely compatible. Therefore, a bridge can usually only provide a limited intersection of functions, such as the exchange of simple messages. The online status as an essential feature of chat, for example, can of course not be transmitted if the presence is not part of the protocol.

Cross-reference: Are bridges and their use legal?

Unfortunately, it is also the case that bridges are not bound to standards and can be set up and changed by the operator at will. Also, for example, message content can not only be transported 1:1, but can also be changed in transit to provide a more pleasant user experience for native Matrix users. (cross-reference: critic ‘data integrity’ )

Types of bridged rooms

  • Portal rooms
    Bridges can register themselves as controlling chunks of room aliases namespace, letting Matrix users join remote rooms transparently if they /join #freenode_#wherever:matrix.org or similar. The resulting Matrix room is typically automatically bridged to the single target remote room. Access control for Matrix users is typically managed by the remote network’s side of the room. This is called a portal room, and is useful for jumping into remote rooms without any configuration needed whatsoever - using Matrix as a ‘bouncer’ for the remote network.

  • Plumbed rooms
    Alternatively, an existing Matrix room can be can plumbed into one or more specific remote rooms by configuring a bridge (which can be run by anyone). For instance, #matrix:matrix.org is plumbed into #matrix on Freenode, matrixdotorg/#matrix on Slack, etc. Access control for Matrix users is necessarily managed by the Matrix side of the room. This is useful for using Matrix to link together different communities.

    Migrating rooms between a portal & plumbed room is currently a bit of a mess , as there’s not yet a way for users to remove portal rooms once they’re created, so you can end up with a mix of portal & plumbed users bridged into a room, which looks weird from both the Matrix and non-Matrix viewpoints. https://github.com/matrix-org/matrix-appservice-irc/issues/387 (external) tracks this.

Types of bridges

There are many theoretically available bridges - however, only some of them are actively offered by the two closely related companies with the sites matrix.org and element.io, and some of them are even different. The marketing for this is not easy to see through, because there seems to be no common positioning but different prioritizations of offered bridges on the part of matrix.org and element.io. Bridges to popular but closed platforms like WhatsApp are advertised - the interface to the standard protocol for chat (XMPP), on the other hand, is currently still in the experimental stage and is (perhaps therefore?) lost in the marketing.
It would be interesting how many development (days/hours) and how much of the founded money is invested in the different kind of bridges:

  • Bridgebot-based bridges
    The simplest way to exchange messages with a remote network is to have the bridge log into the network using one or more predefined users called bridge bots - typically called MatrixBridge or MatrixBridge[123] etc. These relay traffic on behalf of the users on the other side, but it’s a terrible experience as all the metadata about the messages and senders is lost . This is how the telematrix matrix<->telegram bridge currently works.

  • Bot-API (aka Virtual user) based bridges
    Some remote systems support the idea of injecting messages from ‘fake’ or ‘virtual’ users, which can be used to represent the Matrix-side users as unique entities in the remote network. For instance, Slack’s inbound webhooks lets remote bots be created on demand, letting Matrix users be shown cosmetically correctly in the timeline as virtual users. However, the resulting virtual users aren’t real users on the remote system, so don’t have presence/profile and can’t be tab-completed or direct-messaged etc. ) They also have no way to receive typing notifs or other richer info which may not be available via bot APIs. This is how the current matrix-appservice-slack bridge works.

  • Simple puppeted bridge
    This is a richer form of bridging, where the bridge logs into the remote service as if it were a real 3rd party client for that service. As a result, the Matrix user has to already have a valid account on the remote system. In exchange, the Matrix user ‘puppets’ their remote user, such that other users on the remote system aren’t even aware they are speaking to a user via Matrix. The full semantics of the remote system are available to the bridge to expose into Matrix. However, the bridge has to handle the authentication process to log the user into the remote bridge.
    This is essentially how the current matrix-appservice-irc bridge works (if you configure it to log into the remote IRC network as your ‘real’ IRC nickname). matrix-appservice-gitter is being extended to support both puppeted and bridgebot-based operation. It’s how the experimental matrix-appservice-tg bridge works.
    Going forwards we’re aiming for all bridges to be at least simple puppeted, if not double-puppeted.

  • Double-puppeted bridge
    A simple ‘puppeted bridge’ allows the Matrix user to control their account on their remote network. However, ideally this puppeting should work in both directions, so if the user logs into (say) their native telegram client and starts conversations, sends messages etc, these should be reflected back into Matrix as if the user had done them there. This requires the bridge to be able to puppet the Matrix side of the bridge on behalf of the user.
    This is the holy-grail of bridging because both the Matrix account and the third party account are accurately represented on their respective networks, with all user metadata intact. This is in contrast to a relaybot which would appear as a separate user from whom it represents.
    Several obstacles exist to the proper implementation of double-puppeted bridges. On the Matrix side, we need an elegant way of having the bridge auth with Matrix as the matrix user (which requires some kind of scoped access_token delegation). On the third-party network, unique problems exist depending on the limitations of that particular network network. For example, many third party networks will lack the ability to represent other Matrix users than the one being puppeted (see hybrid relaybot).
    matrix-puppet-bridge is a community project that tries to facilitate development of double-puppeted bridges, having done so, without a bridgebot feature, for several networks. A downside to their approach is the assumption that an individual will run the bridge on their own homeserver, thus working around the problem of sharing auth credentials on a shared homeserver.

  • Hybrid Relaybot Puppet Bridge
    This type of bridge is a combination single or double puppet bridge which tries to solve the problem of representing other users by means of the bridgebot technique. mautrix/telegram works in this way.

  • Server-to-server bridging
    Some remote protocols (IRC, XMPP, SIP, SMTP, NNTP, GnuSocial etc) support federation - either open or closed. The most elegant way of bridging to these protocols would be to have the bridge participate in the federation as a server, directly bridging the entire namespace into Matrix.
    We’re not aware of anyone who’s done this yet.
    [Annotation: It’s not the job of others. Shouldn’t this be the holy-grail of bridging instead of double-puppet bridge? Please invest here some of the founded money to integrate a xmpp-server direct into matrix server to achieve interoperability!]

  • One-way bridging
    One-way bridging is rare, but can be used to represent a bridge that is bridging from the remote system into matrix. This is common when the remote system does not permit message posting, or is simply not capable of handling posting outside their system. The users bridged from the remote system often appear as virtual users in matrix, as is the case with matrix-appservice-instagram.

  • Sidecar bridge
    Finally: the types of bridging described above assume that you are synchronising the conversation history of the remote system into Matrix, so it may be decentralised and exposed to multiple users within the wider Matrix network.
    This can cause problems where the remote system may have arbitrarily complicated permissions (ACLs) controlling access to the history, which will then need to be correctly synchronised with Matrix’s ACL model, without introducing security issues such as races. We already see some problems with this on the IRC bridge, where history visibility for +i and +k channels have to be carefully synchronised with the Matrix rooms.
    You can also hit problems with other network-specific features not yet having equivalent representation in the Matrix protocol (e.g. ephemeral messages, or op-only messages - although arguably that’s a type of ACL).
    One solution could be to support an entirely different architecture of bridging, where the Matrix client-server API is mapped directly to the remote service, meaning that ACL decisions are delegated to the remote service, and conversations are not exposed into the wider Matrix. This is effectively using the bridge purely as a 3rd party client for the network (similar to Bitlbee). The bridge is only available to a single user, and conversations cannot be shared with other Matrix users as they aren’t actually Matrix rooms. (Another solution could be to use Active Policy Servers at last as a way of centralising and delegating ACLs for a room)
    This is essentially an entirely different product to the rest of Matrix, and whilst it could be a solution for some particularly painful ACL problems , we’re focusing on non-sidecar bridges for now.

Source: https://matrix.org/docs/guides/types-of-bridging (external; 01.08.2022)

It is noticeable that it is often talk about problems and in the form of possibilities . That is also the reason why bridges are often called old crutches.
Cross-references: criticism: ‘bridges’ and interoperability: ‘bridges’

Another description about bridges: blog.novatrend.ch (external)

XMPP-bridge

With “Bifröst/libpurple” there is a bridge that was presented at FOSDEM 2020 (external):

„… and demonstrate high quality bridging with XMPP, Slack, Discord, WhatsApp, and more!“

What is specifically understood by “high quality”? At least the note given for this bridge does not quite fit “high quality”: “Puppet bridge for general purposes with libpurpule and other systems. This bridge is currently under very active development and is mainly intended for experimentation and evaluation purposes.”

„General purpose puppeting bridges using libpurple and other backends. This bridge is in very active development currently and intended mainly for experimentation and evaluation purpose.“ (Originaltext Stand 04/2022)

Notice:
In public chat rooms Matrix does not provide "semi-anonymity". This means that not only administrators, but all participants see not only the alias, but the actual used (XMPP) chat address.

Technical details about Bifröst can be found at https://github.com/matrix-org/matrix-bifrost/wiki/Address-syntax (external) and https://aria-net.org/SitePages/Portal/Bridges.aspx (external). In addition, matrix.org offers a public instance of the bridge:

„matrix.org hosts a public instance of Bifröst for XMPP bridging. You can join any chat from either side of the bridge using the address syntax below. …“_ (Stand 02.05.2020)

It works:

  • Unencrypted messages between Matrix and XMPP rooms

  • Adding individual XMPP users to 1:1 conversations (i.e. independent of groups/public chat rooms):

    • via website(!?): -> invite -> @xmpp=40:matrix.org
    • via the client “element “ -> +chat -> invite ID -> @_xmpp_xmppusername=40xmppserver.TLD:matrix.org

  • Invitations to an already existing chat room

    • The native connection for connecting XMPP chat rooms for Matrix users:
      #_xmpp_CONFERENCE.SERVER.TLD_MUCNAME:matrix.org
      (instead of the part “CONFERENCE” of course depending on the server individually also: room/rooms/muc/chat/…
    • The command is: /join #xmpp_:matrix.org
    • Example how to get into the public chat of “Free Messenger”: /join #_xmpp_conference.jabber.de_conversations:matrix.org

  • Conversely, an XMPP user can reach a Matrix user via the central service matrixuser_matrixserver.tld@matrix.org

  • Typing notifications are displayed on the Matrix page (“XY is typing”)

Github: https://github.com/matrix-org/matrix-bifrost (external), https://github.com/matrix-org/matrix-bifrost/graphs/code-frequency (external)

Restrictions:

  • Communication in the room must not be end-to-end encrypted.

  • Occasionally Jabber(XMPP) chat rooms cannot be entered if “create” is accidentally selected via the matrix bridge instead of “join”. Then the (wrong) error message “does not exist” appears.

  • For images sent via the bridge missing the file extension, so without manually adding e.g. “.JPG”” or “.PNG” only the preview image is displayed here.

Further development of Bifröst / Aria Networks

matrix.org does not seem to have a big motivation in the development of the Bifröst bridge. Therefore Aria Networks (Aria-net (external) has made some improvements to the Bifröst bridge and bugfixed it. Unfortunately these points are not taken over by the original project. In the meantime in matrix circles therefore often the aria-net-bridge) (external) instead of the Bifröst bridge from matrix.org.

Thoughts about the XMPP bridge.

Basically, for connections from Matrix to XMPP, there are three possible ways to develop a connection (bridge/transport):

  1. a real, direct bridge (where a Matrix user gets his own name (“alias/nickname”) in the XMPP space and vice versa) - like it is currently possible with “bifröst”.

  2. an automatism in the form of a single user, who simply forwards all messages - as a robot (=robot = bot) - is/was error-prone.

  3. communication via a third place
    e.g. via IRC. Advantage is that one can use the “matrix api service”. Sequence: The matrix server goes through a matrix-irc-appservice which connects to an IRC channel. The same would then have to be done from xmpp (e.g. via “biboumi” into the same IRC channel.
    However, this would have a significant disadvantage: communication via a third party system and thus more complexity and error-proneness.

Another bridge project https://matrix.org/docs/projects/as/matrix-xmpp-bridge (external) was discontinued in 2019.

WhatsApp

Matrix has a bridge to the chat standard XMPP called Bifröst/Libpurple and also markets it. With the project Mautrix (external) there is further possibility. The current available features (external) are impressive.

However, all providers/users who use WhatsApp’s web interface for their purposes must expect that this (abusive) use of Meta/Facebook can be quickly stopped by changes.

Cross-reference: legality of bridges

Further

  • With Matterbridge (external) also many bridges between different systems are possible.
  • This project (external) deals with accessing Matrix via shell scripts.

Use

Instructions

Matrix ID

Structure of the user ID in real operation: @username:servername.tld
For connections going over IRC in other systems: #channel%ircserver@xmpp_component

**conversion Chat addresses (chat standard XMPP), SMS (phone numbers), email addresses as well as SIP addresses can be displayed here in matrix format: https://cheogram.com/matrix (external)

Permissions

There are different permission levels for participants of group chats. Currently, a room administrator can only make these settings/changes from the PC:

  • 0 - Standard
  • 50 - Moderator
  • 100 - Administrator

However, the upgrading of users to moderators or to administrators can then also be done mobile e.g. via a smartphone/tablet.

Server

During server installation, self-signed TLS certificates are initially created, but these can then be easily replaced with Let’s Encrypt certificates. This must be done manually. For communication between different servers (federation), port 8448 is used by default.

In addition to the standard matrix server software “Synapse”, there are also other solutions such as “Conduit”, which can be used to run your own matrix island (without federation and of course without interoperability). The server software can even be installed on a mini-computer like the Raspberry Pi.

As a successor to Synapse, “Dendrite” has been in the works since 2020. This server software is not written in Phyton but in the programming language “Go”. Dendrite is supposed to improve efficiency, reliability and scalability (see https://gnulinux.ch/matrix-von-synapse-zu-dendrite (external)) - however, Dendrite is still in beta stage.
A nice tutorial can be found here: https://ersei.net/en/blog/setting-up-matrix-dendrite (external; English)

Synapse: https://github.com/matrix-org/synapse (external; English)
Dendrite: https://github.com/matrix-org/dendrite (external; English)
Conduit: https://conduit.rs (external; English)

Connections

An overview of the server landscape at Matrix can be found at https://voyager.t2bot.io/#/graph (external).

Voyager is a bot that travels through Matrix trying to find new rooms. He does this by sitting in rooms and waiting for someone to mention another room, then trying to join that room. Each new room he discovers is mapped to a public graph.

Matrix server connections
In the central area are the servers with many connections - further out are those with fewer connections and at the edge of the pane are the servers without connections.
Matrix server connections (central cutout)
Most connections converge at the two major instances “Matrix.org” and “Element.im”(=“Riot.im”).

Server lists

Own server

Tip: Reduce resource consumption: Matrix Synapse native on Ubuntu consumes a lot of RAM and CPU (external)

More:

  • Tip 1: If you have your own Synapse server, home automation is also possible.
  • Tip 2: If no public rooms are to be visited:. In this case restrict Synapse regarding the federation or let it listen only locally under 127.0.0.1:8448 and restrict a federation additionally by whitelist. I.e. adapt the configuration file (homeserver.yaml) accordingly and simply enter - <OwnServerName> at federation_domain_whitelist:.
  • Tip 3: Compress database:
    • Stuff that no longer needs to be kept around
    • Optimizing synapse cache
    • Table bloat & Index bloat in PostgreSQL

Source: https://levans.fr/shrink-synapse-database.html (external, English)

Further server info

Clients

A plus point of Matrix is that there are working clients (programs/apps) for almost all operating systems (external, English). But beware: Many of the apps listed on the page are still in alpha or beta stage or are no longer being developed further (the status of the individual projects is no longer immediately visible on the overview page - now please look one level deeper in the details).

  • Element (PlayStore: USK 18) is the quasi reference client with the largest distribution. Only 1 chat account is possible; the desktop application is based on Electron.

  • FluffyChat (external) (PlayStore: USK 18)
    This cuddly client runs among other things also on the operating system “UbuntuTouch”. Only application without Electron for the desktop, as the others are still in the development stage (alpha/beta) or are no longer being developed. *

  • SchildiChat (external) (PlayStore: USK 0)

  • Syphon (external) (PlayStore: USK 0)
    This client has a very interesting approach, because here, in addition to the server-based also a direct, serverless communication should be enabled (“P2P”). However, Syphon is still in an early alpha stage and therefore not suitable for actual productive use yet. Basis for this is p2p-matrix (external) / pinecone-overlay-network (external).

  • Zom (external) (PlayStore: USK 0)
    With ZOM for Android and iOS (formerly an XMPP client; now Matrix), several chat accounts can be used. It is possible to log in here with all the accounts that were created under Element. Unlike Element, ZOM does not allow telephony or video telephony. Another advantage is that encryption is already enabled and is relatively easy to use.
    Source code: https://github.com/zom (external)

*) Other Electron-free desktop clients than FluffyChat are not recommended:

  • Fractal (external): Maturity: Beta
  • NeoChat (external): Maturity: Beta
  • Nheko (external): Maturity: Beta
  • Seaglass (external): Maturity: Not actively maintained / At this stage it is early in development and stands a good chance of being buggy and unreliable.
  • Spectral (external): Maturity: Alpha

Chat rooms

Since everything is considered/treated as a “room”, it is possible to (accidentally) open multiple rooms with the same contact without any problems.

For chatrooms (all are rooms) there are different versions (external) as room specifications evolve.

Funding

Unlike other messengers like Telegram, the structures (information about the company, the people involved as well as the funding) are public:

  • Funding:
    From 2014 to 2017 Matrix was funded by Amdocs (external) (Morris Kahn, Israel), even later there were contacts. More about Amdocs >> here <<.
    At Golem (external) is to be found in addition:

… The two founders of the project, Matthew Hodgson and Amondine Le Pape, as well as a small core development team are paid by the US software service provider Amdocs, which also holds the rights to Riot. Amdocs naturally has a commercial interest in the development, Hodgson confirms. The main goal is to develop hosting and support services for business customers and thus market the Matrix platform. … Another business area for Amdoc could be chargeable bridges for business applications.

On this, the Matrix developers formed their own company, New Vector Limited, for funding.

The investment group “Notion Capital” specializes in European companies that offer software applications over the Internet, i.e. as a service, or have a licensing model (“Notion Capital is a VC firm focused on European SaaS and Cloud”). The investor first became involved with Element.io in 2017 and included it in the portfolio: https://www.notion.vc/portfolio/element (external). Through Notion, jobs are also repeatedly offered at Element.io.

Funding problems

Funding seems to be faltering at the end of 2022, as Matrix users are clearly asked to contribute to the funding (of what exactly?) in a blog article from matrix.org (external) despite open licensing. Thoughts on this are formulated >> here <<.

Participations Matrix

  • Jan 29, 2018: Matrix raised $5,000,000 from Status.im

Total (external):
Matrix has raised a total of $5M in funding over 1 round. This was a Venture - Series Unknown round raised on Jan 29, 2018. Matrix is funded by Status.im.

Participations New Vector

Gesamt (external):

  • Element has raised a total of $48.1M in funding over 5 rounds. Their latest funding was raised on Jul 26, 2021 from a Series B round.
  • Element is funded by 8 investors. Metaplanet Holdings and Notion Capital are the most recent investors.
  • Element has acquired Gitter on Sep 30, 2020.

Blockchain and cryptocurrency

In 2018, blockchain messenger status.im, which is very closely associated with the cryptocurrency “Etherum”, invested $5 million in Matrix.org (and another $5 million in New Vector):

Status invests $5 million in Matrix to create a blockchain messaging superpower

Enter Status, the mobile Ethereum client built entirely on peer-to-peer technologies. Today, Status has announced a significant investment in New Vector, the company behind Matrix.org, the open standard for secure and decentralized communication.

How significant? Status is making a $5 million investment in New Vector, effectively creating a partnership between two of the industry’s largest decentralized messaging platforms.

Source: https://venturebeat.com/2018/01/29/status-invests-5-million-in-matrix-to-create-a-blockchain-messaging-superpower/ (external)

The board of directors of the foundation also includes (as of 04/2022) the company Parity Technologies (external), which is active in the field of blockchain technologies.

Structures

Term usage:

Element is the term for both the client, the web page, and companies. The web page is: https://element.io (external) - https://vector.im (external) redirects to element.io.

According to https://element.io/privacy (external), ‘Element’ can usually be equated with New Vector Ltd, New Vector SARL (external) and Element Software Inc:

Where you read ‘Element’ or ‘we’ or ‘us’ below, it refers to Element, a trading name of New Vector Ltd., its French subsidiary: New Vector SARL, its U.S. subsidiary: Element Software Inc, and their agents.

Organization and companies

  • Amdocs: The beginning of Matrix still under the name “Amdocs Unified Communications” (external)

  • The Matrix.org Foundation C.I.C. develops and maintains the Matrix protocol

  • NEW VECTOR LIMITED is the world’s largest Matrix hoster, owns the registered trademark “Element” and also operates, for example, the identitieservers Matrix.org and Vector.im or is the “data controller” for these services source (external). The page https://element.io (external) is from New Vector.
    Registry excerpt at service.gov.uk (external)

  • New Vector SARL Company under French law (no concrete information found on the net about this yet)

  • ELEMENT SOFTWARE INC., USA
    At opencorporates.com (external) or nhcompanyregistry.com (external) or bizpedia.com (external) a total of 11 [ELEMENT SOFTWAR INC. …] are found, of which 3 are noted as old/inactive. (Activity information is still missing) …

  • PARITY TECHNOLOGIES LIMITED and Parity Technologies Deutschland GmbH, Berlin / Blockchain Technology (external))

Commissioned companies:

  • Commercial law firm “King & Wood Mallesons” (external) in London: postal address for New Vector Limited
  • CT Corporation System / Wolters Cluwer (external) (Said to be the world’s leading provider of legal entity management, corporate compliance and due diligence solutions / leading legal entity management solutions company): Registered Agent for various ELEMENT SOFTWARE INC

People

Similarities

Both M. Hodgson and A. La Pape are employed as directors both by Matrix.org and by the company New Vector Limited (as well as its subsidiaries - but a common display in the Register is prevented for both by different first names:

  • NEW VECTOR LIMITED: “Matthew Hodgson“
  • THE MATRIX.ORG FOUNDATION C.I.C.: “Matthew James Hodgson“
  • NEW VECTOR LIMITED: “Amandine LE PAPE“
  • The MARTIX.ORG FOUNDATION C.I.C.: “Amandine Beatrice Marie LE PAPE“

Bad? No - but very interesting, as directors are paid and there should be some transparency also regarding connections.

The close connection is also shown by the offices of the so-called “legal entities”, which are located right next to each other in the same building (14 Turnham Green Terrace Mews):

The postal address of New Vector Limited (“10 Queen Street Place, London, United Kingdom, EC4R 1AG”) is the address of the international business law firm “King & Wood Mallesons” in London (headquartered in Hong Kong), which seems not unusual for international corporations.
OpenStreetMap: Show on map (external)

Miscellaneous

Conclusion

Despite everything:
Matrix is a very good solution for distributed work in organizations, companies or authorities! In contrast to some other team messengers like Slack, the complete source code is open and therefore verifiable - also an in-system federation is possible, which also sets Matrix apart from Mattermost, Rocket.Chat and Zulip. *

Ideal would be an even better support of the international standard (XMPP). This would allow companies/agencies to enjoy the benefits of failsafe chat rooms and team chat capabilities internally - while still allowing for standardized message exchange to/from the outside world.

For system comparison of Matrix and chat standard (XMPP): >> here <<

Matrix Logo