This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode

Matrix for OpenDev Comms

IRC has long been OpenDev’s synchronous communications platform. We’ve used it long enough to change IRC networks moving from Freenode to OFTC. As time has gone on one of the things that has made IRC approachable for new users is the ability to connect to IRC servers via bridges provded by the Matrix Foundation. Unfortunately, the Matrix Foundation has indicated that without additional funding these bridges are no longer a priority, and we have seen the OFTC Matrix bridge degrade functionality at times since.

Problem Description

IRC is a relic of the beginning days of the Internet. It existed before HTTP in a time where self hosting of federated services running over purpose built protocols was the norm. These attributes and long familiarity with the tools built around IRC have endeared the system to those of us who have relied upon it for decades.

The Internet is very different today. Users expect to interact with web services via a web browser without the need for running any long lived services themselves. This has made connecting to and using IRC difficult for those not already familiar with it. Nickserv with its special incantations instead of webforms is a foreign interface to many. Maintaining scrollback in IRC channels implies running a server somewhere to maintain a persistent connection to the IRC network. The ability to create a free Matrix account then connect to IRC channels via Matrix Foundation bridges with persistent scrollback all without leaving the web browser has made IRC accessible to many. Unfortunately, as this service has become unfunded those relying on it have noticed degradations of functionality. These degredations include network splits where new Matrix IRC connections are only visiable to other Matrix users on the bridge and not to native IRC users.

In addition to these user experience concerns, there is also the problem of corporate firewalls. IRC does not run over HTTP and many corporations consider it a risk due to historic use as a command and control protocol for botnets. Matrix does run over HTTP and provides an out for users whose corporate firewall policies allow outbound HTTP connections.

Proposed Change

In order to better serve our existing users that rely on Matrix for IRC connectivity and potential new users that would otherwise not connect to IRC I propose that we trial Matrix for OpenDev team communications. We would create the #opendev:opendev.org room on our existing Matrix homeserver. We would not host user accounts on Matrix. Users can continue to use free matrix.org accounts or accounts from another homeserver that allows user account creation.

Existing Matrix bridge users would simply connect to the new matrix room. Many of us that continue to use IRC natively also have Matrix connections in order to interact with other communities like Zuul and Gitea. We would also simply connect to the new room. Everyone else would be provided with a modern web account sign up process with client tooling that runs in their browser. This experience will be familiar to anyone who has used Slack or Discord.

The upsides to choosing Matrix over these other tools (Slack, Discord, etc) are many:

Matrix is Open Source Software
Matrix is a federated service allowing us to run our own homeserver
Matrix provides free unlimited scrollback to its users
Matrix is not riddled with ads

All of this on top of the common attributes of sharing modern web based tooling that runs over HTTP.

During the trial we would continue to operate and monitor the IRC channel and encourage users in that channel to connect to the Matrix room instead. Then after two months we can evaluate if the Matrix room has made it easier for our users to engage with OpenDev.

If after the two month trial we conclude that continuing to use Matrix is the best compromise for us, then there are a small number of followup improvements we will need to make.

First we would need to consider long term channel moderation needs. On IRC we have accessbot which delegates channel op to trusted individuals who can then ban users from those channels. For Matrix we would run a mjolnir instance on eavesdrop. This bot would then be joined to each of the rooms we manage on Matrix as an administrator. Trusted users would be invited to mjolnir’s management room. Users in this management room are trusted by mjolnir and it will carry out any requests made by those users to moderate the other rooms mjolnir is in.

It is worth noting that unlike accessbot we cannot configure mjolnir access and permissions programmatically through its configuration. Instead anyone with access to the mjolnir management channel have access to all of mjolnir’s functionality. We can record individuals with access to the mjolnir management channel in the opendev/project-config. In addition to adding transparency to the system this will allow us to formally nominate and approve such access via our normal code review processes.

Next, we currently rely on Limnoria’s meetbot plugin to help manage our weekly team meetings. This simplifies note taking and historical record keeping. We would want to write a new Matrix meetbot bot that would serve a similar purpose in our Matrix room(s).

Finally, we will want to update statusbot to communicate across both Matrix and IRC. This way we can send notices to rooms on both service types and record important log details regardless of where the client is connected.

Alternatives

We could continue to use IRC as we do today and encourage users to find alternatives to Matrix as an IRC client. These alternatives could include running bouncers or subscribing to IRCCloud.
We could run our own Matrix bridge for OFTC IRC channels. Others have chosen to take this route and written about their experiences: https://postmarketos.org/blog/2025/03/31/matrix-bridge-migration/ While doable it is non zero effort and requires coordination with OFTC. We’ve also gotten feedback from some that using Matrix for IRC is not as simple as they would like it to be. Running a Matrix client for Matrix rooms should be simpler for users.
Related to the previous alternative we could make Matrix the canonical location for our discussions then bridge the rooms in Matrix to IRC. The difference here is where we consider to be the canonical location and where we are bridged to from there.

Implementation

Assignee(s)

clarkb

Gerrit Topic

Use Gerrit topic “opendev-matrix” for all patches related to this spec.

git-review -t opendev-matrix

Work Items

Work items or tasks – break the feature up into the things that need to be done to implement it. Those parts might end up being done by different people, but we’re mostly trying to understand the timeline for implementation.

Create the #opendev:opendev.org room on our existing homeserver.
Connect matrix-gerritbot and matrix-eavesdrop to #opendev:opendev.org.
Update the topic in #opendev on OFTC indicating that we are now on Matrix and communication should be sent there.
Lurk in #opendev on OFTC to redirect users to Matrix from there.
Decide after two months if we complete the transition to Matrix or take what we have learned and return to IRC.

Repositories

We may need a new git repository if we decide to expand the scope of matrix-eavesdrop significantly for meeting support. That said the most likely result is that we’ll continue to maintain that codebase within opendev/system-config.

Servers

No new services or servers will be needed. We will update the existing homeserver configuration and possibly update the existing matrix-eavesdrop bot.

If the trial is a success and we proceed with Matrix then we would need to run a mjolnir instance, a new meetbot for Matrix, and update the existing statusbot bot to handle both Matrix and IRC status updates.

DNS Entries

No DNS updates required.

Backups

No changes should be necessary for backups. We’ll log the new room similar to how we log the existing IRC channel.

Documentation

Our user documentation will need to be updated to point people at the Matrix room. This includes (but is likely not limited to):

We will also send notice of the trial to service-announce@lists.opendev.org once we begin the trial.

Security

The primary security consideration is whether or not we should encrypt the new Matrix room. Since we will publicly log the room anyway there is little need to encrypt the room itself. This simplifies client management for users connected to the room.

Testing

The change itself is a large test/trial. We aim to make the change to see if this is viable and if it produces a better communications system for our users.

Dependencies

None