Recently we’ve been looking at the Matrix protocol and its close integration in the Rocket.Chat platform. The Matrix protocol is a standard for secure, federated real-time messaging created by the UK-based matrix.org foundation. It employs end-to-end encryption by default, and can be used by many instant messaging clients, including applications you may be familiar with, via their extensive assortment of client-to-Matrix bridges. To test this, we’ve been using Rocket.Chat, a widely adopted open-source communications platform, and Matrix’ own client Element.
Why does it matter?
The idea is decentralised communication; talking to people via the Matrix protocol in other domains, whilst not having to add those people directly to your domain. A common example is given for that of a manufacturer who wants to be able to talk to several suppliers via an instant messaging channel. The manufacturer wants to have a list of channels in their instant messaging software for each supplier but does not want the supplier to be added to their environment (if this was the case, they could message other suppliers directly, or other people in your organisation).
This is where Matrix comes in; we have Rocket.Chat configured with Matrix such that we can send messages from the Rocket.Chat messaging application directly to the users on the Matrix’ Element messaging application on special ‘federated’ channels. The Matrix users can message each other, and the Rocket.Chat users via these special channels, but we have a boundary between the domains.
Once we can bridge communication from Rocket.Chat to a Matrix server, we are able to talk to other Matrix servers which may be connected to almost any other messaging client. This opens the possibility to enable secure communications without using bespoke portals or being tied into specific client applications or services.
The tech bit…
Docker containers for Rocket.Chat and its MongoDB replica set, and the Matrix homeserver implementation ‘Dendrite’ with its PostgreSQL database were successfully deployed on AWS inside a single EC2 compute instance, with an NGINX proxy configuration for accessing either service via TLS. We used a docker-compose script based on a repository created by one of Rocket.Chat’s lead developers Aaron Ogle for repeatable results; the deployment was scripted using Pulumi IaS to launch and teardown when required.
Whilst the concepts behind this setup are simple, this was by no means an easy configuration. Matrix uses certificated TLS by default, and there are several procedural ‘gotcha’s’ that can hinder successful deployment with regards to config files, host names, and how network traffic moves between the two services. Rocket.Chat has the Matrix bridge built-in by default, so this was setup from the administration console in the UI.
During federation between the instance of Rocket.Chat and Matrix it appears that each service registers a new local user to represent the user on the other system; this caused some issues if restrictions are configured to prevent new registration of users. Ultimately, this was no bad thing as it shows confidence in the secure nature of the Matrix protocol and it’s second-generation home server implementation Dendrite.
Can we use this today?
Delving into interesting new technology is all very well and good, but can this be used today? We’ve seen promising signs; the Matrix foundation have addressed a number of vulnerabilities outlined in this paper in their SDKs and homeserver repositories, and our friends at Rocket.Chat are working on improving the developer experience for configuring Matrix with their platform, declaring that if you want to connect two Rocket.Chat instances, the Matrix bridge was the way to go about it in 2023. We look forward to seeing these new updates that get rolled out and more importantly, how they can enhance the experience of secure communication for our customers.