A Matrix overview

At this year's (virtual) Open Source Summit Europe, Oleg Fiksel gave an overview talk on the Matrix decentralized, secure communication network project. Matrix has been seeing increasing adoption recently, he said, including by governments (beyond France, which we already reported on in an article on a FOSDEM 2019 talk) and other organizations. It also aims to bridge all of the different chat mechanisms that people are using in order to provide a unified interface for all of them.

Fiksel is a former security consultant and a longtime member of the Matrix project. His opening slide (slides [PDF]) was an altered version of the xkcd "Why SMS refuses to die" Venn diagram, with "Matrix!" placed at the intersection of the three sets and "How we view the future :)" as the caption. It ably captured one of the main thrusts of his talk and can be seen in the screen shot below.

He began by talking about all of the different chat networks that exist, which, for the most part, are isolated from each other. One idea behind Matrix is to unite all of these networks, but that does not mean that it is just a giant bridge. Matrix is a network in its own right as well. The "difference is that Matrix is friendly to other networks", he said.

He put up a sentence that describes Matrix well: "Matrix is an open network for secure, decentralised real-time communication." It is open in the sense of having an open specification and open implementation. "Secure" means that it has end-to-end encryption by default; it is decentralized because "anyone can run their own Matrix server". These days, real-time communication generally refers to chat rooms, he said, but Matrix can be used for other types of communication, such as for the Internet of Things (IoT).

Key features

Fiksel then listed some of the key features of Matrix from his perspective. The open specification for its protocols along with an open reference implementation means that anyone can write their own server or client—and many have done so. In addition, Matrix has a distributed, federated architecture, which means that messages are not stored in a single central location or owned by a single party. The messages are spread throughout the network and each server owner can decide which other servers to connect with and federate their data with.

From an architectural point of view, it is important that Matrix was built with end-to-end encryption from the ground up, rather than bolting it on later. It also allows Matrix to support encrypted voice and video calls using WebRTC.

The "most unique feature of Matrix" for him is its ability to provide bridges that break the boundaries between networks. That means users do not have to install lots of different clients in order to connect with people on all of the disparate networks. There are also integration widgets to combine Matrix with other tools (e.g. Etherpad).

Last, but not least, he said, the project has a "healthy and friendly community", which is "very important" to him.

Encryption details

In his opinion, any encryption that is not implemented as open-source software is questionable. With closed-source encryption, you have to trust the word of a company or project that they are encrypting the data, but with Matrix you can study the code that implements it.

Encryption is such an important foundation for Matrix that the project took a lot of time to build that support in. It took "much more time" to build the user interface for the encryption, he said; the project looked at all of the different use cases so that it could make the encryption easy to use. Those who are working on encryption should take note that building the crypto code is one thing, but "making it usable for people and easy to use is a bit of a different job".

The Matrix end-to-end encryption implementation has been used for around three years at this point. There are two libraries, Olm, which is based on the cryptographic "double ratchet" specified by the Signal secure-messaging application project, and Megolm, which is a different ratchet used for group messaging. A review of the cryptography in Olm and Megolm was done in 2016. A few problems were found and fixed at that time; Fiksel encouraged security experts to review the code and provide feedback as well.

Architecture

He then described the architecture for Matrix. It starts with users that have clients that talk to a home server using a client-server API. These users will have accounts on one or more home servers. The home servers talk with other home servers to exchange messages using a server-server API. There are also identity servers that can either be centralized (e.g. at matrix.org) or run by various groups to, say, federate with a company's existing identity server. Discovery of home and identity servers is done using DNS records; home servers can also be discovered using a well-known URI scheme.

Application servers are another entity in Matrix; they connect to home servers using an application service API. These servers have more privileges than the clients have. They are mostly used for bridges or integration managers.

Home servers use the server-server API to synchronize messages and room state between them. The API can also be used to request older messages so that a server that has been offline for a day or two can catch up on ongoing conversations. Servers can query for the profiles and status of users on other servers as well.

Multiple home server implementations are available, starting with Synapse, which is the reference implementation written in Python using the Twisted networking framework. Synapse is stable and is used on matrix.org. Dendrite is a Go implementation that is now in beta; it is aimed at being highly performant and scalable. Conduit is written in Rust; it is in an alpha state and lacks federation support, but it is "blazingly fast". A C++ server, Construct, is also performance-oriented. There are others, which are listed in the Matrix directory of tools.

The client-server API was developed to be "as user-friendly as possible", Fiksel said, which makes it easy to create a client. For example, you can use curl to send a message to a room from the command line. There are also "fancy clients", including Element, which is the reference client. Element implements all of the different features that Matrix has and is available as a web application, a desktop application using Electron, and for mobile devices using Android or iOS. Other clients for desktops and mobile devices exist, with different feature sets and maturity levels, which are listed in the directory as well. Terminal-based clients are available for those who prefer that kind of interaction.

An application service has privileged access to its home server, which it needs to transport messages from one network to another if it is performing a bridging function, for example. It can subscribe to server traffic to get access to the events that are occurring in the chat rooms. It also needs to be able to act as a virtual user that will make users on other networks seamlessly appear in a Matrix chat. Users on, say, Telegram or WhatsApp, will appear just like any other Matrix user, he said.

Application services can be used for integrations with other tools. For example, an Etherpad can be added to a chat room by using an integration; users in the room will all be able to see and interact with the Etherpad. There are bots of various kinds that are implemented as integrations; for example, a bot could monitor an RSS feed and post new messages to the room. Another example would be a room for a group that is monitoring a set of servers; it could have Grafana graphs displayed for all participants to discuss. Integration with Jitsi video-conferencing is also possible. Custom integrations can be written as well, of course.

Bridges are application services that sit between a home server and another chat network. On one side they use whatever API is required for the other network, while they use the application services and client-server APIs to the home server. There are two types of bridges: puppeted and bridgebot. A puppeted bridge will present its Matrix messages as native messages in the other network and vice versa. This provides a seamless experience on both sides, so that Telegram users, for example, cannot distinguish Matrix users from other, actual Telegram users.

For various reasons it may not be possible to have a puppeted bridge for a particular network. For example, the network may not support it or the user may not have an account on the other network. In those cases, the system can fall back to a bridgebot type of bridge, which means that a single bot user relays the traffic. To a user of the other network, the messages will all come from a single bridge user, though individual messages in the chat will be separated and prefaced with the Matrix user's name. It would seem to be a kind of clunky way to work around restrictions in some "walled garden" chat networks.

Adoption of Matrix has been growing rapidly over the last few years, he said. Beyond the adoption by the French government, there are three other governments that are running pilot studies. Multiple open-source communities have adopted it, with Mozilla being the most prominent. Lots of universities and virtual conferences are using it; there are also many official Matrix channels for various projects that are available to clients from matrix.org.

Getting started

Fiksel presented some steps to get up and running on Matrix. The first is to choose a home server. There are various lists of public home servers or you can use Element with an account at matrix.org. Using matrix.org should probably be a last resort, he said, as it is fairly overloaded at this point. You can pay to host a home server at a specialized Matrix provider or, of course, host a server yourself; there are guides, an Ansible playbook, as well other efforts to automate the process using Kubernetes Helm charts.

Next up is to choose a client from a list of Matrix clients and connect it to the home server. As he did several times in the talk, he strongly encouraged attendees to get involved with the project. He also noted that Matrix and the Gitter chat network have announced that they are joining forces, which further expands the Matrix community. As mentioned, that community is welcoming and friendly, so interested folks should get involved.

Fiksel spent the last part of his talk on an extended pre-recorded demonstration of some of the bridging features in Matrix. He used the Ansible playbook to deploy a home server, then connected to it using Element and the terminal-based gomuks client. He showed bridging Matrix to both Telegram and IRC, with messages flowing in both directions. For those who find themselves with too many different chat clients, Matrix seems like it could be a welcome alternative. In addition, a decentralized end-to-end encrypted communication system that is not under the thumb of some corporation or other organization has some attractions of its own.