Upcoming updates to our Matrix Moderation setup

Project Discussion
,
1

Hey folks,

TLDR; a bit of join/leave work in all our rooms as we switch to a new moderation account, and a policy for “official” Matrix rooms.

For the last … (checks notes) at least a year, the ever-excellent Emma has been hosting our moderation bot on their infrastructure. It’s been critical to protecting our community on Matrix, and huge thanks are due for this :heart:.

We cannot reasonably expect Emma to handle this forever though, so it’s time we brought this into the Fedora infra properly. I’m currently setting up a new account on our official, non-user homeserver (@moderation:fedoraproject.org is the Matrix ID) which will take over the role of doing the watching/redacting/kicking/banning from Emma’s account. As such, you’ll see me getting that account added to all our rooms and promoted to the needed power. The moderation team who can instruct the bot remains the same, and the bot config is the same, this is just a transfer to our own infra.

That’s the short term but longer term, it means we can also set a policy around “official Matrix rooms”. This might need to be re-posted to Project Discussion > Change Proposals but I’m thinking we can do something like:

  • Official Fedora Matrix Rooms MUST
    • Have the moderation bot in the room
    • Have the bot promoted to the correct powerlevel
    • Have the bot protecting the room (confirmation available from the Matrix moderation team)
  • Official Fedora Matrix Rooms SHOULD
  • Official Fedora Matrix Rooms MAY
    • Be added to a Matrix Space of choice
      • This is also done via an Infra ticket or as part of the creation ticket

Thoughts on this?

6 Likes
2

Thank you @rorysys for your service and hosting for our moderation point. We could not have survived the 2025 spam attacks without this critical infrastructure in place, combined with its stewardship and maintenance for many, many, months.

It might be an interesting idea to propose some/all of this as a F45 Change. It might be too late now to do that though? I forget the schedule and I’m not in a place to conveniently check.

Some amendments to the “MUST” clause though. I think rooms MUST have a :fedoraproject.org room alias, since this is the most visible, clear marker of something being official to most Matrix users/clients. I also thing a room MUST be added to an appropriate sub-space from the main Fedora space. I’ve taken great care to remove all individual rooms from the main Fedora space and sort them into the sub-spaces. This makes the interface easier to navigate with Element Web especially. The advantage of adding a new room to a sub-space is it further enshrines, in a visible way, what it means to be official, and also makes it easier for us to bulk edit rooms by sub-space too.

The rest looks and sounds good to me.

3 Likes
3

I’m glad to have been part of this for so long, and to have been able to provide this infra when it was needed. :slight_smile:

Just wanted to mention that a given (v12+) room can have “co-creators” (treated as equal to creators), so in theory you could have the room be created by the bot and have @fca:fp.o as co-creator or vice versa.

Additionally, i see no harm extending the bot to some non-official rooms too, if desired by an affiliated project (unsure of any examples here), without the need of a fp.o alias.

2 Likes
4

Hey folks,

TLDR; a bit of join/leave work in all our rooms as we switch to a new moderation account, and a policy for “official” Matrix rooms.

For the last … (checks notes) at least a year, the ever-excellent Emma has been hosting our moderation bot on their infrastructure. It’s been critical to protecting our community on Matrix, and huge thanks are due for this :heart:.

We cannot reasonably expect Emma to handle this forever though, so it’s time we brought this into the Fedora infra properly. I’m currently setting up a new account on our official, non-user homeserver (@moderation:fedoraproject.org is the Matrix ID) which will take over the role of doing the watching/redacting/kicking/banning from Emma’s account. As such, you’ll see me getting that account added to all our rooms and promoted to the needed power. The moderation team who can instruct the bot remains the same, and the bot config is the same, this is just a transfer to our own infra.

That’s the short term but longer term, it means we can also set a policy around “official Matrix rooms”. This might need to be re-posted to Project Discussion > Change Proposals but I’m thinking we can do something like:

  • Official Fedora Matrix Rooms MUST
    • Have the moderation bot in the room
    • Have the bot promoted to the correct powerlevel
    • Have the bot protecting the room (confirmation available from the Matrix moderation team)
  • Official Fedora Matrix Rooms SHOULD

Perhaps we should make this the matrix working group tracker?
I’m happy to let them handle requests as long as there is a active group
doing so. If not, infra is also fine with me.

  • Official Fedora Matrix Rooms MAY
    • Be added to a Matrix Space of choice
      • This is also done via an Infra ticket or as part of the creation ticket

Ditto the above.

Thank you @rorysys for your service and hosting for our moderation point. We could not have survived the 2025 spam attacks without this critical infrastructure in place, combined with its stewardship and maintenance for many, many, months.

Here here! Thank you!

