👥 9 conferences
🎤 16 talks
📅 Years active: 2015 to 2023
📊 Wikidata: Q115934150
Matthew is project lead for Matrix (https://matrix.org): an open protocol for secure, decentralised communication - defining an end-to-end-encrypted real-time communication layer for the open Web suitable for instant messaging, VoIP, microblogging, forums and more. Matthew splits his time between The Matrix.org Foundation non-profit, and his dayjob at CEO/CTO of Element, the startup created to fund development for Matrix.
9 known conferences
Matrix is an open standard for secure, decentralised communication, which may be familiar from powering the online editions of FOSDEM in 2021 and 2022 (and hybrid-FOSDEM this year!).
In this talk we will explain the fundamental changes which are landing in Matrix 2.0, which speeds up Matrix to be at least as snappy as the fastest proprietary messaging apps - all while handling thousands of rooms spanning millions of users.
During 2022 we've been on a mission to completely rework the slowest bits of Matrix, aiming that nobody can ever complain about Matrix being sluggish again. In practice this means fundamental changes in:
how Matrix syncs data - "sliding sync", where servers only sync the bare minimum data to clients required to render the UI, providing instant login and instant sync (MSC3575)
how room joins work over federation - "faster joins", where servers only sync the bare minimum data such that clients can start participating in the room as soon as possible (MSC3902)
how auth works - switching Matrix to use OIDC natively for all authentication, registration and account management (MSC3861)
how VoIP works - switching Matrix to natively support multiparty decentralised E2EE VoIP as the primary calling mechanism (MSC3401 and MSC3898)
The end result is transformational, and by far the biggest change to Matrix since the project began in 2014. So, we're calling it Matrix 2.0, and this talk will give a guided tour of everything that's changed - and show off the new reference matrix-rust-sdk client SDK, which powers the new flagship mobile Matrix client, codenamed Element X.
A short introduction to the Matrix Devroom by Matrix Foundation co-founder Matthew Hodgson.
This slot was freed when the talk "Load Testing Matrix Homeservers" was cancelled.
The Matrix core team is busier than ever, juggling hundreds of Matrix Spec Core Proposals and undergoing some major techtonic shifts as Matrix evolves into the ultimate secure decentralised communication network. In this talk, we'll give a high-level survey of the state of the core project, including: * How we're ensuring that flagship clients are as attractive as possible to a mainstream audience - and why we will fail if we don't. * How we're making Matrix go fast via v3 sync and fast room joins * How matrix-rust-sdk is becoming a flagship client SDK * How we're getting a full end-to-end security of the reference Matrix stack * How we're tackling abuse on the public Matrix network * How Matrix is evolving to use cases beyond chat.
Matrix (https://matrix.org) is an open protocol for secure, decentralised communication - defining an end-to-end-encrypted real-time communication layer for the open Web suitable for instant messaging, VoIP, microblogging, forums and more. We provide the open standard and open source tools to democratise communication away from the proprietary closed communication silos (Slack, Discord, Telegram, WhatsApp etc) that currently dominate.
In this talk, we'll explain all the features we've been adding to let Matrix scale to support massive virtual communities such as FOSDEM itself, Mozilla, KDE and others. This includes Spaces: the ability to group rooms into a hierarchy, for ease of discovery and management; Widgets: the ability to add arbitrary webapps to chatrooms to provide dashboards of additional functionality (e.g. the FOSDEM livestreams and video conferences); Threading: the ability (at last!) to support threaded conversations in Matrix; and Decentralised Reputation - the ability to empower users to tune out content they dislike on their own terms. Our goal is to ensure no open source project ever uses Slack/Discord/Telegram to collaborate ever again. Finally, we'll give a quick tour of the FOSDEM-specific work we've done in order to run FOSDEM 2021 on Matrix!
Matrix has always been built to support large virtual communities - after all, Matrix itself and all its dependent projects are developed via Matrix. Over the last year this has expanded further, with Mozilla joining Matrix in March 2020, Gitter joining in October - and meanwhile a huge influx of large virtual events and educational and public-sector deployments driven by the COVID-19 pandemic. As a result, lots of our work in 2020 has been focused on improving features for navigating and managing large virtual communities, whether that's improving the user experience in Element, or adding entirely new features to the protocol. We'll give a tour of what we've been doing, and how we deployed it for FOSDEM. We'll also show off our brand new Spaces implementation (the ability to group rooms into a hierarchy).
Spaces are particularly interesting because they open up the possibility of Matrix being more than just a big flat namespace of conversations: instead they provide a global fully decentralised hierarchical filesystem, complete with decentralised ACLs, allowing users to publish and curate an arbitrary taxonomy of whatever data they choose (be it real-time conversations, history, data streams, files, objects, etc). This has potential to flip Matrix entirely on its head: Spaces could become the main backbone of the protocol, with chatrooms being mere leaf nodes in a giant tree of collaboration. Imagine if NNTP, AFS, IRC and the Web had a baby :D We'll dig into these ideas and more, and their implications for large-scale decentralised open source collaboration in years to come!
Matrix is an open protocol and open network for decentralised real-time communication; shifting control over communication from the big proprietary silos back to the general population of the Internet. In 2016 we added E2E Encryption based on the Double Ratchet, and since then have been working away on getting the encryption so polished that we can transparently turn it on by default everywhere. In this talk, we'll show how we have finally done this, what the blockers were, and then try to smash the encryption to pieces to illustrate the potential attacks and how we mitigate them.
Matrix is an ambitious project to build a open decentralised real-time communication network; providing an open standard protocol and open source reference implementations, letting anyone and everyone spin up a Matrix server and retake control of their real-time communication. Matrix is looked after by the non-profit Matrix.org Foundation, and as of Oct 2019 we have over 11.5M addressable users and around 40K servers on the public network.
Over the course of 2019 we spent a huge amount of time finalising Matrix's end-to-end encryption so we could finally turn it on by default without compromising any of the behaviour users had grown accustomed to in non-encrypted rooms. Specifically, the main remaining blockers were:
Ability to search in E2E encrypted rooms (now solved by Seshat: a Rust-based full-text-search engine embedded into Matrix clients)
Ability to get compatibility with non-E2E clients, bots and bridges (now solved by pantalaimon: a daemon which offloads E2E encryption)
Reworking the whole encryption UI to expose cross-signing to radically simplify key verification (including QR-code scanning for simplicity)
Ability to receive notifications in E2E encrypted rooms.
However, we have finally got there, and this talk will demonstrate how the final E2EE implementation works; the final problems we had to solve; the threat model we have implemented; and how we're doing on rolling it out across the whole network. More interestingly, we will then demonstrate a variety of attacks against the encryption (e.g. shoulder-surfing QR codes during device verification; MITMing TLS; acting as a malicious server implementation; global passive adversary) to demonstrate how well we handle them.
Matrix is an open source project run by the non-profit Matrix.org Foundation dedicated to building an open protocol and communication network for decentralised, encrypted communication - providing a viable open alternative to WhatsApp, Slack, Discord an other proprietary communication silos. In this talk we will show of the work we've been doing over the last year to shift Matrix from being a decentralised-server architecture to a fully decentralised-client p2p architecture, through running clientside homeservers and experimenting with libp2p and friends as a p2p transport. We'll also show the route we'll be following over the year to go from proof-of-concept to the live Matrix network.
Traditionally Matrix decentralises communication by replicating conversation history over a mesh of servers, so that no single server has ownership of a given conversation. Meanwhile, users connect to their given homeserver from clients via plain HTTPS + DNS. This has the significant disadvantage that for a user to have full control and ownership over their communication, they need to run their own server - which comes with a cost, and requires you to be a proficient sysadmin. In order to fully democratise communication and eliminate a compulsory dependency on a homeserver, we've started seriously working on making Matrix run as a P2P protocol by compiling homeservers to run clientside and using P2P transports such as libp2p - while seamlessly supporting all existing Matrix clients (e.g. Riot.im), bots and bridges with negligible changes. This work includes:
In this talk we'll show off our progress so far, and lay out the path forwards over the coming year as we go from proof-of-concept to the live Matrix network.
The Matrix team has had a lot of fun recently investigating radically more efficient transports thanks to a challenge to get usable client-server and server-server communication on links as bad as 100bps. In this talk we're give a tour of the network simulation environment we've built and the transports, encodings and routing algorithms we've used to slash our network resource utilisation. We'll also look at what this could mean for open source push notification implementations.
Matrix is an open protocol and network for secure decentralised communication which uses HTTPS+JSON as its baseline transport and encoding. Whilst HTTP is convenient for developers, it's not the most resource-efficient solution for instant messaging. Matrix has always theoretically supported alternative transports, and we finally got an excuse to build one and push it to a ludicrous extreme - to try to operate usably over links as low as 100bps, as high as 4s latency, and up to 40% jitter. The approaches we've taken include:
We'll talk through our findings, show off the simulator (which is ridiculously fun), spin up a ton of servers and log into them, break the network, and see just how well everything holds up...
At the beginning of 2018, the French Government reached out to Matrix.org to discuss the idea of creating an entirely open source, standards-based encrypted messaging app as the official means of instant messaging and VoIP communication across the government; replacing adhoc usage of centralised proprietary services such as Telegram and WhatsApp. As of summer 2018, their app exists (a public fork of Riot.im), and there is now a massive federation of Matrix servers deployed throughout the government serving up to 5.5M users, spanning over 30 clusters, letting each ministry run and admin their own operationally independent deployment. In this talk we'll tell the adventure of rolling out FOSS communications at this scale, and give a tour of the architecture and all the work that's gone into Matrix along the way to reach a 1.0 capable of powering government-grade communication.
Matrix is an open source project that defines a protocol for secure, decentralised real-time communication - providing simple HTTP+JSON APIs for sending and receiving instant messages, VoIP calls, file transfers, and any other arbitrary realtime data. In this talk we'll tell the tale of how the French Government has deployed Matrix at massive scale, show off their app and its capabilities, and dive into all the challenges and solutions which came up along the way. Particularly, we'll cover what was needed to finalise Matrix's end-to-end encryption such that it can be turned on by default for all conversations; designing whole new extensions to Matrix to support content-scanning of E2E encrypted attachments, and the pleasures of high-availability clustering and management of Matrix server farms by Ansible.
Meanwhile, Matrix itself is rushing towards a 1.0 release (as of Oct 2018) - defining stable releases of the spec across all API surfaces; defining the long-term open governance process for Matrix; iterating on the room state merge resolution protocol which lies at the core of Matrix's decentralisation; and massive amounts of performance work: reducing disk space by 10x thanks to improved state compression; switching from O(N) to O(1) state resolution via memoization; reducing sync sizes and client RAM by 3-5x via lazy-loading members; saving 2-3x RAM in Synapse by migrating from Python 2 to Python 3 etc. We'll give a tour of Matrix 1.0, and talk about what comes next!
VR/AR has a huge problem: there isn't any standard way to communicate with other people. This talk will demo how Matrix can be used as an open signalling layer for establishing WebRTC voice, video and 3D video calls in WebVR on anything from a Cardboard to a Vive: providing a decentralised communication ecosystem to build an open metaverse!
One of the most fun areas Matrix.org has worked on this year has been adding interoperable WebRTC calling to WebVR using matrix-js-sdk, A-Frame and the latest WebVR browser support and hardware (Cardboard, Rift & Vive). Rather than communication in WebVR being fragmented into different silos and websites, we hope that Matrix will provide an open decentralised ecosystem to power communication within a decentralised metaverse of WebVR environments. We'd like to show off our demo of full-mesh end-to-end encrypted videoconferencing in WebVR, as well as interoperability with the rest of the Matrix ecosystem. Finally, we're hoping to demonstrate some of our work in transmitting 3D camera depth-buffer and mesh data over WebRTC media & datachannels in order to bring 3D video calling in VR to life!
Over at Matrix.org we've spent a lot of the last year refining the Matrix protocol for open, secure, decentralised communication to make it more usable for larger scale usage. One of the major recent additions has been the ability to group together sets of users and rooms into 'Communities' - equivalent to Slack Teams or Discord Servers, which give a way for existing projects and communities to give their users a much more focused and friendly environment for decentralised communication with Matrix. In this talk we'll explain how Communities (aka Groups) work, how they're implemented, and how FLOSS projects in particular are using them and other recent features to escape the centralised tyranny of proprietary alternatives!
Everyone should be painfully familiar with the sinking feeling of their favourite online community (be that FLOSS or any other topic) fragmenting and getting trapped in proprietary communication technologies. Matrix exists to defragment these silos and provide an open standard with open source implementations as a decentralised alternative. One of the main improvements over the last year has been the introduction of Communities - a new feature in Matrix which provides a much-needed ability to define decentralised sets of users and groups alongside other community metadata (profile page, avatar, etc) to create a friendly home in Matrix for existing organisations of any kind. This makes it way easier to migrate from proprietary silos into Matrix for communication and collaboration within a community, as rather than users being thrown head first into the open ocean of Matrix, anyone can now produce curated landing pages for given communities which users can participate in... without having to constantly sign up for new accounts or having communities locked into proprietary platforms. Meanwhile bridges lets Matrix connect through to IRC, Slack, Discord, Telegram and others to fix the fragmentation problem. We'll be showing off how folks like NextCloud, OpenSource Design, Status.im and Cosmos are using Communities already, and how they work under the hood.
Meanwhile, lots of other stuff has landed in Matrix this year focused on improving usability: entirely new UX for managing end-to-end encryption; all new native desktop clients (e.g. Nheko from the community); the addition of Widgets to embed arbitrary webapps into Matrix rooms; integrating with Jitsi for video conferencing and more! Alongside Communities we'll show off the latest stuff and demonstrate how Matrix clients like Riot are becoming an increasingly viable open source alternative to Slack and friends.
For the last 2 years the Matrix.org team has been working on libolm - a clean-room FOSS liberal-licensed (Apache) independent specification and implementation of the end-to-end encryption Double Ratchet Algorithm as popularised by Signal, WhatsApp, Facebook Messenger, Google Allo etc. As of November 2016 the spec and library is finally finished and being unleashed on the world, successfully audited by NCC Group, and is available as part of Matrix's client SDKs for Web, iOS & Android and apps that use them (e.g. Riot.im).
In this talk we will discuss Matrix's mission to be an open, global end-to-end-encrypted communications network - showing that it's possible to build open communication infrastructure which is both secure and decentralised (unlike the silos of Signal, Wire, etc); where users can own their data and pick who they trust to run their service. We'll show how you can use Matrix to securely defragment communities scattered over proprietary silos such as Slack, Telegram and Gitter, open silos like Rocket.Chat and MatterMost - whilst also bridging to IRC, XMPP and even SIP.
We'll also introduce the Megolm cryptographic ratchet - a new ratchet written by Matrix to tackle the specific problem of encrypting Matrix rooms, which may have thousands of users and require synchronised history over multiple devices (including new devices). Megolm is layered on top of the Olm ratchet, and is unusual in that it encrypts per-device rather than per-user, and lets rooms specify how much scrollback may be decrypted by new devices: providing a customisable trade-off between privacy and usability. This is a major step forwards from other systems which unilaterally prioritise privacy over usability.
Finally, we'll give a quick tour of all the FOSS clients, bots and bridges that the community has built on Matrix over the last year - ranging from native Qt clients (Quaternion, NaChat, Tensor), CLI apps (WeeChat), React webapps (Riot, Freebird) to Native mobile apps (Riot).
Matrix.org is a non-profit open source initiative dedicated to creating and maintaining the Matrix open standard for decentralised communication, whose goal is to create an open and secure ecosystem for interoperable messaging, VoIP and IoT communication on the internet.
The success of the decentralised internet depends on robust building blocks for decentralised identity, reputation and communication in general. We'll look at how Matrix.org (an open standard for decentralised communication) is attacking these problems - both now and in the future.
Matrix is an open source project that publishes a standard and reference FOSS implementations for decentralised communication, primarily focusing on defragmenting all the various communication silos (messaging, VoIP, IoT etc) that users are trapped in today. We believe that no single company or entity should ever have ownership or control a user's conversations - only the user themselves should have control.
In Matrix today rooms are replicated over all the servers which participate in a given conversation, decentralising by default similarly to Git or blockchain. Unlike other protocols, rooms have no single point of control on a given domain or entity and conversation history is shared equally over all participants. However, user accounts themselves are currently bound to a single 'home server', meaning that users are currently tied to a single service provider, similarly to email or XMPP.
In this talk, we'll discuss Matrix's plans to decentralise accounts too - letting users share their account data across whatever sets of servers they trust; providing account portability as a matter of course. We'll also discuss the related topic of decentralised identity - how to track how email addresses, phone numbers and other identifiers map to a given matrix user... without maintaining a centralised ID mapping database.
Finally, we'll explore the critical topic of decentralised reputation. Any decentralised system, whether it's Matrix, Email, XMPP, blockchain etc needs a way of tracking the relative reputation of the participants in the system in order to let users filter undesirable content. We see this as the single biggest challenge remaining for Matrix, and one that is vital to the internet at large - helping users self-curate the content they consume and breaking free of the echo-chamber effect of centralised services. We'll talk about the options we've been looking at with Matrix, and issue a call to arms for the whole community to work on solving this problem.
Matrix is an open standard for open decentralised real-time communication using simple HTTP APIs and WebRTC, providing fully decentralised communication history with cryptographic integrity and no single point of control over any given conversation. Since our debut at FOSDEM 2015, the project has grown significantly as we've added end-to-end encryption, glossy clients, read receipts, WebRTC conferencing, and built bridges and integrations with a huge range of existing communication networks. This talk discusses the challenges we've hit along the way, and updates the FOSDEM community on how our mission is progressing!
Today, most commonly used VoIP and instant messaging apps do not interoperate, and all your data is stored in each service, locking in users and fragmenting their conversations and contacts between different vendors. In the Matrix ecosystem, anyone can run a server (called a "homeserver"), and a communication room is owned by all the homeservers participating in that room.
Users can communicate via any client or service that understands the Matrix protocol; we provide open source implementations for web and mobile, and members of the community have written many other open source clients in languages ranging from QML to Emacs. We have also written bridges that enables a homeserver to connect to existing protocols such as IRC, XMPP or SIP, and solutions such as FreeSWITCH, Asterisk and even Lync.
In this session we will explain the design choices we made when creating Matrix, the challenges over the last year, and we will look at different clients and servers that have been implemented (both by ourselves and the community). We'll demo the latest features such as end-to-end encryption and video conferencing, and show how Matrix is a viable option for all your open realtime communication needs!
In this session we will focus on gathering, processing & visualising data from various IoT and human sources, reviewing the various technologies available to unify the data whilst providing a deep dive into the Matrix.org decentralised data ecosystem.
After an introduction to the problem space and available solutions, we will focus on introducing Matrix's architecture and its open source, Apache-licensed reference client and server implementations.
This session will show how to actually build an entirely open and dentralised IoT platform using open source software. Together we will start from scratch, check-out the code and first get a Matrix webclient running. We will use this as a dashboard to collate and visualise data from a variety of connected devices and services, federated together in an open ecosystem via Matrix. We will then add services on top to further aggregate, process and route the data.
We will also discuss exactly how you could extend the platform for advanced features and for your own specific needs. We will look at some examples (wearable computing, drone control/telemetry/video, robotics) that we and the community have implemented during various hackathons and projects - and show how IoT data may be bridged into non-IoT communication platforms such as IRC or Slack via Matrix.
Matrix is a new, pragmatic HTTP-based clean-room alternative to XMPP, SIP, IRC and other messaging/VoIP technologies. It consists of an open standard defining RESTful HTTP APIs and open source, Apache-licensed reference implementations for creating and running your own real-time communication infrastructure for VoIP/IM or any other service that includes sending binary data around - including IoT services.
Matrix is a set of pragmatic RESTful HTTP JSON APIs presented as an open standard, intended to be implemented on a wide range of servers, services and clients, letting developers build functionality on top of the Matrix ecosystem for messaging, VoIP and a multitude of other services.
In Matrix, every user runs one or more Matrix clients, which connect through to a Matrix "homeserver" which stores all their personal communication history and user account information - much as a mail client connects through to an IMAP/SMTP server. Just like email, you can either run your own Matrix homeserver, which means you own and control your own communications and history - or you can use one hosted by someone else (e.g. matrix.org) - there is no single point of control or mandatory service provider in Matrix. In fact, there is no single point of control over conversations in Matrix at all - conversation history is a first class citizen, with room state replicated over all participating servers, avoiding single-points of failure or control as you get in XMPP MUCs.
With the continously increasing number of devices connected to the internet, we need ways to gather and unify all the status and instruction data going back and forth - and Matrix is a perfect fit for these kind of services.
Matrix is a new, pragmatic HTTP-based clean-room alternative to XMPP, SIP, IRC and other messaging/VoIP technologies. It consists of an open standard defining RESTful HTTP APIs and open source, Apache-licensed reference implementations for creating and running your own real-time communication infrastructure.
Our hope is to make VoIP/IM as universal and interoperable as email, and build an open ecosystem that people can use for a multitude of purposes.
We believe that real-time communication is fundamentally broken and fragmented on today's internet. XMPP and SIP tried to solve this, but haven't taken off as they might have done, leaving the internet dominated by closed proprietary islands of communication like WhatsApp, Facebook, Hangouts, etc.
Enter Matrix: a set of pragmatic RESTful HTTP JSON APIs as an open standard, intended to be implemented on a wide range of servers, services and clients, letting developers build messaging and VoIP functionality on top of the Matrix ecosystem rather than adding yet another closed/proprietary solution.
In Matrix, every user runs one or more Matrix clients, which connect through to a Matrix "homeserver" which stores all their personal chat history and user account information - much as a mail client connects through to an IMAP/SMTP server. Just like email, you can either run your own Matrix homeserver, which means you own and control your own communications and history - or you can use one hosted by someone else (e.g. matrix.org) - there is no single point of control or mandatory service provider in Matrix. In fact, there is no single point of control over conversations in Matrix at all - conversation history is a first class citizen, with room state replicated over all participating servers, avoiding single-points of failure or control as you get in XMPP MUCs.
In the end, we hope Matrix will crack the problem of a widely successful open federated platform for communication on the internet, and provide a worthy alternative to the PSTN. You should be able to use your favourite app to communicate via Matrix - and your recipients should be able to reply through the app of their choice!