Matrix 2.0: How we’re making Matrix go voom

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • matrix-docker-ansible-deploy

    🐳 Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker

    If you host yourself on a VPS you can hook in coturn (it's enabled by the linked playbook by default):

    https://github.com/spantaleev/matrix-docker-ansible-deploy/b...

    https://github.com/coturn/coturn

  • matrix-dimension

    Discontinued An open source integration manager for matrix clients, like Element.

    Scalar (the integration manager) is not open source [1] (though there was some effort to reverse-engineer its protocol [2]); and some of their anti-abuse scripts aren't public [3]

    [1] https://github.com/vector-im/element-meta/issues/260

    [2] https://github.com/turt2live/matrix-dimension/blob/master/do...

    [3] https://github.com/matrix-org/matrix.org/issues/557

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • element-x-ios

    Next generation Matrix client for iOS built with SwiftUI on top of matrix-rust-sdk.

    Element X is an entirely new client written in Rust + Swift UI/Jetpack Compose (https://github.com/vector-im/element-x-ios and https://github.com/vector-im/element-x-android) which will eventually replace the legacy Element apps (https://github.com/vector-im/element-ios and https://github.com/vector-im/element-android).

    The features already exist serverside; we're just working on getting them out of beta.

  • element-x-android

    Android Matrix messenger application using the Matrix Rust Sdk and Jetpack Compose

    Element X is an entirely new client written in Rust + Swift UI/Jetpack Compose (https://github.com/vector-im/element-x-ios and https://github.com/vector-im/element-x-android) which will eventually replace the legacy Element apps (https://github.com/vector-im/element-ios and https://github.com/vector-im/element-android).

    The features already exist serverside; we're just working on getting them out of beta.

  • element-ios

    A glossy Matrix collaboration client for iOS

    Element X is an entirely new client written in Rust + Swift UI/Jetpack Compose (https://github.com/vector-im/element-x-ios and https://github.com/vector-im/element-x-android) which will eventually replace the legacy Element apps (https://github.com/vector-im/element-ios and https://github.com/vector-im/element-android).

    The features already exist serverside; we're just working on getting them out of beta.

  • element-android

    A glossy Matrix collaboration client for Android.

    Element X is an entirely new client written in Rust + Swift UI/Jetpack Compose (https://github.com/vector-im/element-x-ios and https://github.com/vector-im/element-x-android) which will eventually replace the legacy Element apps (https://github.com/vector-im/element-ios and https://github.com/vector-im/element-android).

    The features already exist serverside; we're just working on getting them out of beta.

  • matrix-spec-proposals

    Proposals for changes to the matrix specification

    The Matrix team spent 15 years building SIP stacks before we gave up and created Matrix, so I can answer this with some confidence:

    Superficially, Matrix looks a bit like SIP: for 1:1 calls, you send an m.call.invite (like a SIP INVITE) to someone; they answer with an m.call.answer (like a SIP 200 OK); eventually someone hangs up with an m.call.hangup (like a SIP BYE). However, the differences are:

    * As a transport, everything goes over normal Matrix signalling (by default HTTPS+JSON) rather than SIP's mix of UDP and TLS sockets. As a result, no need for SIP's three-way handshakes inherited from its UDP transport

    * As a result, you inherit Matrix's end-to-end-encryption and decentralisation for free (so no special Routes, Vias, Record-Routes, branch parameters etc from SIP - it uses the Matrix client-server and server-server APIs over HTTPS instead)

    * Everything is trickle ICE by default for rapid call setup, no need to gather candidates

    * Matrix piggybacks on WebRTC for its media protocol, so you don't have the fragmentation of different media transports that SIP has inherited

    * Matrix (as of https://github.com/matrix-org/matrix-spec-proposals/blob/mat...) now supports multiparty native VoIP calls in the same conversation: effectively letting you signal full-mesh, SFU and MCU style multiway video/voip using the same mechanism as you'd use for a 1:1 call. This is probably the biggest difference in the end: with Matrix's VoIP you can jump straight in and have interoperable Zoom/Teams/Jitsi style conferences (as shown in the OP at https://youtu.be/eUPJ9zFV5IE?t=1513) - Matrix isn't just for boring old PSTN/PBX-style 1:1 calls, but for the conferences folks actually expect to use today.

    You can play with it at https://call.element.io, and if you really want to compare with SIP, go to the developer tools in options and turn on callflow mode, which will draw little mermaid sequence diagrams of the call signalling for the calls, so you can see precisely what's going on :)

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • convos

    Convos :busts_in_silhouette: is the simplest way to use IRC in your browser

    For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.

    Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.

    [1] - https://github.com/thelounge

    [2] - https://thelounge.chat/

    [3] - https://github.com/convos-chat/convos/

    [4] - https://convos.chat/

    [5] - https://www.mumble.info/

    [6] - https://github.com/umurmur/umurmur/wiki/Configuration

  • Mumble

    Mumble is an open-source, low-latency, high quality voice chat software.

    For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.

    Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.

    [1] - https://github.com/thelounge

    [2] - https://thelounge.chat/

    [3] - https://github.com/convos-chat/convos/

    [4] - https://convos.chat/

    [5] - https://www.mumble.info/

    [6] - https://github.com/umurmur/umurmur/wiki/Configuration

  • umurmur

    Minimalistic Murmur

    For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.

    Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.

    [1] - https://github.com/thelounge

    [2] - https://thelounge.chat/

    [3] - https://github.com/convos-chat/convos/

    [4] - https://convos.chat/

    [5] - https://www.mumble.info/

    [6] - https://github.com/umurmur/umurmur/wiki/Configuration

  • The Lounge

    💬 ‎ Modern, responsive, cross-platform, self-hosted web IRC client

    For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.

    Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.

    [1] - https://github.com/thelounge

    [2] - https://thelounge.chat/

    [3] - https://github.com/convos-chat/convos/

    [4] - https://convos.chat/

    [5] - https://www.mumble.info/

    [6] - https://github.com/umurmur/umurmur/wiki/Configuration

  • pantalaimon

    E2EE aware proxy daemon for matrix clients.

    Well, if you want end-to-end encryption, then obviously that's going to be hard to write from scratch(!) - especially if you want it to be secure. However, we make it trivial to get up and running by piping your client through a proxy like Pantalaimon (https://github.com/matrix-org/pantalaimon/) which takes your normal traffic and makes it E2EE.

    Not sure which "any of the other tablestakes features" you have in mind... obviously if you want loads of features, then you're going to have to write a whole bunch of code to implement them in your client, or build on an existing SDK like matrix-bot-sdk, matrix-rust-sdk, matrix-js-sdk etc. Not sure that's a disadvantage of Matrix though(!)

  • coturn

    coturn TURN server project

    If you host yourself on a VPS you can hook in coturn (it's enabled by the linked playbook by default):

    https://github.com/spantaleev/matrix-docker-ansible-deploy/b...

    https://github.com/coturn/coturn

  • github

    A GitHub client and webhook receiver for maubot (by maubot)

    We use Matrix for our open source project: https://wiki.mathesar.org/en/community/matrix. We self-host a Synapse homeserver, but there's no reason why you can't set up a community on one of the big existing servers (e.g. matrix.org). Their Spaces feature allows you to package groups of channels together.

    I set up Maubot for GitHub integration: https://github.com/maubot/github. There are moderation features, but we haven't had to use them.

  • matrix-hookshot

    A bridge between Matrix and multiple project management services, such as GitHub, GitLab and JIRA.

    Matrix's moderation should be at least as good as Gitter. The GitHub integration is okay (it lets you create/comment/resolve issues using your GitHub identity from Matrix, and also can expose GitHub issues as Matrix rooms using https://github.com/matrix-org/matrix-hookshot). It's not quite as tightly integrated as GitHub was to Gitter though, but we're working on putting it in the Right Panel.

    Some example Matrix communities which seem to work well include Mozilla (chat.mozilla.org), GNOME (https://matrix.to/#/#community:gnome.org) and KDE (https://webchat.kde.org/). Smaller ones include folks like Helix editor: https://matrix.to/#/#helix-community:matrix.org. I don't think anyone's written a guide for getting up and running though, which in retrospect is a crying shame; we'll get it on the todo list.

    (p.s. thanks for Hex Fiend! :D)

  • matrix.to

    A simple stateless privacy-protecting URL redirecting service for Matrix

    Matrix's moderation should be at least as good as Gitter. The GitHub integration is okay (it lets you create/comment/resolve issues using your GitHub identity from Matrix, and also can expose GitHub issues as Matrix rooms using https://github.com/matrix-org/matrix-hookshot). It's not quite as tightly integrated as GitHub was to Gitter though, but we're working on putting it in the Right Panel.

    Some example Matrix communities which seem to work well include Mozilla (chat.mozilla.org), GNOME (https://matrix.to/#/#community:gnome.org) and KDE (https://webchat.kde.org/). Smaller ones include folks like Helix editor: https://matrix.to/#/#helix-community:matrix.org. I don't think anyone's written a guide for getting up and running though, which in retrospect is a crying shame; we'll get it on the todo list.

    (p.s. thanks for Hex Fiend! :D)

  • telegram

    A Matrix-Telegram hybrid puppeting/relaybot bridge (by mautrix)

    It's supported, e.g. mautrix-telegram uses it: https://github.com/mautrix/telegram/blob/master/ROADMAP.md

  • rust

    Empowering everyone to build reliable and efficient software.

    I've been dogfooding the iPad layout of Element X under macOS on Apple Silicon since day 1 - it works pretty well. We could also ship it via Catalyst to run as a pure macOS app (albeit with the iPad layout) on both Apple Silicon and Intel, once https://github.com/rust-lang/rust/issues/106021 is fixed.

    Unfortunately making it a "real" macOS app is much harder, as the UI is currently uses UIKit in a bunch of places to make up for feature and performance limitations in SwiftUI. These would have to be ported over to AppKit to run on macOS. I had a go at it over the holidays, but it's not trivial - perhaps someone with more AppKit skills than I could make it work (or maintain a fork) though.

    To give an idea of the amount of UIKit that would need to be swapped out:

    ```

  • Kiwi IRC

    🥝 Next generation of the Kiwi IRC web client

    > At that point you've just reimplemented a less-standard version of matrix with extra steps though.

    There are IRCv3 specifications that allow this richer experience, and they are at least as standard as Matrix. Check out https://ergo.chat/ with modern clients like https://sr.ht/~emersion/goguma/ (Android), https://git.sr.ht/~emersion/gamja/ https://kiwiirc.com/ (web), or https://git.sr.ht/~taiite/senpai (TUI)

    > but in practice using your enhanced server from an unenhanced client will always be painful

    IRCv3 normally makes sure new specs don't make it worse for older clients. Could you give me some examples to see if we can fix that?

  • element-meta

    Shared/meta documentation and project artefacts for Element clients

    Scalar (the integration manager) is not open source [1] (though there was some effort to reverse-engineer its protocol [2]); and some of their anti-abuse scripts aren't public [3]

    [1] https://github.com/vector-im/element-meta/issues/260

    [2] https://github.com/turt2live/matrix-dimension/blob/master/do...

    [3] https://github.com/matrix-org/matrix.org/issues/557

  • matrix.org

    matrix.org public website

    Scalar (the integration manager) is not open source [1] (though there was some effort to reverse-engineer its protocol [2]); and some of their anti-abuse scripts aren't public [3]

    [1] https://github.com/vector-im/element-meta/issues/260

    [2] https://github.com/turt2live/matrix-dimension/blob/master/do...

    [3] https://github.com/matrix-org/matrix.org/issues/557

  • Element

    A glossy Matrix collaboration client for the web.

  • Synapse

    Discontinued Synapse: Matrix homeserver written in Python/Twisted.

  • hydrogen-web

    Lightweight matrix client with legacy and mobile browser support

  • conduit

    > "At least as standard" how?

    There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.

    > A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on.

    But any IRC client will work fine on any IRC server, and they can connect to various servers with different implementations.

    On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following exactly the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.

    It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".

    > And there seem to be more visibly independent implementations of Matrix than IRCv3.

    Clients, maybe, at least in the number of implementation. It's hard to find stats of this, but I feel that >95% of people in the public federation use Element even in tech-y rooms; IRC has a healthier mix of major clients (weechat, irssi, IRCCloud, Hexchat, KiwiIRC, The Lounge each have >5% of desktop/web users). But I admit that's just my very subjective point of view.

    In terms of servers, Matrix has three open source ones as far as I know: Synapse (controlled by Element), Dendrite (controlled by Element, and almost on par with Synapse according to https://arewep2pyet.com/ ), and Conduit. Based on https://gitlab.com/famedly/conduit/-/milestones/3 , Conduit seems to be far from implementing the spec yet (eg. it doesn't seem to support leaving rooms or respecting history visibility).

    > things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps)

    You can use https://ircv3.net/specs/extensions/message-ids to deduplicate them.

    > And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs.

    A conversation where people where people are using embedded gifs will exclude me regardless of client, because they are too distracting. At least on IRC I can expect people not to do it too much, and use words or emojis instead of reaction gifs.

    > SSO access control; you just can't do that in a nice way if the client doesn't support it

    That's a fair point; IRC is made by hobbyists more than companies, so that's not surprising. There is some discussion around it though: https://github.com/ircv3/ircv3-ideas/issues/74 and Sourcehut is sponsoring implementation (https://emersion.fr/blog/2022/irc-and-oauth2/).

  • ircv3-ideas

    > "At least as standard" how?

    There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.

    > A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on.

    But any IRC client will work fine on any IRC server, and they can connect to various servers with different implementations.

    On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following exactly the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.

    It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".

    > And there seem to be more visibly independent implementations of Matrix than IRCv3.

    Clients, maybe, at least in the number of implementation. It's hard to find stats of this, but I feel that >95% of people in the public federation use Element even in tech-y rooms; IRC has a healthier mix of major clients (weechat, irssi, IRCCloud, Hexchat, KiwiIRC, The Lounge each have >5% of desktop/web users). But I admit that's just my very subjective point of view.

    In terms of servers, Matrix has three open source ones as far as I know: Synapse (controlled by Element), Dendrite (controlled by Element, and almost on par with Synapse according to https://arewep2pyet.com/ ), and Conduit. Based on https://gitlab.com/famedly/conduit/-/milestones/3 , Conduit seems to be far from implementing the spec yet (eg. it doesn't seem to support leaving rooms or respecting history visibility).

    > things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps)

    You can use https://ircv3.net/specs/extensions/message-ids to deduplicate them.

    > And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs.

    A conversation where people where people are using embedded gifs will exclude me regardless of client, because they are too distracting. At least on IRC I can expect people not to do it too much, and use words or emojis instead of reaction gifs.

    > SSO access control; you just can't do that in a nice way if the client doesn't support it

    That's a fair point; IRC is made by hobbyists more than companies, so that's not surprising. There is some discussion around it though: https://github.com/ircv3/ircv3-ideas/issues/74 and Sourcehut is sponsoring implementation (https://emersion.fr/blog/2022/irc-and-oauth2/).

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts