DO_BYTE 2026 - Was ist Matrix?

Yes, good day. Today I'm going to tell you a little bit about what The Matrix is. I'm delighted that so many people came . Exactly . My agenda today is to give you a little introduction . Why am I standing here? Then the question becomes: what exactly is Matrix ? Next, I will introduce you to possible servers and clients. Next, I'll discuss additional components that you can install, and then I'll address problems and my own experiences . This entire presentation has a focus that leans more towards self-hosting, how to run your own Matrix server, but I will also begin by explaining what that is. Okay, so let's start with what Matrix is. I took a look at the website , matrix.org, and there it says: "An open network for secure decentralized communication". Let's break this down somehow. Let 's start with communication. It's kind of a chat log. It is not technically a chat log, but for all intents and purposes and this presentation, it is a chat log. Okay, so we'll communicate via chat. Decentralized. Decentralized is kind of okay; we communicate between multiple servers. We do n't have a central server, no central server that says, " I am the authority here, I decide which messages are in the chat." Instead, we have decentralized servers, like with email, for example. Each server is its own master of the data. Exactly, secure. We offer end-to-end encryption support. This means all your chat messages can be encrypted. More on that later. And open, it's an open standard. OK. Now we need a few more basics, such as the Matrix ID. I already mentioned it in a way, it 's a bit like email. With email, we're familiar with a kind of local part, so something like your name, then an @ symbol, and then something like your provider, where the server is located. It's similar to Matrix; we have a Local Part, which is the username, and then we have a colon and then the server where the data is located. So, while a chat room (more on that later) is not located on a fixed server, your account is always located on a fixed server, like with email. Exactly, I somehow pressed the blackout button. Exactly, the username is freely selectable and the home server is the domain of the server on which the data is located. So, for example, if you create an account on a Matrix server at fachschaften.org, it will say " fachschaften.org" followed by a colon. This is also so that other servers can figure out where the messages actually need to go . That means you somehow added your username followed by a colon to the server. And that would be @arkul:fachschaften.org, for example. Um, okay, now we've been talking about the server. What exactly is a home server? A home server is, first and foremost, a server, server software that runs somewhere on your computer. Accounts are stored there, chats are stored there. I may mix up chats and rooms in the following section; these two terms are used interchangeably. In The Matrix, everything is always a room, a chat is also a room, so I will use them somewhat equivalently , even if they are not technically completely equivalent terms, and that's where the media lies. This means your home server knows which chats you are in, and your home server has all media stored locally. When a new message comes in, it will be saved to your home server and everything will be temporarily stored there. Your client, on the other hand—oh, I promised not to use a laser pointer— simply sits at the bottom and connects to your home server, then retrieves the current state. Exactly . As I've already mentioned, the whole thing is similar to an email server. We keep all accounts encrypted with each other, and each institution or person can operate their own server . So, now we have one server, now we want multiple servers to be able to communicate with each other . This is federation. Um, here every server knows all the information about all the rooms, because every server knows the rooms you are in and only servers talk to each other, where there is always at least one person in the room, every server knows all the information about the rooms. This is also a bit of a difference to other approaches to federated systems, federated chats, in that there is no server that essentially owns the room, but rather each room is duplicated on each home server. I pressed the wrong button again . Um, so now, if a change happens somehow, that is, a new message is sent, then um, there is the server, so to speak, where the user who caused it is located, and that is then distributed to all other servers where the rooms are located. Of course, there are also things you could go into detail about for an hour, like protocols that sync things retrospectively, if a server was offline or something like that. Yes . Exactly, and then the conclusion: No central server per room. Exactly, then somehow, how does that come about, who else is behind it? There is the Matrix Foundation, which is funded by donations and maintains this specification. The specification is partly developed by other companies and also by the community, but there is the Matrix Foundation, which ultimately takes care of it. It also operates a public Matrix server, matrix.org. And it is governed by a Governing Board, and the Governing Board is elected annually. Then there's Element, Element is somehow the company or its commercial enterprise, initially from Great Britain, and they co- developed the Matrix specification at the beginning; that's where the money came from, at least initially, and they still contribute a fair amount to the Matrix specification. They also develop the most widely used server (we'll look at the different types of servers and the most widely used client in a moment). Okay, now that I've introduced the basic concepts, the question is, why do we actually want to do this ? Why do we want to use Matrix? Um, point one, it's kind of an open standard, as we just mentioned, it's maintained by the Matrix Foundation, there are clearly defined processes, these are Matrix backproposals, for how to change the protocol, how to add new things , how things might be deprecated, the community can contribute, so if you don't like something, you can simply write a Matrix backproposal and suggest changing it. And you can build your own server and client implementations. Of course, this is quite a large protocol by now, so building your own server or client implementation takes some effort, but it is theoretically possible; nobody is stopping you, unlike with other commercial providers where you are not allowed to do so. We've already mentioned the existence of a federation, which is also one of the advantages of The Matrix. We have enabled communication between accounts on different servers. Nobody is permanently tied to any one server, and therefore no server has complete control over the network. Ultimately, if one server is shut down, it initially has no effect on other servers, and they can continue to communicate. For example, there's the really funny story that matrix.org, the biggest server, was down for a few hours last year. I think it was more like a day like this . And then, of course, one could see who was on matrix.org, because one could no longer reach those people , but in one's own cozy little Federation world, everything continued to federate nicely. And each server can manage its own users . This also means that if you set up a Matrix server for a hackspace , for example, you can simply go there and somehow attach your OIDC, your SSO to it and can directly take over your accounts. Furthermore, it is encrypted. This means that all message content can be encrypted. You can choose that. In an open chat, it always depends; you might not want to encrypt because then old messages are even easier to see, and things like that. And it's more of an open chat with an open login. But in a private chat, I might want to encrypt. I've just used the cash audit chat from a year ago as an example. That might be sensitive information. I might even want to prevent my server operator from reading them. And then I just click on encryption. Furthermore, for communication between multiple individuals, it always makes sense to turn on encryption, simply because why not? Exactly, users can verify each other . I think that has faded a bit more into the background in recent years. That 's also what somehow acts as a signal or something, I don't know, but it kind of hides you. This means you can somehow go to another person and say, okay, let's compare emojis here, and then you know afterwards that it is cryptographically ensured that only this other person can see it. And then no one has wedged themselves in the middle, so to speak. And that, in my view, is a great advantage. At least until a few months ago, Signal was opposed, but many still seem to be opposed to encrypted services that allow the use of multiple devices simultaneously . I don't have a main device that everything is somehow connected to . Ultimately, I can connect an unlimited number of devices to my account and communicate with all of them simultaneously, without having to regularly charge my phone or anything like that. OK. Now I'm sure I've convinced you all that you want to try out Matrix . Now let's talk a little bit about how that actually works. There are multiple servers. That's a synapse. This is the server that is being developed by Element, and is also being operated and sold commercially. There is now a Pro version of it. Um. But the community version is perfectly adequate for pretty much everything, unless you have a server with thousands or tens of thousands of users . Then there is Conduit. Conduit is a small, self-developed project in Rust that someone created. And then there are various forks of it, and Continuvity is also worth mentioning. It's basically a fork of a fork and at the end of Conduit. Um. Exactly, and those are the small servers that are poorer in terms of resources. It's also kind of cool to have different servers in the ecosystem, and not just one. But they might also potentially have more bugs and fewer features. Exactly, the ecosystem somehow seems larger when it comes to clients. That means we have Element, which is the client distributed by Element. It's currently somewhat recommendable on desktop operating systems because it works and has the features. Then there is Element X, which is the new development for mobile devices, i.e., iOS and Android. There 's also some kind of new thinking protocol in there now, and then there's FluffyChat. FluffyChat is also a client that originated from the community and is primarily intended for mobile devices. Theoretically, it also works on the web and under Linux. Then there's Neko. Neko is a community- developed application for Windows, macOS and Linux. Cinny took some inspiration from Discord in terms of layout. And it's also available for Windows, macOS, Linux and Web. And Sable is a Cinny fork and has somehow incorporated a few more features. And lastly, you can also use Matrix in Thunderbird. Thunderbird allows you to set up a Matrix account and connect to it. You should n't do that. It's a truly terrible experience. Do n't do it, it will potentially break your account , but it is possible. OK. Exactly, let's go through in more detail the things I just skimmed over , the things I wrote down beforehand. There is Synapse, which is the most widely used server implementation, at least for now. It's also relatively mature, actually stable, and you can easily implement a single sign-on with it, so if you're running some kind of hackspace infrastructure or something like that, as mentioned above, then you'd probably want to use Synapse. And Synapse supports Element X, which I believe the other smaller servers also support by now. Not when I first gave this lecture . Um. Then on to clients. There is Element Desktop, which is a desktop client, obviously. But you can also use it on the web. It has this layout. Um. Exactly, you can see a chat there, you can see information about the chat, you can see a chat list. Um. One could delve even deeper into that. It supports Spaces, for example, which is what's called a server on Discord . Um. Um, or at least a counterpart to that, um, where you can also group your chats . Exactly . Element X is the mobile version, which is new. Um, and it looks like a chat client. Um, I don't know what else I can really say about that. Um, there's a list of rooms, um, chats, which you can filter by private, for example, individual or group chats. Then you can tap on a chat and then you can write messages. Um, great, it 's a chat client. So, you've set up Synapse or something similar, and now you want a little more. Now you want to use some more cool features. Then, um , there is the, uh, exactly, I'll show it to you this way now. So, there is Matrix Authentication Service. Uh, it's kind of an add-on for Synapse, but theoretically other servers could also use it, server software. Uh, it manages all the accounts located on the server and the devices logged into those accounts. This is linked to single sign-on systems. If you want to implement Single Sign-On with Synapse, there are practically no other options available anymore. Uh, and it enables QR code login, so you can say on your phone, okay, I want to scan a QR code, and on your computer I say, I want to connect a device, and then it scans it, like you might know from Signal or similar services. This is a separate piece of software that allows OIDC to communicate with Synapse; it's essentially an OIDC that can be placed alongside it, because theoretically it's designed so that other server software could also be connected to it. Then the topic of moderation always somehow comes up . Especially if you're running a server where not only you are on it, but other people are too, you might want to moderate chats. There are public chat rooms, the Hackspace chat, whatever . Um, and then it receives spam reports from users. Spam reports are currently only reported to the server administrator. And now I want to somehow ban people from servers . For that, there's Traubenier, which is also kind of a bot that you simply place next to it. He then simply opens a chat with you , sends a message, okay, a new spam report has come in. Then you press ban and he bans you once in all the chats where he is supposed to ban. Additionally, there are also community lists, meaning you can, for example, subscribe to Community Moderation Effort in this bot and then say, okay, if trusted community members go here and say that the user should be banned, then he will automatically be banned from all my chats and I don't have to do the work myself, or rather, he ca n't join me there. So, you've somehow set up a Synapse, want to manage it, and perhaps have many users who are in many rooms. There's Kitsune, which is a Synapse Admin fork. Element Admin is now also available, but it can do a bit more. I can easily administer it there; I have a list of rooms, a list of users, and a list of uploaded media. In case of doubt, I can simply deactivate a user, delete user rooms, and similar things. I also see information about the Federation. We've already touched on the fact that there's federation, you know how it is with email, that something might break or get lost, that's also a problem with Matrix. But then I see, for example, that okay, I've already federated with this chat, with these servers, and I last sent a message to this server, and maybe that didn't work, so I try it again and again . If you have a feeling that messages aren't arriving right now, you can always check it and see, ah, okay, the server actually does n't have a connection right now, and then take the next step into the log and see what the reason is. Mostly when you've broken your own internet connection . Then there's Element Call, which is similar to what you might expect from traditional chat apps – the ability to make calls , which was previously implemented via Jitsi . The newer variant is Element Call. This then works directly in Matrix and uses WebRTC. This is also encrypted. Which is somehow an advantage over Jitsi. And it can be used in the browser, in Element Desktop, and in Element X. However, to use it, in addition to your Synapse, you also need a separate Element Call Server, which handles all the call-related tasks. Then you might have the problem, which XKCD illustrates a bit, that you have many groups of people using different chat services, and now you go and say, yes, Matrix is ​​great, I'll do that now, and then you have yet another chat service. Perhaps only another group of people deserve to use it. For this purpose, there are Bridges, which are essentially small pieces of software that you place next to your server, and the Bridges then transfer chat messages, e.g. from WhatsApp, into your Matrix, essentially impersonating a local Matrix account. So that in Matrix it actually looks like you're having a real chat with this person. And the person who is somehow messaging you on WhatsApp wo n't see this either, because they are messaging normally with your WhatsApp account. Exactly, it's available for Discord, Slack, Signal, WhatsApp, Zulip and many other services. They are almost all community maintained, though of course with varying quality and different amounts of time that people put into them. And I've somehow, I don't even know, been productive with WhatsApp Bridge for six or seven years now , and it's definitely improved. And you practically don't need to use WhatsApp for that. And you can still reach the people who only write to you on WhatsApp . Then we briefly talked about federation . Now, of course, I want to test it somehow; I've set up my server, have I configured it correctly? There are instructions, which I can of course follow, but in the end I want to see, okay, it works. For that, there's the Matrix Federation Tester, or rather, several of them these days. This is now the one under federationtester.mtnord.blog. I enter my server domain, press test, and then it tells me green, federation works, or red, it does n't work, something is wrong here. This also works with all server software, including Conduit, Continuity, Synapse, and whatever else is out there. Okay, last but not least, Matrix Docker Ansible Deploy. I just mentioned a lot of services; we need to install them somehow. Um, the way to do this, at least somewhat on the community side, is Matrix Docker Ansible Deploy. I do n't know if any of you have ever used Ansible before. Anyway, it's such a big Ansible playbook with a whole lot of stuff, but in the end I have a config file and I say okay, I'd like Synapse or I'd like Continuity, I'd like to have Element Co next to it , I'd like to have Matrix Authentication Service next to it, I just say true true true, I might have to configure one or two secrets, but it also automatically deploys a database for me, it automatically deploys a reverse proxy, takes care of SSL and then it runs once and it just works and then I can run it again every now and then and then exactly. Will it be updated? This can also work with different bridges; for example, I now simply operate the WhatsApp Bridge by saying, "Okay, create a WhatsApp Bridge for me," and then it does that . Exactly, the alternative is, if you already have a Kubernetes cluster lying around, Element now also offers a Helm package, but it does n't handle things like bridges and such for you, and you can of course install all of that manually. There are Debian packages for Synapse, for example, and there are things for Synapse in Pip, and the bridges are usually Go binaries or something similar. But that becomes quite a lot to manage when deploying something larger, and that's where this tool comes in, which essentially does it all for you. Exactly, I've just told you how expensive all of this is, why you want it, and what you want. Now we'll briefly touch on some problems, especially problems that are mentioned more frequently. That includes, firstly, the ability to find rooms. This is particularly relevant if you are running a public server or if you want to find rooms. There is a central room register once per server, which means that when you are on the server you can see, okay, the server recommends the following rooms for me to join. If the server allows it, you can also check what another server recommends, joining rooms from room to room, but this is always a very manual process that you then have to do on a small scale . Then there are Spaces. Exactly, I already mentioned that it's kind of the equivalent of Discord servers. Ultimately, it's just a room containing a list of rooms, where I can then say, okay, you just need to join this one and then you'll see all the available chats. But of course, I still have to somehow get that to the people. So, the least painful solution right now is either to have automatic invitations. We experienced that ourselves here at Dub IT, for example. This means that if you bought a breakfast ticket, you were asked for your Matrix ID. You could enter your details there and then you were automatically invited to a room. Especially if you're running this on an institutional level, I don't know, in a hackspace for example , you can of course say, okay, all users should be invited to the main hackspace room. Alternatively, as we do in the student council, for example, we simply have a page with lots of links, and then you click on the link and then you can join the room. This isn't exactly the most elegant solution, but from my point of view, other services also have this problem. Then encryption problems. I think that's the first thing you notice when you read up on things about The Matrix on the internet. Lots of "Could not decrypt message". It's really not as bad as some people suggest anymore . It used to be much more broken. A lot of engineering work has gone into making sure that this is no longer the case. It still breaks down from time to time , especially due to fundamental reasons, for example, if a server is offline, then it ca n't send me the encryption data, um, and things like that. Exactly, then the bigger problem from my point of view is that metadata is not encrypted. This means that, in particular, the information, uh, which rooms exist, the description in the rooms, the titles of the rooms, the pictures of the rooms, um, and who is in this room , will not be encrypted. They are simply stored on the server . Um, the conclusion is basically this: just run your own server, then you are in control of this data and then you don't have to worry so much that it is not encrypted. But of course, running your own server is always a good thing in such a federated system. Uh, that increases the federation, uh, that somehow makes the network bigger, that's great. Exactly, and last but not least, uh, UI and UX. As I just showed you, the UI isn't always completely suitable for normal users. Element X is starting to do a really good job; it's easy to use. Otherwise, depending on the client, especially if you're running this in a larger institution, perhaps at work , you'll need some kind of guide that says, okay, um, you'll set up your encryption using the following steps . And yes, the key where you are told to please save the recovery key safely, please save the recovery key safely. Exactly . Um, if in doubt, if you're doing this for a larger number of people, maybe at work, write instructions and help with problems, then it will work. Oh, that wasn't the last problem at all. The last problem, changing the home server, um, exactly. As I mentioned at the beginning , an account is always tied to a home server, um, and cannot be moved. However, there are tools available to automatically move the chats. It's all a bit hacky, not very nice, so you should either find a server you want to stay on or set up your own. I've had to switch home servers twice, and both times it was a bit of a hassle. Exactly, then we'll go into a little more detail , um, perhaps adding this a little later, what actually entitles me to give this talk . Um, exactly. At fachschaften.org, um, that is a project of the KIF e.V. located at the computer science student association of TU Dortmund. Um, we host two Matrix servers for students in the attic. Um, exactly, we now have, this is the statistic, about 400-500 monthly active users. Um, exactly, one is fachschaften.org, um, and the other is KIFrocks, which is uh the one for the conference of computer science student associations. And then I just took a look and saw how much power we actually need right now. This is, mind you, without a database; this is just Synapse. Um, and the data is a bit older, but it's probably still accurate. Uh, we have some kind of VM with eight cores and six gigabytes of RAM. And then you see, we need just about four and a half gigabytes of RAM and about 25% CPU usage, um, but that's already a server where, as I said, there are quite a lot of users and we also have some power users who are in the really big chat rooms, um, with thousands of users, where there's a lot of federation traffic. Um, at home I have a VM with two cores and four gigabytes of RAM with Synapse in it, and it works great. No problem at all. Um, well, you can get by reasonably well with that, and you can also run a Synapse with a reasonable hardware size. Um, otherwise there's Conduit and Continuity, which are both written in Rust and therefore probably much better. Exactly . Bridges, which I just mentioned and praised so highly, um , but in our experience they are more suitable for smaller deployments. Uh, we used to have a Telegram bridge, but that was with the old software; there's a new one now, and we simply had to shut it down after rebuilding it several times because it kept running into bugs. Um, so please do something for home usage; the same Telegram Bridge works great as long as one person is logged in. That's also kind of the case where it's being tested. Um, my WhatsApp Bridge, as I said, has been running for about six years now. It is, it is great. Um, but don't make it for tall people. It's better not to say, "Okay, we have Telegram here, so we're going to do Matrix and bridge all the chats over." This leads to terrible UX on both sides, and it also results in the admin people ending up crying. The admin person in the audience nods. Exactly, so to summarize, Matrix is ​​a federated chat protocol. This means the servers send messages to each other. You don't have a dedicated server. A room does n't have a dedicated server, but your user does. Um, it allows encrypted communication between accounts on two servers or on the same server, obviously. Um, there's something kind of cool about it. Uh, individual configurations, um, through various extensions and different servers. Uh, video calls are now also supported. Exactly, and then the question would be, do you have any further questions? Yes, very cool presentation, thank you. Are the video calls also end-to-end encrypted? Perfect, okay. Basically, I want to encrypt all traffic that passes through it end-to-end. So, if it's an element of a call space, it's ultimately just a matrix space. That means I assume that the room's metadata is also not encrypted. Um, but the video and audio traffic is encrypted. OK. That 's my current understanding. Would you like to elaborate on that? That cannot be said definitively; there are different revisions of the protocol. I believe that in the version that should eventually become stable, at least enough metadata would be encrypted that it would n't be clear that you even started a call, but perhaps negligible in this respect. If there are no further questions, thank you for listening and I hope you have a lot of fun at Do What.