It might be an interesting idea to propose some/all of this as a F45 Change. It might be too late now to do that though? I forget the schedule and I’m not in a place to conveniently check.

I think this is another infrastructure type of thing that really is ill
suited to the change process. I think just being deliberate/getting
feedback and then clearly announcing things will do…

Some amendments to the “MUST” clause though. I think rooms MUST have a :fedoraproject.org room alias, since this is the most visible, clear marker of something being official to most Matrix users/clients. I also thing a room MUST be added to an appropriate sub-space from the main Fedora space. I’ve taken great care to remove all individual rooms from the main Fedora space and sort them into the sub-spaces. This makes the interface easier to navigate with Element Web especially. The advantage of adding a new room to a sub-space is it further enshrines, in a visible way, what it means to be official, and also makes it easier for us to bulk edit rooms by sub-space too.

Thats fine, although I still wonder about private rooms being in the
space. Advertising that a room exists that people can’t join is weird…

3 Likes
5

Fair point, and I agree.

I have no problem with this.

Yeah, I’m thinking we’ll want a tool (perhaps an Ansible playbook, or just a script) that can be used with a moderator’s token which automatically adds the bot as a co-creator.

Completely, I’m happy to see us protect affiliated rooms - my main goal is to fix the proliferation of different room setups and try to standardise it :wink:

Yeah, this was mentioned to me elsewhere, and I agree - I’d forgot about that tracker. Just need to make sure they have the tools for setting the co-creator of rooms to the bot, I guess.

IIRC you san’t see them unless you have permissions to do so, right? So it’s not an issue because most folks won’t know they’re there.

6

Ah, I am pretty sure it was showing them even without ability to join
them sometime in the past, but I just tested with my fedora.im account
and it does indeed not show them.

7

But then that mean that the Fedora CoC decisions would extend to that affiliated rooms, while they are placed not officially covered by the CoC nor governed by it (and technically, the reverse would also apply). That’s IMHO a rather unfortunate governance mix that may cause troubles down the road.

8

I don’t think anybody is suggesting that “affiliated” rooms must have the fedora draupnir bot. Just that it would be nice to make it available to those “affiliated” project rooms.

1 Like
9

I think my point still apply even the bot is voluntary used.

The rooms will have to live with the Fedora CoC decisions even outside Fedora. They could decide to be ok with that, but the inverse is a bit more problematic, eg dealing with ban requests (cause I assume that people will ask for them unless they have their own bot, and in that cause, they likely not need draupnir from Fedora) from a room outside of the official Fedora rooms that will have impact on Fedora rooms for events that happened outside of the purview of the Fedora CoC (whose scope is quite clear ).

At minima, this should be discussed by the Fedora Council.

1 Like
10

I would prefer to keep things centralized in the Matrix WG, so there is a clear place for this kind of work and so that there is a mechanism to onboard people who want to help with this kind of work specifically.

Works for me. Likely warrants a post to devel-announce@. And maybe announce@ too? :thinking:

The benefit (for me) of having private rooms in a Fedora space is so that they are grouped with other Matrix rooms in that space, and when I am browsing the various Fedora sub-spaces or main space, I can find all of my Fedora-related chats in one place. But I guess this is something that only a space or sub-space admin could do…

For clarity, I think we are all speaking about @admin:fedoraproject.org when we are talking about “the bot”, right?

I see this as a non-issue. What we could do is perhaps make it clear to any other community which uses the Fedora community moderation bot outside of a :fedoraproject.org room that this bot is controlled by and for the Fedora community. I believe as policy, we should only moderate and add ban rules to the fedora-coc policy room when issues come up in :fedoraproject.org rooms. Any other community using the Fedora bot must understand and be willing to accept that the Fedora moderation bot will enforce Fedora rules and decisions.

I believe many of the communities using @rorysys’s bot and are not :fedoraproject.org rooms are largely okay with this. Some might not be, and that’s okay. They can always opt out or remove the bot from the room. But we are focused on trust and safety in our community first and foremost. It is great when we can help out other communities, but it is not our job or responsibility to be stewards of trust & safety tools for all Matrix-based communities ever.

Speaking as a Council member in transition and a member of the Fedora CoC Committee, I don’t see any precedent for this sort of decision requiring Council input. I am strongly against delegating this decision to the Council. It is up to the Matrix WG to make an operational policy decision and enforce it. We need our community platform moderators to be empowered to interpret the Code of Conduct and form their own moderation guidelines around it, similar to how the Fedora Discussion team has now done so.

If every decision about moderation has to flow back up to the Council, nothing is ever going to get done. The Council is not made up of content moderation experts. The experts are the people here, doing the work, day in and day out. If there is a need for an escalation pathway, then that is what the Code of Conduct is for.

