Merge "Add spec to use Matrix for OpenDev comms"
This commit is contained in:
Zuul
@@ -33,6 +33,7 @@ permits.
|
||||
:maxdepth: 1
|
||||
:caption: Approved Specs
|
||||
|
||||
specs/matrix_for_opendev
|
||||
specs/wiki_modernization
|
||||
|
||||
Help Wanted
|
||||
|
||||
@@ -0,0 +1,227 @@
|
||||
::
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
..
|
||||
This template should be in ReSTructured text. Please do not delete
|
||||
any of the sections in this template. If you have nothing to say
|
||||
for a whole section, just write: "None". For help with syntax, see
|
||||
http://sphinx-doc.org/rest.html To test out your formatting, see
|
||||
http://www.tele3.cz/jbar/rest/rest.html
|
||||
|
||||
========================
|
||||
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 <https://github.com/matrix-org/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.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
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):
|
||||
|
||||
* https://meetings.opendev.org/
|
||||
* https://docs.opendev.org/opendev/system-config/latest/project.html#contributing
|
||||
* https://opendev.org/
|
||||
|
||||
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
|
||||
Reference in New Issue
Block a user