Draft: MSC3215: Aristotle - Moderation in all things #3215
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,264 @@ | ||
| # MSC3215: Aristotle: Moderation in all things | ||
|
|
||
| On large public channels (e.g. Matrix HQ), we have too many users abusing the room: | ||
| - Spammers | ||
| - Bullies | ||
| - Invite spammers | ||
| - ... | ||
|
|
||
| The Matrix community doesn't have enough moderators to handle all of this, in particular during | ||
| weekends/outside of office hours. | ||
|
|
||
| In an ideal world, we should not need to rely upon human moderators being awake to react to | ||
| such abuse, as many users tend to report these types of abuse very quickly. One could imagine, | ||
| for instance, that if 25 long-standing users of Matrix HQ report the same message of a new | ||
| user as spam, said user will be banned temporarily or permanently from the room and/or the | ||
| server as a spammer. | ||
|
|
||
| This proposal does NOT include a specific policy for kicking/banning. Rather, it redesigns the abuse | ||
| reporting mechanism to: | ||
|
|
||
| - decentralize it; | ||
| - produce formatted data that can be consumed by bots to decide whether action should be taken | ||
| against a user. | ||
|
|
||
| This proposal redesigns how abuse reports are posted, routed and treated to make it possible to | ||
| use bots to react to simple cases. | ||
|
|
||
| The expectation is that this will allow the Matrix community to experiment with bots that deal | ||
| with abuse reports intelligently. | ||
|
|
||
|
|
||
| ## Proposal | ||
|
|
||
| Matrix specs offer a mechanism to report abuse. In this mechanism: | ||
|
|
||
| 1. a user posts an abuse report for an event; | ||
| 2. hopefully, the homeserver administrator for the user's homeserver will handle the abuse report. | ||
|
|
||
| In the current state, this mechanism is insufficient: | ||
|
|
||
| 1. If the abuse report concerns an event in an encrypted room, the homeserver administrator typically | ||
| does not have access to that room, while a room moderator would, hence cannot act upon that report. | ||
| 2. Many homeserver administrators do not wish to be moderators, especially in rooms in which they | ||
| do not participate themselves. | ||
| 3. As the mechanism does not expose an API for reading the abuse reports, it is difficult to experiment | ||
| with bots that could help moderators. | ||
| 4. As the mechanism is per-homeserver, reports from two users of the same room that happen to have accounts | ||
| on distinct homeservers cannot be collated. | ||
| 5. There is no good mechanism to route a report by a user to a moderator, especially if they live on different | ||
| homeserver. | ||
|
|
||
|
|
||
| This proposal redesigns the abuse report spec and suggested behavior as follows: | ||
|
|
||
| - Any room can opt-in for moderation. | ||
| - Rooms that opt-in for moderation have a moderation room (specified as a state event). These moderation | ||
| rooms may be shared between several rooms and there may be a default moderation room for a homeserver. | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Posting an abuse report on a specific event from a room with moderation sends a data message to the | ||
| moderation room. | ||
| - As there may still be a need to report entire rooms, the current abuse report API remains in place for | ||
| reporting entire rooms, although it is expected that further MSCs will eventually deprecate this API. | ||
|
There was a problem hiding this comment. Reporting an entire room to a room moderator probably doesn't make too much sense. I suppose reporting these to admins of homeservers that are in the room is the better route? There was a problem hiding this comment. The idea is that, for the time being, we keep the reporting API, reporting only to our homeserver admin and we'll work on improving this in future MSCs. |
||
|
|
||
| While this is not part of the MSC, the expectation is that the community may start experimenting with bots that | ||
| can be invited to moderation rooms act upon abuse reports: | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - a bot could pick these data messages and turn them into human-readable reports including context | ||
| and buttons to let moderators easily ignore/kick/ban/redact; | ||
| - a bot could collate reports, ignore those from recently registered users, and decide to kick/ban | ||
| reported users if some threshold is exceeded; | ||
| - ... | ||
|
|
||
| ### Invariants | ||
|
|
||
| - Each room MAY have a state event `m.room.moderated_by`. If specified, this is the room ID towards which | ||
| abuse reports MUST be sent. As rooms may be deleted `m.room.moderated_by` MAY be an invalid room ID. | ||
| A room that has a state event `m.room.moderated_by` supports moderation. | ||
|
|
||
| ```jsonc | ||
| { | ||
| "state_key": "m.room.moderated_by", | ||
| "type": "m.room.moderated_by", | ||
| "content": { | ||
| "room_id": XXX, // The room picked for moderation. | ||
|
There was a problem hiding this comment. I fail to see the purpose of this room. IIUC users never actually use this room, they likely don't even have access. There was a problem hiding this comment. Probably to couple with ban lists as rooms. There was a problem hiding this comment.
The entire room or specifying the room ID in the state event? If the former, well, we need to send abuse reports somewhere. The current abuse API has them sent to a proprietary admin API. We replace this with a standard room. At this stage, it's up to users and tooling to decide what they do with it. If the latter, the client needs a way to find where to post the abuse reports. There was a problem hiding this comment. Here I am talking about in the state event.
Please elaborate, I thought they just talked to the bot. There was a problem hiding this comment.
The bot is just a delivery mechanism to send a message to the Moderation Room. The same bot may be used by several Moderation Rooms. So we need both the userID of the bot (to talk to it) and the roomID of the Moderation Room (to tell it where to send the message). There was a problem hiding this comment. Why doesn't the bot have a mapping from source room to destination. There was a problem hiding this comment. Using field Yes, this could work, too, if we require the bot to be stateful. I believe that the best way to do it, though, is to keep rooms themselves the source of truth, rather than some bot memory. There was a problem hiding this comment. I see. Does this mean that the bot has to peek into the "community room" to see where it should send the report to? Or is the bot expected to be part of that room already? There was a problem hiding this comment. In the current status of the MSC, the user's client copies this value There was a problem hiding this comment. Ah, I missed that. It still feels weird to me that we need to expose this to the user but I'll consider this resolved until I have a better idea what to do here. |
||
| "user_id": XXX, // The bot in charge of forwarding reports to `room_id`. | ||
|
There was a problem hiding this comment. Why enforce that there is a bot? This seems to be over-complicated. Why not just provide a list of users that should be invited to a report room? This could be a bot, or it could just be the room admin(s). This way the use of a bot is not mandated. This also has a number of advantages, such as maybe one of the admins is causing the issue, the user could choose to exclude that user (this benefit is lost in the case of a bot, but at least it is allowed in some cases). Furthermore the user can use E2EE if they know the admin's keys. This removes an extra set of keys that need to be dealt with. It is also much simpler, especially for the case of a small team of admins that manage a room or two. Now they don't need to set up rooms, bots or anything. Yet they are still prepared if a (rare) abuse report comes in. In fact I would even consider that clients recommend reporting to the users of highest power-level in the room if this event is not present, this means that there is some sort of reasonable route for reporting abuse even if the room moderators haven't considered that abuse may concern. (People generally don't think about these issues until they happen) The process then becomes:
At that point that report may be handled by the bot listed in the There was a problem hiding this comment. The main reason for there being a bot is that Matrix does not offer a built-in mechanism for users who are not member of a room (in this case, the Moderation Room) to post events towards that room. The bot is the simplest routing mechanism that I can think of. If I read correctly your counter-proposal, it does not address this (rather fundamental) issue.
Good idea. We can definitely add this as a suggestion in the MSC if the state events are not setup.
What's the "reporting room"? If it's what I call the Community Room, receiving abuse reports in the same room as they were sent leads to immediate deanonymization of the reporters. There was a problem hiding this comment.
It does address it, but it does effectively sidestep it. It allows you to use a bot which forwards to a room, or it lets you just use the room that the user created to send the report. It puts the choice to the moderation team.
I mean the room the reporter created with the bot. Let me summarize the flow you are requiring in this MSC.
That is a completely reasonable report flow. However it seems overly specified. There are many other valid moderation workflows that don't need or want this complexity. Especially if you have a smallish community abuse reports will be rare. So having a dedicated mod room for discussion is probably not necessary. And in many communities the mods may want to keep the separate reports in different rooms for organization. Also keep in mind that for many (probably most) communities the "mod team" is one person. So copying the abuse report to $modroom is quite pointless. It just lets that one mod discuss with themselves. What I am suggesting is that we just drop everything about the bot and the moderation room from this MSC. It can still be implemented, but it leaves each mod team free to implement their own workflow and leaves room for different bots that work differently (and leaves room for no bot at all). In this case the MSC becomes
This way we have a standardized method for reporting abuse. But the actual workflow for handling it is still flexible. It is totally valid to use a bot as suggested in this MSC to copy the report to a moderation room, however that is optional, not required. This has a number of advantages in my mind.
TL;DR I don't see the benefit of mandating the bot and its behaviour. There was a problem hiding this comment. Where does the reporter send the abuse report in your counter-proposal? To a userID as specified in If I understand correctly, you're splitting the MSC in two. The bot and moderation room are still necessary in many (most?) cases but remain unspecified. Essentially, we're losing the specification for
A few notes on this:
Well, that's possible with either variant. The main difference in this specific scenario is that the Moderation Room allows more than one bot to operate. More generally, I believe that the true difference between your proposal and mine is that in yours, the abuse endpoint is a user (which may optionally connect to a Moderation Room, etc.) while in mine, the abuse endpoint is a room (which may optionally connect to users, etc.)
I believe that I understand your point and that I understand the point of minimizing. If I were to go this way, though, I'd probably come back with a MSC for the bot pretty soon :) There was a problem hiding this comment.
Yes. You could have a
Basically. I see a lot of value to specifying how the client reports abuse, but I'm not so convinced that the "report management" workflow that you have proposed is sufficient for all use cases, furthermore I don't see as much value in standardizing it. So I think it makes sense to get the reporting flow through. Then we can consider management workflows later if we find value in standardizing it.
But who is expected to run the bot? Is it to be built into every homeserver?
Why can't this just be done by the client for the non-bot case?
In this case we would probably want a bot because with a lot of reports new rooms for each new report may be undesirable. So set My point here is that the bot workflow works even without being part of the spec. Each mod team can use a bot that works for them instead of mandating a single bot that implements one workflow.
That sounds fine to me. If you can justify the value of specifying the bot I am all ears :) There was a problem hiding this comment.
I believe that neither proposal solves that scenario, because of the difficulty of trusting DMs. I believe that this deserves its own MSC. I also believe that both proposal allow for such experimentation (especially since each proposal can easily be extended into the other proposal :) ).
Agreed on the summary.
Good point. Unfortunately, I believe that we have reached a stage at which this conversation has stopped progressing. We both have arguments that make sense, we each appreciate the other's arguments, but I feel that continuing this thread will simply block everything. So, to summarize:
For these reasons, I believe that continuing work on this MSC more or less as is (i.e. my proposal) does not harm your proposal and should yield clear benefits in terms of both enabling experimentation (including experimentation on your proposal) and aiding the fight against abuse. Therefore, I'm planning to:
Does this make sense? There was a problem hiding this comment. I think the point that you are missing is that I think specing out the "second half" right now of this MSC is (mildly) harmful. I agree that what I am proposing is a subset of yours. But I think that it makes sense to start with that subset. Most importantly I am still do not see the benefits that you see in specifying the "second half". If there is no benefit of nailing something down in the spec then I think it is best not to specify it to avoid unnecessary restrictions that may come back to bite us down the road. Would it help if I put forward a stripped down version of this and we can consider deferring this for now?
It isn't clear that your proposal can be cleanly cut down to the minimal version. Could you clarify roughly the tweaks that you would make? It is just changing the bot name to a MXID or list of MXID?
Yes, that is why I am suggesting pushing out the "first half". Then you can write the bot and use it for these communities. This looks like the fastest path to me and avoids adding technical debt. So to be clear this is the plan that I think makes the most sense:
Again, if you can specify clear reasons why the MSC would be worse without specifying the behaviour of the bot then I think it can go ahead. But reading back I still don't see any reasons why the bot needs to be specified. I have only see "big communities will need it". That statement may well be true but that doesn't mean that it needs to be specified. My preferred subset allows using a bot, and it may well be the case that all users would use a bot, but unless there is a downside to removing the bot from the proposal then I think we should. Simpler is better. There was a problem hiding this comment. I'm ok with reducing the MSC to its first half and keeping the second half as an illustration of a possible workflow. Before experimentation, I'm not ok with specifying that the client must be able to display abuse reports or that we can specify several targets in Does this work for you? There was a problem hiding this comment. A few additions:
There was a problem hiding this comment. That sounds good.
Then we can consider things like a fallback with extensible events in the future or mandating the bot. For now we can assume that anyone who ads the metadata has a way to read the reports.
Can we cut down the middle for now and say that it must be a list of one element? That way we don't need to break the API to allow multiple recipients. What is your objection to allowing multiple? It doesn't seem to cause any issues in my mind.
That sounds good. We can also consider adding back There was a problem hiding this comment. Having a single bot for routing moderation reports is a clear single point of failure, as if the server running the bot goes down, no moderator from any server will be able to receive reports. |
||
| } | ||
| // ... usual fields | ||
| } | ||
| ``` | ||
|
|
||
| - Each room MAY have state events `m.room.moderator_of`. A room that has a state event `m.room.moderation. | ||
|
|
||
| ```jsonc | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| { | ||
| "state_key": "m.room.moderation.moderator_of.XXX", // XXX is the ID of the Community Room, i.e. the room being moderated. | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| "type": "m.room.moderation.moderator_of", | ||
| "content": { | ||
| "user_id": XXX, // The bot in charge of forwarding reports to this room. | ||
| } | ||
| // ... usual fields | ||
| } | ||
| ``` | ||
|
|
||
| ### Client behavior | ||
|
|
||
| #### Opting in for moderation | ||
|
|
||
| When a user Alice creates a room ("the Community Room") or when a room moderator accesses the Community Room's configuration, | ||
| they MAY opt-in for moderation. When they do, they MUST pick a Moderation Room. The Client SHOULD check that: | ||
| - the Moderation Room is a room in which Alice has a powerlevel sufficient for sending messages; | ||
|
There was a problem hiding this comment. Why does Alice need to be able to send messages in the moderation room? What if people configure their moderation room to be a read-only stream of reports (disabling users other than the bot user from sending messages). There was a problem hiding this comment. Actually, I should have written "events" instead of "messages".
Do you think I'm missing something? |
||
| - the Moderation Room has a state event `m.room.moderation.moderator_of`. | ||
|
|
||
| If Alice has opted-in for moderation, mased on the Moderation Room's Room ID and `m.room.moderation.moderator_of`, the Client | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| MUST create a state event `m.room.moderated_by` (see above) in the Community Room. | ||
|
|
||
| Similarly, if a moderator has opted in for moderation in a Community Room, a moderator MAY opt out of moderation for that | ||
| Community Room. This is materialized as deleting `m.room.moderated_by`. | ||
|
|
||
| #### Rejecting moderation | ||
|
|
||
| A member of a Moderation Room may disconnect the Moderation Room from a Community Room by removing state event | ||
| `m.room.moderation.moderator_of.XXX`. This may serve to reconfigure moderation if a Community Room is deleted | ||
| or grows sufficiently to require its dedicated moderation team/bots. | ||
|
|
||
| #### Reporting an event | ||
|
|
||
| Any member of a Community Room that supports moderation MAY report an event from that room, by sending a `m.abuse.report` event | ||
| with content | ||
|
|
||
| | field | Description | | ||
| |----------|-------------| | ||
| | event_id | **Required** id of the event being reported. | | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| | room_id | **Required** id of the room in which the event took place. | | ||
| | moderated_by_id | **Required** id of the moderation room, as taken from `m.room.moderated_by`. | | ||
| | nature | **Required** The nature of the event, see below. | | ||
| | comment | Optional. String. A freeform description of the reason for sending this abuse report. | | ||
|
|
||
| `nature` is an enum: | ||
|
|
||
| - `m.abuse.disagreement`: disagree with other user; | ||
| - `m.abuse.toxic`: toxic behavior, including insults, unsollicited invites; | ||
| - `m.abuse.illegal`: illegal behavior, including child pornography, death threats,...; | ||
| - `m.abuse.spam`: commercial spam, propaganda, ... whether from a bot or a human user; | ||
| - `m.abuse.room`: report the entire room, e.g. for voluntarily hosting behavior that violates server ToS; | ||
| - `m.abuse.other`: doesn't fit in any category above. | ||
|
|
||
| We expect that this enum will be amended by further MSCs. | ||
|
|
||
| The rationale for requiring a `nature` is twofold: | ||
|
|
||
| - a Client may give to give a users the opportunity to think a little about whether the behavior they report truly is abuse; | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - this gives the Client the ability to split between | ||
| - `abuse.room`, which should be routed to an administrator (in the current MSC, using the existing moderation API); | ||
| - `abuse.disagreement`, which may better be handled by blurring messages from offending user; | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - everything else, which needs to be handled by a room moderator or a bot. | ||
|
|
||
| To send an `m.abuse.report`, the Client posts the `m.abuse.report` message as DM to the `user_id` specified in the | ||
| `m.room.moderated_by`. | ||
|
|
||
| This proposal does not specify behavior when `m.room.moderated_by` is not set or when the `user_id` doesn't exist. | ||
|
|
||
| ### Built-in routing bot behavior | ||
|
|
||
| Users should not need to join the moderation room to be able to send `m.abuse.report` messages to it, as it would | ||
| let them snoop on reports from other users. Rather, we introduce a built-in bot as part of this specification: the | ||
| Routing Bot. This Routing Bot is part of the server and has access to priviledged information such as room membership. | ||
|
There was a problem hiding this comment. Again, i think this is a bad idea when the focus of matrix wants to shift away from servers and onto users and rooms, maybe specify that such a bot can either be server-controlled or "self-hosted", and it'll solve a lot of problems down the line (such as the "permissions bot" in #2962 which both needs to be verifiable in a decentralized manner, but also built-into every server it'll touch) State that the bot can be any valid matrix user, then it only has to follow below behaviour to be "acceptable" as a cog in this MSC. Note that this is a point of centralisation, though i think this is less of a problem than requiring built-in server bots There was a problem hiding this comment. Not sure I follow what you're suggesting. I've removed the "privileged" part, though. |
||
|
|
||
| 1. When the Routing Bot is invited to a room, it always accepts invites. | ||
|
There was a problem hiding this comment. (I'm writing this regardless of the status of the MSC in case it gets picked up again later by someone else, even if that's in another form.) It would be really useful for the client to give the room a distinct type. Currently in Mjolnir (which has a partial implementation of the routing bot) this behaviour is problematic as it clashes with the There was a problem hiding this comment. I wouldn't be happy with a solution that requires a bot on my homeserver joining all rooms it's invited into. This seems too abusable. I want my server only participating in rooms that my users explicitly joined. |
||
| 2. When the Routing Bot receives a message other than `m.abuse.report`, it ignores the message. | ||
|
There was a problem hiding this comment. To be clear, this is an event with type There was a problem hiding this comment. Right, it's a message event with type |
||
| 3. When the Routing Bot receives a message _M_ with type `m.abuse.report` from Alice: | ||
| - If the Routing Bot is not a member of _M_`.moderated_by_id`, reject the message. | ||
| - If Alice is not a member of _M_.`room_id`, reject the message. | ||
| - If room _M_.`moderated_by_id` does not contain a state event `m.room.moderation.moderator_of.XXX`, where `XXX` | ||
| is _M_.`room_id` | ||
| - Reject the message. | ||
| - Otherwise | ||
| - Call _S_ the above state event | ||
| - If _S_ does not have type `m.room.moderation.moderator_of`, reject the message. | ||
| - If _S_ is missing field `user_id`, reject the message. | ||
| - If _S_.`user_id` is not the id of the Routing Bot, reject the message. | ||
| - If event _M_.`event_id` did not take place in room _M_.`room_id`, reject the message. | ||
| - If Alice could not witness event _M_.`event_id`, reject the message. | ||
| - Copy the message to room _M_. | ||
|
|
||
|
|
||
| ### Possible Moderation Bot behavior | ||
|
|
||
| This section is provided as an illustration of the spec, not as part of the spec. | ||
|
|
||
| A possible setup would involve two Moderation Bots, both members of a moderation room _MR_. | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| - A Classifier Bot consumes `m.abuse.report` messages, discards messages from users who have joined recently or never | ||
| been active in the room (possible bots/sleeping bots), then collates reports against users. If there are more than | ||
| e.g. 10 reports in the last hour against a single user, post a `m.policy.rule.user` message in the same room specifying that the user | ||
| should undergo temporary ban. | ||
| - A Ban Bot consumes `m.policy.rule.user` messages and implements bans. | ||
|
|
||
| ## Security considerations | ||
|
|
||
| ### Routing | ||
|
|
||
| This proposal introduces a (very limited) mechanism that lets users send (some) events to a room without being part of that | ||
| room. There is the possibility that this mechanism could be abused. | ||
|
|
||
| We believe that it cannot readily be abused for spam, as these are structured data messages, which are usually not visible to members | ||
| of the moderation room. | ||
|
|
||
| However, it is possible that it can become a vector for attacks if combined with a bot that treats said structured data messages, | ||
| e.g. a Classifier Bot and/or a Ban Bot. | ||
|
|
||
| ### Revealing oneself | ||
|
|
||
| If a end-user doesn't understand the difference between `abuse.room` and other kinds of abuse report, there is the possibility | ||
| that this end-user may end up revealing themself by sending a report against a moderator or against the room to the very | ||
| moderators of that room. | ||
|
|
||
| ### Snooping administrators | ||
|
|
||
| Consider the following case: | ||
|
|
||
| - homeserver compromised.org is administered by an evil administrator Marvin; | ||
| - user @alice:compromised.org is a moderator of room _R_ with moderation room _MR_; | ||
| - user @bob:innocent.org is a member of room _R_; | ||
| - @bob:innocent.org posts an abuse report _AR_ to _MR_; | ||
| - Marvin may achieve access to the metadata on report _AR_, including: | ||
| - the fact that @bob:innocent.org has reported something to room _AR_; | ||
| - Marvin also has access to the metadata on _R_, including: | ||
| - the fact that _MR_ is the moderation room for _R_; | ||
| - the fact that @charlie:toxic.org was just banned from _R_; | ||
| - Marvin may deduce that @bob:innocent.org has reported @charlie:toxic.org. | ||
|
|
||
| It is not clear how bad this is. | ||
|
|
||
| It is also not clear how to decrease the risk. | ||
|
|
||
| ### Snooping bots | ||
|
|
||
| As bots are invited to moderation rooms, a compromised bot has access to all moderation data for that room. | ||
|
|
||
| ## Alternatives | ||
|
|
||
| ### MSC 2938 | ||
| MSC 2938 (by the same author) has previously been posted to specify a mechanism for reporting events to room moderators. The current MSC is considered | ||
| - more reliable (it does not need to roll out its own federation communication); | ||
| - less specialized/more general. | ||
|
|
||
| I am not aware of other proposals that cover the same needs. | ||
|
|
||
| ### Alternatives to the Routing Bot | ||
|
|
||
| The "knocking" protocol is an example of an API that lets users inject state events in a room in which they do | ||
| not belong. It is possible that we could follow the example of this protocol and implement a similar "abuse" API. | ||
|
|
||
| However, this would require implementing yet another new communication protocol based on PDUs/EDUs, including a | ||
| (small) custom encryption/certificate layer and another retry mechanism. The author believes that this would entail | ||
| a higher risk and result in code that is harder to test and trust. | ||
|
There was a problem hiding this comment. Thanks for including this - I see now that the weight that comes with this solution is not just a new API, but all the scaffolding that goes along with it (including message secrecy). There was a problem hiding this comment.
From what I can tell this is not currently part of the MSC, but it could be in the future. On the point against adding another handshake, I am not too sure as to what the problem is, as a certificate is not only not part of the MSC as it currently stands, but arguably isn't that useful, since any bad actor could spam reports for events they can see instead, which doesn't make a big difference to the moderators dealing with it. Not too sure what the trust and testing part is about though, since there is already a precedent for using handshakes to send state to rooms a server is not a part of, so the code to perform it would likely be not much of a new thing, especially when compared to creating the concept of a routing bot. |
||
|
|
||
| ## Unstable prefix | ||
|
|
||
| During experimentation | ||
|
|
||
| - `m.room.moderated_by` will be prefixed `org.matrix.msc3215.room.moderated_by`; | ||
| - `m.room.moderator_of` will be prefixed `org.matrix.msc3215.room.moderator_of`; | ||
| - `m.abuse.report` will be prefixed `org.matrix.msc3215.abuse.report`; | ||
| - `abuse.*` will be prefixed `org.matrix.msc3215.abuse.nature.*`. | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While probably not something which should be done in this proposal, extending this to spaces would be super useful. A room which is added as a child to a space with a moderation room set being required to also inherit that moderation room (and the ability for any bot to verify it's PL in the new room and remove the room from the space if it can't moderate it) would make it possible to have moderated spaces where many more people can be trusted to add new rooms to a space (like people can add channels to a slack team etc).