1 Like
11

By agreeing to moderate rooms outside of Fedora (and so have shared editorial control on those rooms by being able to remove what is posted/said there), the project might be potentially taking extra legal liability.

To give the example of the EU and GDPR, Fedora (or more likely, Red Hat) would be a data Processor, because the bot process the rooms content and that’s personal data. But Fedora/RH would arguably also be a data controller since we control what to do with the data by co-moderating the rooms.

In turn, being a data controller might strip us of some legal protections after a recent CJEU ruling (Russmedia, C-492/23) where the Court seems to have weakened the safe harbour protection of the DSA. In short, if you have editorial control (like being able to moderate and moderating in practice), you also have responsibilities.

The decision is a tad controversial as you can imagine, slightly unclear as explained in the linked article, and will likely be discussed a lot in the future. But in the mean time, by being data controller, my understanding is that we lose some protections we would have in the US under section 230.

In fact, if you read the wikipedia page I just gave, you can see that the Herrick v. Grindr case is almost the same story of a fake profile on a website for dating as the Russmedia case, but the US court uphold immunity for Grindr where the EU court didn’t for Russmedia.

So I still maintain that the Council should be the one that decide if we want to take that potentially extra liability by offering the bot as a service for more than Fedora.

12

(does replying via email work?)
I’d figure the data processor relation already inherently exists via the existqnce of the fedora homeserver(s), no?

13

It seems so.

Processor, yes. But processor come with less responsibilities than controller. In the case I pointed, if the Court had found that Russmedia was just a processor, the website would likely had been protected by the DSA as a online intermediary service, aka, a dumb pipe. But the court decided it was a controller due to moderation (see §58, §67, §68 of the judgement), so it had more responsibilities.

The project is already responsible for all things that are managed by Fedora, and I think no one would be surprised by that. I want to make sure that the project leadership is ok to be potentially equally responsible for things that are not managed by Fedora.

And while I am quite sure there is a issue to be discussed, I am not a judge, I am not specialised on the topic of DSA/Section 230 (or legal systems outside the US/EU), and I am not in a position to decide the level of acceptable risk, so, if only for awareness, I think the Council should give a approval before.

And I gave the example of GDPR, but I found another potential issue.

Let’s say that we provide the bot as moderator for Matrix rooms for a University club for PhD students, totally unrelated to Fedora. That’s just a Fedora member who think Matrix is cool and ask for it. And since we are cool, we say “sure, here it is”. If they are paid by their university, they might be considered as a Governement Employee. This is not the case in the US because universities are private entities (as far as I know), but in France, we mostly have public universities, and so PhD students are mostly on the payroll of their university, or the payroll of fully state owned company such as EDF, or partially state owned defence contractor like Thales.

And the act of offering a service for some specific people (eg, paid by governement) could be constructed as corruption under the US FCPA (Foreign Corrupt Practices Act). Anyone who worked at RH for more than 1 year had to do the yearly mandatory training about it. And while I doubt that a bot would be a problem in practice, the training is clear on 2 things:

  • RH would be responsible, no matter what
  • In doubt, ask RH Legal team

So that’s another reason why I think it would be wiser to verify with the Council before adding the bot to a non Fedora room. While my example is convoluted, I do not think it is that convoluted, because this is what happen at every FOSDEM where I am never sure if I can pay the meal or not for new people I met.

14

Hm, i see… TIL about all those acts…
I personally don’t see operating in a personal capacity that way as problematic (hence my offering to run the bot for Fedora thus far), but I see how that could become problematic once you add the assumption that the bot isn’t managed by the people running the subject room etc.

As far as my services go, the exact configuration is available to Fedora/RH, under no concrete contract other than volunteer contribution (hence I’m not sure “unrelated” would count, as a contributor).

While it’s true that “Shadow IT” is legitimate risk, I’d be willing to argue that the benefits in legal protection outweigh the legal risk of such a conflict/finding anyhow.

15

moderation:fedoraproject.org but yes, the moderation account.

Regarding the room-creation process, I have a proof-of-concept workflow set up, see Making sure you're not a bot! for details.

16

I dont have an email address for the mentioned thread, but wouldn’t it make more sense to add @fca:fp.o as a creator and/or co-creator?

Could probably also do with having templated powerlevels, i’d figure.

17

Potentially, both accounts are likely to be around forever, unlike us mortal staffers :slight_smile:

The co-creator field could be added to the playbook easily if that’s wanted, and I don’t think it changes anything in terms of usage because you’ll still want to invite yourself to the new room after creation (and without co-creator level).

Do you mean for setting the room config for who-can-do-what? We could send that over the API too I guess - but do we use non-standard power levels anyway?