Representatives of the Matrix Council had their second online meeting today, 11 January 2024.
Meeting participants: Merlijn Seberecths, Marc Gilligan, Aaron Rainbolt, Seth Arnold, Mauro Gaspari, Nils Büchner
Meeting chair: Nils Büchner (@ravage:xentonix.net)
The Matrix Council had a very constructive meeting with Kenny about their experience with the KDE IRC bridge.
KDE uses matrix-appservice-irc with over 2500 users on the bridge at the moment. The overall experience is positive.
The bridge is stable and so far there has been little to none negative feedback from the IRC side. They bridge selected rooms between IRC and Matrix. Moderation is done separately on both sides.
We want go forward with setting up the bridge. Details will follow soon.
We would like to thank Kenny ( @kenny:kde.org ) for the very helpful and open conversation.
The plan is to only bridge individual IRC channels to it’s Matrix counterpart.
Example: ubuntu on IRC to #support:ubuntu.com
We will try to bridge the most common rooms from the beginning.
Additional rooms can be requested on demand through the Ops room.
We discussed the need for an ubuntu- prefix for rooms aliased on the Ubuntu homeserver. Initially the idea was to make it easy to find Ubuntu related rooms on other homeservers. The consensus is that we do not need this prefix as the alias can be set individually on every homeserver.
For example the main Ubuntu support room has the local alias #support:ubuntu.com but can have it’s own name #ubuntu-support:matrix.org on the matrix.org homeserver.
Every user on the Ubuntu homeserver (that is every Ubuntu member) should be able to create rooms at any time. There is no need to announce temporary rooms to the OPs. Temporary rooms are not allowed to be published on the homeserver’s public directory. If you want to make room official/permanent it has to comply with certain rules and standards. This includes specifying the room’s rules and adding bots against spam. Details on how we can make sure this can be checked and monitored will follow in cooperation with the IS DevOps team.
Currently the Ubuntu homeserver has a whitelist that specifies which other homeservers it talks to. This has caused some confusion in the past. We hope to get a new proxy online within the next few weeks to be able to remove this limitation. Until then, if you need to contact someone on a non-whitelisted homeserver please contact us in the Ops room. We will try to add the server to the whitelist as soon as possible.
So far we already created some internal documentation about how Matrix works in general and how to setup basic things like rooms and spaces.
Our goal is to open that up to the community on Discourse.
There will be an open “aspirational index” of the documentation. Everyone will be able to add or extend articles.
All additions to this aspirational index may or may not land in the final index and every contribution can be modified. We will share details about that as soon as it becomes available.
Moderation on a federated platform like Matrix is a big challenge and will never be perfect.
With the growing number of rooms and spaces on the Ubuntu homeserver we talked about how we can allow moderation without limiting the freedom of individual rooms. Seth gave us some really helpful input from his experience on IRC in the past like this article.
We concluded that finding moderators that know about the specific culture of rooms is important for a functioning community. They usually know how to handle incidents much better than any “global” Ops team. Every space/room should be able to add their own rules in addition to the basic rules that apply to all Ubuntu rooms on Matrix.
Matrix is a great platform for bots. For basic tasks like reaction bots we found that Maubot can be a good platform. For more complicated task like moderation and spam defense more complex solutions are needed. Currently we use Mjolnir to handle those things. It is a very powerful tool but lacks some features we would like to have. For example it is difficult to assign limited power for room moderators or defenders. That is why access to this bot can be dangerous. Developing a custom bot has been discussed and Marc will look into this. Once we have a basis for such a bot everyone will be able to participate on this project.
Merlijn will contact the Fedora project about their experience with Maubot.