 I'm very happy to be able to announce you, to welcome you for our next talk, Matrix, the current status and year-to-day by Ben Parson. Thanks to the internet, the means of communication have evolved in the last year very quickly. In the last years, we started with mailboxes, some of you might remember. Then there was IOC and Jabba and now we have a whole bunch of messengers installed on our smartphones. Each of them has their own advantages and disadvantages. Today, Ben will tell us about Matrix, an open standard, and he will tell us why they saw the need for the standard and he will tell us how they implemented it. So please welcome Ben with a big round of applause. Ben, the stage is yours. Hi everybody, welcome. So I'm going to tell you about Matrix. Before we talk too much about this, I just want to get a quick show of hands. Can you tell me who has heard of Matrix before? Wow, that is probably everybody. Who has used Matrix? Yeah, it's slightly less. And who has used Matrix and they've never heard of it? Okay. So I don't think it's anybody, but in fact it's not as bizarre as it seems because the state of the bridge is today means that you could be using Matrix without knowing it. I'll talk more about that in the future. I'm going to go quite fast then over what exactly is Matrix because I think the most of you already will understand this very well. So it's an open standard for interoperable, decentralized, real-time communication. What do we mean by these things? It's interoperable. It's an open standard, which means that you can connect different parts to it. You can connect different modules. You can connect to other outside services, including proprietary services that wouldn't otherwise make it easy to do so. We do this because we're transmitting open standards. We're transmitting JSON over HTTP. It's decentralized. It's not peer-to-peer. You connect to a single server. That server connects to a federation of other servers. You don't connect to your friend server. It's real-time. It's not like email. It's a push and it's an on-demand service. We provide standard HTTP API for publishing and subscribing in real-time, which means it can be used to power instant messaging, VoIP, WebRTC signaling, IoT communication, and anything else that would have been good to transmit over JSON, over HTTP. Distributed architecture. So we've touched on this a little bit. You will only, with your client, connect to a single server at a time. These servers will then communicate between themselves. You will not connect to other servers. The advantage of this, which we'll see now, is that in a world where there's fragmentation of instant messaging, you've got many different services. They're all incompatible with each other. You've got friends on Telegram, some nerd friends on IRC, and you've got people all over the place on different services. How do you connect to them? With Matrix, because of the architecture design, a home server sends matrix messages between it, but a bridge, which can go between a home server and an outside service, with this, you can send matrix messages, and a user on the other end doesn't even need to know that there's anything happening. Very secure and privacy-focused. No single party owns your conversations. The log of all the history is shared between all participants on each participating home server. Not going to get into a lot of detail with this, but end-to-end encryption is essential in a distributed environment. What this means is that the encryption is performed on the sending client, and decryption is performed on the receiving client. No server in the process sees the unencrypted data during transit. We have a new double-ratchet implementation called OM. This was assessed in 2016, and the results are public and they're very interesting for people familiar with cryptography. End-to-end encryption presents a UX challenge. We must turn it on by default. This is the next step. We need to be able to cross-sign device keys. This means that if you have multiple devices, you have a separate key for each conversation for each device. This turns into a lot of keys, and we must improve the UX for this. This is something that we'll talk about later, and it's been improved over the last year. So I know you all know it. I'm going to go really quickly through exactly how it's used. Sending a message is really this simple. So you send a single JSON object over a REST API, and it contains the correct room ID where you'll be sending the message. Rooms are analogous to channels in IRC. And if you compare the previous slide to this, you can see that sending structured data is very easy, because the message content itself is simply a JSON object, which we will be sending over REST. That means that if you need to send fields or predefined data, you can send that over matrix with no changes to the protocol. So the server-server API, this is the mechanism by which the servers synchronize data between themselves. This is the essence of federation, really, is keeping these servers in synchronization. They can also do what we call backfill, which means that they take historical data and fill in the missing gaps in their own history logs. And they can do identity processes. Application services, very interesting. They enable bridges and other similar tools. The API is similar to the client-server API, but it has privileged access on the server. This means that you can have a user. It's like a virtual user. It's coming from another location. Maybe it's coming from Telegram, but to the matrix user, it looks like a real user. So 2018 was berserk. It was a very, very busy year for the matrix ecosystem. I hope you've been following along, but we'll go through some details now. The goals from the beginning were to finish the first version of the specification. This is what we call R0, revision 0, and it will represent a baseline for what the specification looks like. We'll talk more about this, but there's been huge progress on this this year. As part of this, getting the reference implementations to look exactly like the published specification is an essential goal, and we'll talk about that too. And then we can do a huge marketing push. Once all these things are done, we can say, yes, this is V1.0. This is a version which we think is a stable baseline, and we'd like you to start building on top of it. Many things happened. The adoption rate for this year has been tremendous. It's been larger than we expected. On a global scale, it's large. As a result, time has been spent on improving the performance of the most popular home server, which is matrix.org. And many improvements have been made to the performance there. There's no longer delays in sending messages and such. Home server hosting. This is a new product coming from New Vector, from the company behind Matrix. This is Modular. Modular is, we've been calling it Matrix as a SAS, but I wonder if that's MAS or MAS SAS. So some internal users, we have Web3 Foundation are using it as their main communications platform, and there are other people to be announced. Right now, the server size starts fairly large, so we need to make that smaller. And custom DNS is coming. Actually, migration path for existing home servers is already being tested. So that is available on Modular.am. If you are running a home server on a domain and you'd like to have somebody else host it, then this is an ideal thing. Bridges. What a topic this is. There are so many bridges. Part of the problem with the ecosystem today is that there are 100 different ways of communicating. And while this is wonderful, having some consistency is really helpful. So this is a sort of zoomed in diagram from what we saw earlier. Notice how structurally the bridge, it looks in the diagram like a home server. It pretends to be this in order to be able to communicate back to the other home servers. Node.js is a very popular stack for this. Of course, there's no reason for it to be Node.js. There's no reason it has to be Node.js, but it is the most popular baseline for the stack. So IRC. IRC is probably the most popular bridge. In terms of the users of Matrix, IRC was a hugely popular platform before. Performance issues in the past are, I'd like to say in the past, right now, IRC performance bridging to matrix.org is extremely fast. We have somebody working full-time on bridges, and a huge amount of his time has been spent this year improving this performance. Stability, no more mastery joins, and a new feature replies supported natively on the matrix side. LibPurple. So this is a brand new library, started from scratch this year, created to support protocols available through LibPurple. Of course, the number of protocols through LibPurple is itself a lot. So this enables a whole new world of bridging. Oops, hello. Discord bridge, new maintainer, many fixes for performance. Discord is, we're seeing a lot of people who want to use Matrix who are currently using Discord. We're finding that it's a major place where people are moving away from their current product. And yeah, we've seen a big uptick in usage of the bridge this year. It's now at version 0.3. Slack, Slack has been again updated, well, rewritten with a new version that uses event bridging. This is using Slack's own APIs. And if you're hosting this on riot.im, then it is a single click. It is just a case of adding your room. The bridging is instant and message passing is instantaneous. Gitter, I don't have the specifics, but huge amounts of performance improvements this year. XMPP, this is the big one of the weekend. So this is a real thing now. XMPP is being bridged live. There is a live XMP muck running at, well, you've got the address there. We have, this has been developed pretty much at the assembly where we've been sat for the last three days. And yeah, huge thanks for the XMPP folk for getting involved and giving advice on the setup of the server. And please come and chat to us if you're using XMPP and are interested in bridging this. I know that that's been a huge thing. Still more, there are many bridges. Some of the notable ones that people are getting a lot of benefit from. WhatsApp, brand new this year using their API. Mastodon bridging and still more. I'd love to list a lot more, but there are many. I recommend checking out matrix.org or coming to chat to us at the assembly. Foundation, this is a brand new community interest company set up in the UK. This is designed to separate concerns between the consultancy work which is being done by the creators of matrix and the ownership and stewardship of the matrix protocol. This was set up this year and it's still in progress in certain things. So the transfer of property and the articles of association, I think the articles of association are done or certainly progressed. International property is in the process of being transferred. I know that this was a huge topic for some people. Yeah, and I hope that it puts to rest any concerns about the conflict of interest in stewardship of the matrix protocol. Oh, specification. So this is sort of the big one. This is the elephant in the room. It takes up so much time to write a specification in public for something which is going to be used for many different use cases and implemented by people who have all kinds of ideas about how things should work. Spec progress. This was a known bottleneck for the adoption. We have a single home server. This is matrix. This is Synapse. But what we'd like to see is an ecosystem of more home servers in the same way that we experience an ecosystem of clients today. There are other home servers in production, including Dendrite, but we'd like to see more from the community. And we would think that once we have a version of this available, then we should see more. Federation API. So this is the server to server API that's expected in January, but client server API, very stable, lots of clients in use, lots of work already being done on this. Application service API. So this is for Brots and Bridges, also already ready. And I think this link will take you to the public project where we are watching all the issues related to the spec slowly move from the left of the screen to the right of the screen. As more progress gets done, it's just a terrific amount of work. And actually, this is even an old image that I haven't updated. Progress on Synapse. What time am I? Sorry. Synapse is the reference implementation of matrix. It is written in Python and it represents 99 plus percent of active home servers. It gets regular incremental performance and security improvements. And this has over the last year led to a big increase in performance on matrix.org. There's no longer problems with message sending times. It's much less resource hungry than it ever has been. And the installation and maintenance is improved. Lots of work has been done by the community in providing Docker and Ansible methodologies to install. There's never been a better time to install Synapse, even of course I would say that. It's also now available in Python 3. This is the default installation method. So yeah, that's in itself as given big improvements. Riot. Riot, I'm sure you know, Riot is the most popular client. It also serves as a reference implementation for what the client server API can do. However, the current design is not always attractive. We get a lot of complaints about the UX. In particular, people seem fixated with the problems with the colors. Apparently they're not right. This will be improved. People, yeah, so people have very strong opinions about messaging software. And one thing that we kept coming back to was people like the design of Slack. It's functional, it's simple. People like that. Yeah, let's just pay attention to what they're doing. It seems to be a good UX. So Riot will be the flagship, Riot is and will be the flagship glossy client. It will represent the most complete implementation of the client API. And other clients will be available to taste. Big progress with this redesign on the web. If you check out riot.im slash experimental or if you're deploying your own Riot, just check out the experimental branch. This is a dangerous thing to be doing on your own server, checking out an experimental branch, but this is available now and it's very stable. Looks great, looks much better, looks much more clean, much more accessible for less technical users. People who want just something that's gonna be streamlined and work and improvements on Android and iOS as well. Ooh. Yeah, UX of key signing. This is a real problem because, as we will have heard before, if you have great end-to-end encryption, that's good, but you need to be able to do that for multiple devices. Riot enables this, but if you have to move keys between devices and you're expecting people to compare long hex strings, users will eventually get used to just clicking okay to everything, which does more harm than good. We will improve the UX on this and you should look for this in Riot soon. I don't have a slide of this, but you should see the results of this research soon. Riot, brand new Android SDK. So this is gonna be written in Kotlin, no more Java. It's a re-implementation of Riot using the new SDK. Some of you may have seen the APKs floating around. I've been using it and it is super fast. It's so fast to do everything, especially syncing other projects from this year. So, new work with the French government. So, Dinsik, I took out the meaning of the abbreviation because it was a slide on its own. It's a very long phrase and I don't speak any French, but they are deploying a private federation of Matrix Home Service. What we found in terms of scaled rollout for this product is decentralized organizations, they like decentralization in their software and in their software architecture. What we find is that different departments have different ideas about how things should be configured, different ideas, different departments don't necessarily get along with each other, talk to each other. So, government and academia really get the benefit of a decentralized architecture in these times. They can have different settings for everything, even security, antivirus severity. So, they've developed their own fork of Riot. It's now available to them on iOS, Android and web. They are live and we're expecting them to roll out faster next year. Client ecosystem explosion. So, I think it's fair to say that it's been a very good year for the client ecosystem. There's been a huge number of new clients built. We've also seen feature completeness improving on a lot of different clients. So, yeah, it's fantastic how many people want to get involved and want to make new clients. In particular, you know, you get the competition between who's using QT, who's using GTK, who's using a web thing, who doesn't want to be using Electron, almost everybody. So, there's a lot of different ideas about how clients should be implemented. And as much as it's important to get the UX for Riot, right, it's also important to remember that people want their own clients. They want to be able to do their own things. So, Caternion is written in QT, looks like a QT app. However, the creator is also the creator of LibQ Matrix Client, which supports many projects, including Spectral, which is great. This is the kind of thing that an open source ecosystem can power. We take the library from a previous client and use it to power a much better looking new client. This enables the developers of Spectral to focus on things that matter to them, which is UX. And it works great. C-Glass, native Mac OS clients. So, it's really important sometimes to give people a native client for their platform. Maybe Mac OS is not the most popular for this crowd, but it's really important to have all the features available to people who want them. It's also got E2E support, which is quite early in the development process for them. Fractal, whatever the QT guys have, the GTK guys have to have. So, if you're using GNOME, then there's a GTK Rust client. Huge, fantastic community. I mean, I've said rapidly evolving strong community. It's really, really friendly. These guys, they're meeting, they're going on hackathons, they're making really fast progress. They're even having some really interesting ideas about how the future of messaging client design should be. And they're also providing a new library for end-to-end encryption, which is pure Rust. So this is going to be really helpful. They are also going to be deployed on the new Purism phone, which I gather is this year's product. Yeah, that's, if you've pre-ordered that, then you'll get a copy of Fractal running on there, and you'll have a Matrix client. GOMUX, it's always useful to have a command line application. So if you're doing logging, or even if you just want to sit and have just a command line open, for any other reason, it's super helpful to have a terminal client. I also love with Go just how easy deployment is. Just go get GOMUX, and you're running with one command. It's super helpful. Fluffy Chat. So this, again, strong communities. There's two clients for Ubuntu Touch, which is impressive for the relative size of the ecosystem. And Fluffy Chat is a great-looking and productive environment. They are in the process of implementing E2E right now as well. Still more. My goodness, there's a lot. So, GOMUX using JavaFX. Of course, there's an inevitable Emacs client, Matrix client EL. It's gonna be there. Simple Matrix, a new from-scratch client in Android. This is using no libraries from Riot. This is using purely a Matrix API wrapper written in Java. So, this is really exciting to see competition in that market. I only found out this week about Scala, which is a new web app in Elm. And yeah, and there's more. It's just the mature stuff. What else we got? Summer of Code. Google sponsored, well, Google incredible amount of sponsorship. But they sponsored two students working with the core team. One added E2E bindings for the Python SDK, which means that anything, any client side application, which is built off the back of Python, is gonna get the benefit of those once they're integrated. Another brought Dendrite back to, well, brought Dendrite back and is now on track for real software development. So, we should see Dendrite's progress in 2019. If you don't know, Dendrite is a new server written in Go. It's the next generation home server to go alongside Synapse. The GNOME project had two students working on Fractal. As I say, Fractal, just phenomenal progress in 2018. Lazy loading. Sinking initially can be difficult and it can be expensive because you're downloading a terrific amount of room state to go set up your initial state. The list of members, if it's more than a few thousand, well, that can be potentially huge. This can easily be solved. Pagination of the member list and yeah, what we've seen is an initial RAM usage in riots around 6x, which makes, it makes massive improvements for anybody using a large account. State resolution. State resolution is phenomenally complicated as a mathematical topic and I don't even pretend to get into it. However, there is a new algorithm designed to solve previous problems with this. The view of the state should be consistent across all servers. It's a simple thing to say, but it's the fundamental part of Federation which many, many projects will struggle with. If there's a fork, the state has to be resolved from two conflicting points of view. This is exactly what the new state resolution algorithms are designed to do. What's next? There's a lot been done. Most of this will still be continuing, but what else have we got? Dendrites. This is the Go server. Aggregations to be added to the spec. This will allow reactions, you know, as you see in things like, I say I don't even know, iMessage, I guess Facebook Messenger does it as well, and editable messages. So aggregations are, everything in Matrix is an ongoing list of events. Aggregations will allow you to refer back to previous events and make edits to them. Threading. So this is something, again, people want the features that Slack and other proprietary products provide. Threading can enable this. Decentralized, so nomadic identity. If you've got multiple accounts on different home servers, you need to be able to merge those. And device cross-signing, yeah, device cross-signing can't come soon enough. Oh, what's next? So, thank you. Sorry. Faster. So, now we come to the Q&A. So there was a lot of input, but we have the chance to even ask more questions for everything which is missing on the slides. If you want to ask a question, please come to our mics. I see the first people are already there. For those in the mics, two important information. A question is in generally one sentence long and has a question mark on the end. Second, if you speak into a mic, speak closely to it. Not like that. Oh, we won't hear you. Like you didn't hear me now. And for everybody who wants to leave because they have to go somewhere, please do this really, really quietly. Thank you very much. So, we'll start with microphone number two here in the middle. Hello, thanks you very much for the talk. Yeah, I have one question for the authentication to the servers. If I, yeah, choose one public server, authenticate with this. And for some reason, this server vanishes. So, I can't reach it anymore. No one can talk to me. Is there the idea that I might use a different public server and authenticate via third party? Yeah, so, I mean, this would be, this would be part of decentralized identity. What you're describing right now, it would be like you losing your email address. It would be quite fundamental. The problem that we face in order to solve this is we must first have a way of linking two matrix accounts or possibly third party IDs from other sources in a way that is reliably agreed about across the entire federation. So, it is something that is in mind. It is not something that has been specced. I should say that we have a new spec proposal process, which is something that's been developed this summer. So, I recommend that if you have ideas and a need for that particular use case, then making a new proposal, even if it's just a request for doing that, that would be the way to do it. It's in mind, but I don't think it's been specced out yet. Okay, the next question we take from the internet. Oh, yeah, there are already a lot of questions, many about the cryptography, and there's one question which is talking about bridging. So, basically, how is bridging working? For example, if you have encryption and then you have a bridge to IRC, is there any compromise? So, yeah, at any point with bridging, if you are, let's, yeah, IRC, at the point where you send out the data to be received by the IRC server, no, it would not be, yeah, within the network, it is end-to-end encrypted. Outside of that, then no. So, I hope that's clear. Next question, microphone number four. Hi, thanks for the talk. Where can we find information about the state resolution algorithm you stated earlier? So, I recommend, probably the fastest and easiest way is to go back through the blog. There has been some discussions about it on the blog. If not, we should be linking it from the docs page, but please find me, because if you can't find it on the blog on matrix.org, then we should link to it better. Awesome, thank you. Microphone number three. Hi, yeah, thank you very much. Do you plan on improving usage of proxies or especially Tor with Riot? Because at the moment, there are a lot of problems. For example, there's no UI for proxy configuration. You have to do it via parameters in the command line. And I tried on Windows. It doesn't work. It uses ClearNet. And also, Riot leaks DNS when you do VoIP calls over proxies. Do you plan on improving that? So in general, the short answer is we plan on improving a lot of the configuration of Riot, because as you say, most of it is command line switches at the very beginning. I'm sorry to say that I don't have visibility on exactly the specific features of Riot. I recommend joining the Riot Dev channel to talk about that. I'm sorry for not having more information. But in short, configuration options are something which need to get more attention. Next question from microphone number two. So this year, I've heard that the IETF has been working on the whole messaging layer security working group thing. And I've heard that the matrix team is pretty heavily involved with that. Could you speak to that at all? I'm not sure what's been done with that. It's a fun working group. They're doing a lot of federation stuff with a bunch of different messaging systems. This is related to activity problems. It's a lot of end-to-end kind of stuff. But yeah, I don't know. Sorry. I've heard matrix people are involved with it somehow. Not my knowledge. OK, come afterwards. I'm sorry for not having more information on that. OK, we have another question from the internet. Yes. One user asks, what's the best way to get into Matrix for Emacs users currently? The best way to get into Matrix for Emacs users currently is to use matrixclient.el. The Emacs community is rabid and excitable and gave me a crash course in using Emacs when I needed to figure out how their client implementation worked. So friendly guys, but rather religious. OK, microphone number two. I've been using the ERC gateway with Hackint. And I noticed the speed improvements that did seem to get much better. But Hackint is shutting down their gateway at the end of the year. And they're also saying that we should not use the main matrix gateway. And they have some, I think, three specific reasons. I wonder if it sounds from your nod, like maybe you've heard of this, maybe you could address some of their reasons of what's coming. So I don't know about the three, but the two reasons that I understood were performance in general, which I think we've spoken to. And it has improved. But I know that the frustrations that they had were very real. The other concern that they have is something which is now is beginning to be specced, but was not at the time when they had their complaints. And that relates to customizable message retention. One of the features of Matrix is that the whole history of forever is potentially stored. This is something that they were not happy about. It's a fundamental part of the specification. However, it can be changed so that we can add customizable per message or per room or per custom level retention policies. Of course, this is difficult over Federation because you have to trust what is being done on the next server. But if you are able to do that, then you can have custom retention policies. So yeah, I would love to see Hackint back bridging with Matrix. Microphone number one. You seem to be happy about having a huge... Speak a bit closer to the mic, please. You're having a big ecosystem of clients. Will it be possible for clients to implement features that only work with a specific client? Is it something you want to have or...? So yeah, this is an interesting one. So the question was we're very pleased at the number of new clients and the number of new things that are coming out. I think your point, really, is that they're all essentially chat clients. They all have that functionality. Would we be happy to see use of custom fields in order to enable different client ideas? And absolutely. So there's actually a few examples of that already. So we have people who've made blog engines built on Matrix using custom fields. People who've used... They've made slides. So you type into a matrix room and it produces a slideshow from this. Yeah, absolutely. You could do different things with different clients. It's just a view onto a room, a client. And it's simplest. So yeah, having custom fields is a big part of it. Being able to send structured data, yeah, it's half the value. So yeah. Microphone number two. Hi, thank you. How is the governance structured for the new matrix.org foundation? And how do you ensure a variety of voices in there that are not the originating team? Right. So I mean, one of the simplest ways to do this is to get people who are not in the community and are not part of the team into the governance structure. So there's a board of what they're calling Guardians. This is people who pledge to protect the spec and to keep it free of commercial interests and make sure that it's a neutral communications protocol. In terms of the specifics of the legal stuff, I strongly recommend checking out the substantial blog posts that have been posted about this because they should clarify, yeah, a lot of specific points. If you had other specifics, then maybe I could speak to it, but it's a lot of legal detail that is quite well covered, in my opinion. Microphone number three. Since I'm currently in the process of developing an iOS client, I very much would love to hear more details about how you plan to improve the encryption UX because currently that's horrible and we're struggling ourselves. Okay, yeah, it's a huge challenge. Yeah, that's great that you're developing a new iOS client. Yeah, that's really cool. I'd love to know what APIs from Apple you'll be using for that because I know that they focus a lot more on iOS than on Mac OS, which has been a problem for the C-Glass team. Yeah, so one of the things is comparing images or comparing shorter strings. The other option would be to have incremental backup of keys, but we haven't actually released any designs around that yet, so please contact me and just tell me more about your iOS client, that would be really useful. We can talk personally later. Yeah, I think so. I'll stay around. Thank you. Okay, we have time perhaps for one or two more questions, so microphone number one. Hi, thanks for your talk. We talked a lot about chatting. Do you know if there's other kind of applications running over metrics? Yeah, I mean, so there are sample bridges for all kinds of different things, including some microcontrollers. I've also built a yet to be released sort of demo for Mozilla's Internet of Things gateway. So yeah, there are different things out there. As I say, there's software for making blog posts, there's software for, you know, master don bridging is not strictly, it's not strictly chat, I suppose. So yeah, I'm not sure how many examples there are, but there's nothing stopping anybody who needs to transmit structured JSON using it for anything else. Messaging is just the most obvious thing. Thank you. Okay, time's up. I'm sorry for those who still have questions. You can just come up afterwards and perhaps talk to him in person. And yeah, let's finish this with a big round of applause for Ben.