Matrix
Matrix is primarily characterised as a chat protocol. This protocol is designed to link up existing chat solutions such as XMPP (Jabber), IRC or Mattermost.
Comparison to XMPP
XMPP has the same idea, a difference is in the protocol structure. XMPP has a base RFC, and can thus be extended using various XEPs. This makes the protocol very complex, and every server can implement different XEPs. By contrast, Matrix is comprised of a single RFC in which everything is specified. If new features are added, the base protocol itself needs to have a new RFC added.
Functionality
The protocol is built on HTTP. Each channel and each client is allocated to at least one server. For example, the server example.com has the channel foo, which, according to the corresponding naming structure, will be called “#foo:example.com“. However, this channel can be distributed through several servers, e.g. it can also be made available through “#foo:example.org“. The advantage is that a channel will remain available even if a server fails.
If a message is sent to a server, it will then be forwarded to each server on which a user has also enabled this room.
Bridges
For example, there is an IRC bridge which makes the IRC network Freenode available on Matrix.org. If the channel “#freenode_#ansible:matrix.org“ is joined, from the IRC side, it looks as if a new user is joining the channel “#ansible“. For each user and IRC server, there is a connection from the Matrix.org server. On the Matrix side, the whole thing looks like a normal Matrix channel.
There are currently various bridges available. Below is an overview of the current situation.
Identity Service
Each user has a Matrix User ID, based on the model “@user:domain“ – for example, “@bob:matrix.org“. Matrix accounts are stored on the given homeserver. The identity service exists in order to link Matrix accounts to other accounts. Currently, the only well known identity service provider is Vector.im. This feature is optional, however, since the actual accounts are located on the corresponding servers and only the links to other accounts (outside of Matrix) are stored there.
Implementations
Since Matrix is a protocol, there need to be implementations of it. Here, we can look at three components separately – the servers, the clients and the bridges.
Server
The most common server implementation is Synapse, which is implemented in Python. Synapse is made available by the protocol developers as its reference implementation.
Bridges
There is already a bridge in all different types of networks. Probably the most common is IRC, of which there are already several products. The list of supported networks is already long. Bridges can be operated to XMPP, Mattermost, Slack or GitHub, among others.
Integrating the bridges is very simple with the web interface riot.im. Activating a new bot goes roughly like this: a new channel is created, and the bot is then added to it. To do this, we use the menu item “Manage Integrations” in the room settings. These bridges are made available by Riot, but the selection is limited. If other bots and bridges have to be added, or, for example, if an IRC network is not available, the corresponding bot itself or the corresponding bridge itself must be made available.
Clients
There are already numerous clients. Synapse features a small web interface. One of the most common interfaces is Riot, which is available as a web application, Android app and iPhone app. Riot is purely a web application which accesses the API of Matrix. It does not have its own database or persistent data in the background.
Another client is WeeChat, for which a plugin exists. This is of interest to anyone who would like to serve a client in the console.
Findings
Matrix makes it easy to access the various existing protocols through a single protocol. Another nice-to-have is the ability to choose your own client.
Various implementations are still in the alpha to beta phases. This severely limits the selection of individual components.
The protocol only knows a reduced set of HTTP headers. For example, the server name indicator (SNI) is not implemented, which means that Matrix can only be operated behind a reverse proxy under certain circumstances.
