All things with moderation
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Teller, David
So you want to moderate your Matrix room, or perhaps your homeserver? You're in the right place. In this presentation, we'll talk about both the core concepts of federated moderation in Matrix and the main moderation tools. Expect to hear about power levels, redactions, quarantine, abuse reports, Mjölnir and plans for the near future!
 Hello, I'm Jorick, also known as David. I'm a Tech Lead at Element. I'm working on moderation tools for the Matrix Network. And I'm going to talk to you about moderation tools for the Matrix Network. So as you may have heard, Matrix is a federated distributed network that features, among other things, chat. There are some people around the net who seem to believe that it's impossible to do any kind of moderation on a federated network. So I'd like to show you some of the tools that are available to everyone to do moderation on a federated network right now. Before we do that, let's say a few words about moderation. Moderation is something that's defined by rules. In some rooms, say, you want to talk about politics and not sport. In some rooms, you want to talk about sport and not politics. In all rooms, you want to avoid being insulted and being spammed. Matrix itself is a protocol. It doesn't know anything about those rules. It's human beings who know about the rules. So what you can do is use a number of tools to block people and prevent people from doing any kind of such harm. A typical scenario of moderation is one in which users such as Alice Bob and Carla are happily chatting in a room and then comes in Marvin and Marvin wants to sell them all stinky French garlic spam. Nobody wants stinky French garlic spam, maybe. So what can they do from this point to avoid being inundated with stinky French garlic spam? We see several ways to approach this problem and starting with what can room moderators do and what are room moderators? As I mentioned, matrix is federated. Already precisely, matrix is, in some way, a distributed federated, appended only log of events. And everything, almost, is an event on this log. Which means when Alice creates the room, when Bob and Carla join the room, when Alice sends a message or changes her display name, everything of this is at least one message. Whenever Alice does something in the room, Alice sends an event to her home server. The home server performs a number of security checks. Is Alice really a member of the room? Has Alice been muted from that room? No, so then she can send things, probably. And then the home server propagates the event to other home servers that are part of that same room and then each home server sends the messages, after again security checks, to the members of the room, to the clients for each member of the room so that they can display accordingly, for instance, the new display name for Alice. So messages look like this. Look like bunch of JSON. In this specific case, well, messages have a type, a sender. In that specific case, there is a display name of Alice. There is an event ID, et cetera. Now one of these events is really important for our conversation. It's power levels. Power levels are part of the configuration of the room, but that everything else, they are events. A power event associates a number to each user. Here Alice has a number of 100 in that room. Good. Other users have a power level of zero. That's the minimum, 100 being the maximum. And what do those numbers do? Well they give you the right to perform a number of actions. For instance, if you have a power level greater than 50, you can ban or kick or redact. If you have a power level of zero, you can invite. If you have a power level of 100, you can change how encryption works, et cetera. Changing power levels itself requires a sufficiently high power level. So once users have the right power level, here Alice has a power level of 100. That's higher than the minimal power level to be able to kick or ban. So she's going to be able to kick or ban Marvin. So you will probably not be surprised to see that kicking or banning are events. That's Alice sending a kick against Marvin. So Marvin is going to leave the room. As previously, Alice sends the event to her home server. Home server checks that she has the correct power level in that specific room, as she does the home server updates her list, its list of members of the room, sends the, propagates the event to other home servers who perform the same checks, update similarly the list of members in the room, and then send those messages back to users so that they can show that the user, that is, Marvin has been kicked. After having dealt with the immediate threat of Marvin sending spam, the next step is removing spam. This is called redaction. Any user can delete, that is, redact their old messages. And if you have a sufficiently high power level, you can redact the messages of other users in that room. That's again an event which specifies which message is being redacted and why we are redacting it and who redacted it. And the message for new users try to download the history of the room because they're connecting or they want new updates. We are going to see a message that is empty and that has been redacted because, well, for the reason that has been provided earlier. Again, this is propagated using the previous mechanisms for sending events across the Federation. One more thing that the moderator could do is set up a server ACL. Maybe Marvin is coming from a bad home server that serves specifically to send spam. In that case, an ACL, so a server access control list set in that room, will inform all the home servers that the room is not interested in receiving messages from that evil.com server. Similarly, those ACLs can be used for security reasons. Maybe you're dealing with confidential data and you want to be sure that nobody invites someone from the outside accidentally. In that case, you want maybe to say that only the local home server can access this room. That can be very useful. All these tools are very powerful, but there are many things that unfortunately they cannot do. In those cases, we need to leave the convenient nice federated world of room moderation and enter the much less convenient word of home server administration. Well, unfortunately, home server administration is not standard. It's a set of APIs that are defined by home server implementations. I don't know how all of them work. I can tell you about the Synapse implementation. I'd be surprised if other home servers were very different. But that's a big limitation. So in Synapse, if you want to become an administrator, either you are in the process of setting up Synapse, you can do some shared secret shenanigans and become an administrator. Or if there is already an administrator, they can turn someone else into an administrator. Once you're an administrator, you have access to these server administration APIs. They're all documented on the documentation of Synapse. So I'm not going to walk through all of them. I'm going to show you some of the key APIs that are very useful for moderation purposes. Typically, two of them are about deactivating accounts. You want to get rid of, maybe of Marvin, maybe not just in this room, but if Marvin is a spam bot, you want to get rid of Marvin on the entire home server. And either you want to inform Marvin that the account has been terminated, that's deactivating it, or you want to hide this from Marvin to prevent them from spam, to prevent them from spawning a new spam bot. You may want to quarantine media. If some images typically or movie has been uploaded to your server and it's something really ugly or something illegal in your country, there are chances that you do not want anybody to download it from your server. You could have lots of trouble with the law if you let people download illegal stuff from your server. You can also block or delete room, but I should specify that this is again not nicely federated even based things. These are all local APIs. When you deactivate an account, you deactivate this account on your server. If it's an account from another home server, that has no effect. If you quarantine media, you can only prevent users from downloading it from your home server. If it's on another home server, nothing happens. If you block or delete room, you prevent your users from being part of the conversation. But if another home server is part of the conversation already, this is going to have no effect on them. There is one more critical form of duration, API, that is home server admin only. That is a big problem, but I'm going to show you later why it's not that bad. It's abuse reporting. So if Clara, when saying that Marvin is spamming everyone, tries to call for help, by clicking on the report button. If she knows that Alice is the moderator and she can get in touch with Alice, very well. But let's say that she cannot and that she's rather clicking on the report button. What happens is that the home server administrator for Clara's home server is going to be informed of the problem. So there are two reasons for which that's actually not what you want. The first reason is that this administrator is typically not a member of the room in which all of these bad things happen. Since they're not a member of the room, unless the room is public, well, this administrator is not going to be able to see whether anything has happened. And the administrator doesn't know whether Marvin is malicious or whether Clara is malicious. And so the administrator cannot take any useful action. Moreover, the administrator is not part of the room. So the administrator cannot actually kick, ban, mute, redact in that room. So typically, the wrong person is receiving this abuse report. That's a problem. And we're going to see as soon as we can solve it. And to give you more detail, this is what a user report looks like. It gets you an event ID and a room ID, which are useful if you are already a member of the room and can take a look at the content, completely useless otherwise, a reason provided by Clara, and a user ID and a date. That's not nearly sufficient to take action. Before showing you more details about that, I'm going to mention something else about HomeServer administration. If you have access to the HomeServer itself, you can go beyond administration by inserting PlugableModules. Synapse is highly scriptable. You can write PlugableModules to do many kinds of things, including enabling or disabling registrations based on arbitrary reasons, such as whether the registration comes from a well known to be bad IP, for instance, or keywords, anything. You can deal with federation with servers, federate, defederation, etc. You can inspect the contents of messages to reject links that are known to be bad, or messages that contain bad keywords, etc. But all of this is subject to the same limitations mentioned previously. The server does not have access to the content of encrypted rows. So that's a huge limitation. And of course, other limitation is it's not federated. Again, it's HomeServer admin style. So this only has an impact on your home server. So a part of the solution to the problems we mentioned is called Mjölnir. Mjölnir is a bot dedicated to helping moderators and to exposing moderation features in a convenient way. Well, setting up Mjölnir can take a few steps. You have to deploy it, create a moderation room, invite Mjölnir to the moderation room, invite Mjölnir to the community rooms, make Mjölnir a moderator in the community rooms, optionally make it admin, optionally set up reverse proxy. But what's that is done, you have access to a whole host of features. This is just a subset of the features. If you want to have the full list, please run Mjölnir help. But to summarize, Mjölnir will help you. It gathers a number of rooms, sorry, the moderation of a number of rooms behind a moderation room. So any member of that moderation room, no has access to the Mjölnir. There is the moderation tools for the other rooms. So any member of the moderation room can kick-band, redact, ignore, mute, etc. Bad users from any of the moderated rooms, which is highly convenient. It also lets you set up room protections such as not letting new users upload images, for instance, or sounds, etc. You can implement room policy lists, which are basically supercharged server ACLs. If Mjölnir is an administrator, you can use it also to use in a convenient way the administration APIs. And then there is this abuse tracker. So the abuse tracker is one of the most exciting recent features of Mjölnir. It's something that replaces the ugly JSON that you did not actually have access to, because you are not the home server administrator, by something like this. This is a human-rable abuse report. It contains all the details you need. If Mjölnir was a member of the room in which the event took place, then it even contains the content of the event that is being reported. And it even has a click-based user interface to conveniently ban mute, redact, kick, or ignore the message. This is much better than the admin-based solution, and this does not require the non-standard admin API. So even better. It's not the end of the story. I'm going to tell you more about it in a few seconds. So after having spoken of recent improvements, let me tell you of a few future additions to the ecosystem of tools. Let me tell you about the future. The future is coming. One of the things I'm most excited about at the moment, one of the things we're working on, is that we're moving towards decentralizing moderation as much as possible. Moving from something that requires home server admin APIs and home server admins to take part, to something that in a very convenient way will hopefully soon let people spawn community rooms and moderation rooms without having to deal with MuirNir configuration shenanigans, and in which attach community rooms to existing moderation rooms, and perform moderation actions from the moderation rooms, again, extending what MuirNir is doing already, but in a much more lightweight way. And every step we take in this direction is going to be useful, not just because it makes things easier, but also because it makes things more standard, and also because it makes things more compatible for the day we finally move to matrix P2P. But that's not all. We're working on many things. One of the things we're working on at the moment right now is to phase moderation, in which moderators can immediately mark something as suspect, hide it from users, and then debate whether they should remove it or reinstate it. So undo, basically. We're improving room protections and how they can be set up and customized. We're improving the user interface from MuirNir. We are working towards distributed trust by the concept of sharing policies between rooms, between servers, between users, et cetera. Hopefully, within a few months, the ecosystem of moderation will be way, way more powerful and easier to use, and I'm really excited about that. So I hope that I have convinced you that while moderated, federated communications isn't trivial, there are many tools and they can be used already to create effects. More tools are coming, and I'd like to thank you for having listened to this presentation. If you have any questions, I am all ears and happy to answer them. Thank you. This... Looks like we went live bitterly. So we have a few questions to answer. The first one and the most upvoted one is, can a malicious home server ignore a kick event and stay in the room? The... So, yes and no. The home server can try and ignore it if it's not receiving messages from the other servers. It's not going to be useful for it much. I'm going to mention that I have currently problem with sound, so please excuse me if I... What I say sounds like nonsense. So let me rephrase. Assume we have a community of home servers. One of them is malicious and decides to ignore kick events. If there is only one user from that home server and that user gets kicked or banned, the other home servers are just going to stop sending federation messages to that home server. And then, well, the user will not be able to receive anything. On the other hand, if the malicious home server has several user accounts that participate in this room, all the user accounts receive the messages and the home server can decide to maliciously forward the messages that were intended from one user to the other user. So this works because Matrix keeps a local copy of the room. So if we have another user, it's possible for the home server administrator to still read those messages and to potentially send them to the user that was kicked. We have another question, which is about Povalovs. So right now, Povalovs are numbers, I think they are supposed to be integers, but I'm not sure. I think there is a MSC to fix that in the spec. But let's say they are supposed to be integrated between zero and 100. So if the last person in the room who was PL100 demos themselves to say PL50, nobody can get PL100 anymore? So I would need to double check that. But it's not about being able to PL somebody to a number higher all over than you. It's whether you have the authorization to send a Povalovs event. So if nobody has the Povalovs sufficient to send Povalovs events, you're stuck and nobody will be able to change Povalovs. All right, so you don't have an administrator who can take over the room and put it back to the PL100 state. But how much trust do you need to have in a home server administrator? What can a home server administrator do? What can they not do? Your home server administrator can do a lot of bad things if they want to, at least in non-encrypted rooms. In non-encrypted rooms, there isn't much that they could do. In an encrypted room, they could do a few things, but that's basically joining the room and leaving the room, basically. Possibly a few minor things, et cetera. But yeah, that's an annoyance. That's a problem we have, and that's one of the reasons why we want to decrease the abilities of admin APIs, although that will not entirely solve the issue. And that's one of the reasons why we want to move towards P2P. It looks like P2P is going to solve a lot of issues. So people have really seen, seem to have appreciated the Mjolnir demo and your pronunciation of Mjolnir. I think, I don't know if I'm pronouncing it correctly. And one of the cool things about Mjolnir is those little buttons you have below. So right now, this is just reactions. Instead of reacting with an emoji, you send an emoji and a text. Is it possible? Do you think we could have proper buttons in the future? I hope so. I don't know if anybody is working on that right now. I know that we have projects to do it, but it's not the highest priority, I think. And it's a cool thing to have, but we'd rather have better moderation tools first. Talking of better moderation tools, we have a question, which is, are there any automated moderating process like this morning? There had been a spam wave with massive amounts of mentions. This could be detected automatically. Do we have tools to work in that direction? So we have many experiments in progress towards doing that. Mjolnir has a few automated moderating processes right now, and we are in the process of expanding them, but we're also playing with many other mechanisms. One thing I didn't mention is that all the things we're doing towards moving towards decentralized moderation also are good ways to plug in bots that could implement any kind of policy you want. Again, Mjolnir comes in with a number of policies, but the idea is to make it easy for people to implement their own. Greg, in the previous talk, mentioned that communities could defend each other, thanks to Federation, I guess. So can you expand a little on how it works today? And you covered a bit that in your talk, but what are the limitations of that? Do we have a way to finally discriminate, for example, if I'm banning somebody because of spam, or if I'm banning them because of conduct violations? So I'm afraid I could not hear everything you said because of my sound issues, so I'm going to answer the part I understood. If you want to ask something else, please write it down. So there are already mechanisms largely implemented by Mjolnir to share some policies between servers, for instance. If, say, evil.com is a malicious home server and it's well known to be used by spammers, there are mechanisms so that you can post information in a room and have Mjolnir on your home server subscribe to that room to be able to download this information. And there is no centralized policy for this. So your Mjolnir can subscribe to many rooms. You can post to many rooms. So it's a form already of federated defense of distributed trust. And basically we want to add more things like this and make it more fine-grained. I don't quite understand the context of the question that was asked. So there is no good mechanism that I know of right now to discriminate between... No, sorry, that's actually false. You can actually discriminate between COC violations, spam, etc. In terms of blocklists, you can have different blocklists, one for COC, one for terms of service, etc. But not all the tools will be necessarily able to understand that. And when you just ban someone, there is no magic thing that knows why you have banned someone. So I guess to follow up on that question, various communities should probably have at least two lists, one for spam bans and one for COC violations because they have different COC. And it should be fairly safe to subscribe to other communities spam blocklists. We are running a bit low on time. We have 15 seconds left. So I suggest that people move to the All Things With Moderation Room to ask more questions and we'll move on to the next talk. Thank you very much. Thank you.
 Hello, I'm Jorick, also known as David.  I'm a Tech Lead at Element.  I'm working on moderation tools for the Matrix Network.  And I'm going to talk to you about moderation tools for the Matrix Network.  So as you may have heard, Matrix is a federated distributed network that features, among other  things, chat.  There are some people around the net who seem to believe that it's impossible to do any  kind of moderation on a federated network.  So I'd like to show you some of the tools that are available to everyone to do moderation  on a federated network right now.  Before we do that, let's say a few words about moderation.  Moderation is something that's defined by rules.  In some rooms, say, you want to talk about politics and not sport.  In some rooms, you want to talk about sport and not politics.  In all rooms, you want to avoid being insulted and being spammed.  Matrix itself is a protocol.  It doesn't know anything about those rules.  It's human beings who know about the rules.  So what you can do is use a number of tools to block people and prevent people from doing  any kind of such harm.  A typical scenario of moderation is one in which users such as Alice Bob and Carla are  happily chatting in a room and then comes in Marvin and Marvin wants to sell them all  stinky French garlic spam.  Nobody wants stinky French garlic spam, maybe.  So what can they do from this point to avoid being inundated with stinky French garlic  spam?  We see several ways to approach this problem and starting with what can room moderators  do and what are room moderators?  As I mentioned, matrix is federated.  Already precisely, matrix is, in some way, a distributed federated, appended only log  of events.  And everything, almost, is an event on this log.  Which means when Alice creates the room, when Bob and Carla join the room, when Alice sends  a message or changes her display name, everything of this is at least one message.  Whenever Alice does something in the room, Alice sends an event to her home server.  The home server performs a number of security checks.  Is Alice really a member of the room?  Has Alice been muted from that room?  No, so then she can send things, probably.  And then the home server propagates the event to other home servers that are part of that  same room and then each home server sends the messages, after again security checks,  to the members of the room, to the clients for each member of the room so that they can  display accordingly, for instance, the new display name for Alice.  So messages look like this.  Look like bunch of JSON.  In this specific case, well, messages have a type, a sender.  In that specific case, there is a display name of Alice.  There is an event ID, et cetera.  Now one of these events is really important for our conversation.  It's power levels.  Power levels are part of the configuration of the room, but that everything else, they  are events.  A power event associates a number to each user.  Here Alice has a number of 100 in that room.  Good.  Other users have a power level of zero.  That's the minimum, 100 being the maximum.  And what do those numbers do?  Well they give you the right to perform a number of actions.  For instance, if you have a power level greater than 50, you can ban or kick or redact.  If you have a power level of zero, you can invite.  If you have a power level of 100, you can change how encryption works, et cetera.  Changing power levels itself requires a sufficiently high power level.  So once users have the right power level, here Alice has a power level of 100.  That's higher than the minimal power level to be able to kick or ban.  So she's going to be able to kick or ban Marvin.  So you will probably not be surprised to see that kicking or banning are events.  That's Alice sending a kick against Marvin.  So Marvin is going to leave the room.  As previously, Alice sends the event to her home server.  Home server checks that she has the correct power level in that specific room, as she  does the home server updates her list, its list of members of the room, sends the, propagates  the event to other home servers who perform the same checks, update similarly the list  of members in the room, and then send those messages back to users so that they can show  that the user, that is, Marvin has been kicked.  After having dealt with the immediate threat of Marvin sending spam, the next step is removing  spam.  This is called redaction.  Any user can delete, that is, redact their old messages.  And if you have a sufficiently high power level, you can redact the messages of other  users in that room.  That's again an event which specifies which message is being redacted and why we are redacting  it and who redacted it.  And the message for new users try to download the history of the room because they're connecting  or they want new updates.  We are going to see a message that is empty and that has been redacted because, well,  for the reason that has been provided earlier.  Again, this is propagated using the previous mechanisms for sending events across the Federation.  One more thing that the moderator could do is set up a server ACL.  Maybe Marvin is coming from a bad home server that serves specifically to send spam.  In that case, an ACL, so a server access control list set in that room, will inform all the  home servers that the room is not interested in receiving messages from that evil.com server.  Similarly, those ACLs can be used for security reasons.  Maybe you're dealing with confidential data and you want to be sure that nobody invites  someone from the outside accidentally.  In that case, you want maybe to say that only the local home server can access this room.  That can be very useful.  All these tools are very powerful, but there are many things that unfortunately they cannot do.  In those cases, we need to leave the convenient nice federated world of room moderation and  enter the much less convenient word of home server administration.  Well, unfortunately, home server administration is not standard.  It's a set of APIs that are defined by home server implementations.  I don't know how all of them work.  I can tell you about the Synapse implementation.  I'd be surprised if other home servers were very different.  But that's a big limitation.  So in Synapse, if you want to become an administrator, either you are in the process of setting up  Synapse, you can do some shared secret shenanigans and become an administrator.  Or if there is already an administrator, they can turn someone else into an administrator.  Once you're an administrator, you have access to these server administration APIs.  They're all documented on the documentation of Synapse.  So I'm not going to walk through all of them.  I'm going to show you some of the key APIs that are very useful for moderation purposes.  Typically, two of them are about deactivating accounts.  You want to get rid of, maybe of Marvin, maybe not just in this room, but if Marvin is a spam bot,  you want to get rid of Marvin on the entire home server.  And either you want to inform Marvin that the account has been terminated, that's deactivating it,  or you want to hide this from Marvin to prevent them from spam,  to prevent them from spawning a new spam bot.  You may want to quarantine media.  If some images typically or movie has been uploaded to your server and it's something  really ugly or something illegal in your country, there are chances that you do not  want anybody to download it from your server.  You could have lots of trouble with the law if you let people download illegal stuff from your server.  You can also block or delete room, but I should specify that this is again not nicely federated  even based things.  These are all local APIs.  When you deactivate an account, you deactivate this account on your server.  If it's an account from another home server, that has no effect.  If you quarantine media, you can only prevent users from downloading it from your home server.  If it's on another home server, nothing happens.  If you block or delete room, you prevent your users from being part of the conversation.  But if another home server is part of the conversation already,  this is going to have no effect on them.  There is one more critical form of duration, API, that is home server admin only.  That is a big problem, but I'm going to show you later why it's not that bad.  It's abuse reporting.  So if Clara, when saying that Marvin is spamming everyone, tries to call for help,  by clicking on the report button.  If she knows that Alice is the moderator and she can get in touch with Alice, very well.  But let's say that she cannot and that she's rather clicking on the report button.  What happens is that the home server administrator for Clara's home server is going to be informed  of the problem.  So there are two reasons for which that's actually not what you want.  The first reason is that this administrator is typically not a member of the room in which  all of these bad things happen.  Since they're not a member of the room, unless the room is public,  well, this administrator is not going to be able to see whether anything has happened.  And the administrator doesn't know whether Marvin is malicious or whether Clara is malicious.  And so the administrator cannot take any useful action.  Moreover, the administrator is not part of the room.  So the administrator cannot actually kick, ban, mute, redact in that room.  So typically, the wrong person is receiving this abuse report.  That's a problem.  And we're going to see as soon as we can solve it.  And to give you more detail, this is what a user report looks like.  It gets you an event ID and a room ID, which are useful if you are already a member of the  room and can take a look at the content, completely useless otherwise, a reason provided by Clara,  and a user ID and a date.  That's not nearly sufficient to take action.  Before showing you more details about that, I'm going to mention something else about  HomeServer administration.  If you have access to the HomeServer itself, you can go beyond administration by inserting  PlugableModules.  Synapse is highly scriptable.  You can write PlugableModules to do many kinds of things, including enabling or disabling  registrations based on arbitrary reasons, such as whether the registration comes from a well  known to be bad IP, for instance, or keywords, anything.  You can deal with federation with servers, federate, defederation, etc.  You can inspect the contents of messages to reject links that are known to be bad,  or messages that contain bad keywords, etc. But all of this is subject to the same limitations  mentioned previously.  The server does not have access to the content of encrypted rows.  So that's a huge limitation.  And of course, other limitation is it's not federated.  Again, it's HomeServer admin style.  So this only has an impact on your home server.  So a part of the solution to the problems we mentioned is called Mjölnir.  Mjölnir is a bot dedicated to helping moderators and to exposing moderation features in a  convenient way.  Well, setting up Mjölnir can take a few steps.  You have to deploy it, create a moderation room, invite Mjölnir to the moderation room,  invite Mjölnir to the community rooms, make Mjölnir a moderator in the community rooms,  optionally make it admin, optionally set up reverse proxy.  But what's that is done, you have access to a whole host of features.  This is just a subset of the features.  If you want to have the full list, please run Mjölnir help.  But to summarize, Mjölnir will help you.  It gathers a number of rooms, sorry, the moderation of a number of rooms behind a moderation room.  So any member of that moderation room, no has access to the Mjölnir.  There is the moderation tools for the other rooms.  So any member of the moderation room can kick-band, redact, ignore, mute, etc.  Bad users from any of the moderated rooms, which is highly convenient.  It also lets you set up room protections such as not letting new users upload images,  for instance, or sounds, etc.  You can implement room policy lists, which are basically supercharged server ACLs.  If Mjölnir is an administrator, you can use it also to use in a convenient way the administration APIs.  And then there is this abuse tracker.  So the abuse tracker is one of the most exciting recent features of Mjölnir.  It's something that replaces the ugly JSON that you did not actually have access to,  because you are not the home server administrator, by something like this.  This is a human-rable abuse report.  It contains all the details you need.  If Mjölnir was a member of the room in which the event took place,  then it even contains the content of the event that is being reported.  And it even has a click-based user interface to conveniently ban mute, redact, kick, or ignore the message.  This is much better than the admin-based solution, and this does not require the non-standard admin API.  So even better.  It's not the end of the story.  I'm going to tell you more about it in a few seconds.  So after having spoken of recent improvements, let me tell you of a few future additions to the ecosystem of tools.  Let me tell you about the future.  The future is coming.  One of the things I'm most excited about at the moment, one of the things we're working on,  is that we're moving towards decentralizing moderation as much as possible.  Moving from something that requires home server admin APIs and home server admins to take part,  to something that in a very convenient way will hopefully soon let people  spawn community rooms and moderation rooms without having to deal with MuirNir configuration shenanigans,  and in which attach community rooms to existing moderation rooms,  and perform moderation actions from the moderation rooms,  again, extending what MuirNir is doing already, but in a much more lightweight way.  And every step we take in this direction is going to be useful, not just because it makes things easier,  but also because it makes things more standard, and also because it makes things more compatible  for the day we finally move to matrix P2P.  But that's not all.  We're working on many things.  One of the things we're working on at the moment right now is to phase moderation,  in which moderators can immediately mark something as suspect, hide it from users,  and then debate whether they should remove it or reinstate it.  So undo, basically.  We're improving room protections and how they can be set up and customized.  We're improving the user interface from MuirNir.  We are working towards distributed trust by the concept of sharing policies between rooms,  between servers, between users, et cetera.  Hopefully, within a few months, the ecosystem of moderation will be way, way more powerful  and easier to use, and I'm really excited about that.  So I hope that I have convinced you that while moderated, federated communications isn't  trivial, there are many tools and they can be used already to create effects.  More tools are coming, and I'd like to thank you for having listened to this presentation.  If you have any questions, I am all ears and happy to answer them.  Thank you.  This...  Looks like we went live bitterly.  So we have a few questions to answer.  The first one and the most upvoted one is, can a malicious home server ignore a kick event  and stay in the room?  The... So, yes and no.  The home server can try and ignore it if it's not receiving messages from the other servers.  It's not going to be useful for it much.  I'm going to mention that I have currently problem with sound, so please excuse me if I...  What I say sounds like nonsense.  So let me rephrase.  Assume we have a community of home servers.  One of them is malicious and decides to ignore kick events.  If there is only one user from that home server and that user gets kicked or banned,  the other home servers are just going to stop sending federation messages to that home server.  And then, well, the user will not be able to receive anything.  On the other hand, if the malicious home server has several user accounts that participate  in this room, all the user accounts receive the messages and the home server can decide  to maliciously forward the messages that were intended from one user to the other user.  So this works because Matrix keeps a local copy of the room.  So if we have another user, it's possible for the home server administrator to still read  those messages and to potentially send them to the user that was kicked.  We have another question, which is about Povalovs.  So right now, Povalovs are numbers, I think they are supposed to be integers,  but I'm not sure.  I think there is a MSC to fix that in the spec.  But let's say they are supposed to be integrated between zero and 100.  So if the last person in the room who was PL100  demos themselves to say PL50, nobody can get PL100 anymore?  So I would need to double check that.  But it's not about being able to PL somebody to a number higher all over than you.  It's whether you have the authorization to send a Povalovs event.  So if nobody has the Povalovs sufficient to send Povalovs events,  you're stuck and nobody will be able to change Povalovs.  All right, so you don't have an administrator who can take over the room and put it back to  the PL100 state.  But how much trust do you need to have in a home server administrator?  What can a home server administrator do?  What can they not do?  Your home server administrator can do a lot of bad things if they want to,  at least in non-encrypted rooms.  In non-encrypted rooms, there isn't much that they could do.  In an encrypted room, they could do a few things,  but that's basically joining the room and leaving the room, basically.  Possibly a few minor things, et cetera.  But yeah, that's an annoyance.  That's a problem we have, and that's one of the reasons why we want to decrease the abilities  of admin APIs, although that will not entirely solve the issue.  And that's one of the reasons why we want to move towards P2P.  It looks like P2P is going to solve a lot of issues.  So people have really seen, seem to have appreciated the Mjolnir demo  and your pronunciation of Mjolnir.  I think, I don't know if I'm pronouncing it correctly.  And one of the cool things about Mjolnir is those little buttons you have below.  So right now, this is just reactions.  Instead of reacting with an emoji, you send an emoji and a text.  Is it possible?  Do you think we could have proper buttons in the future?  I hope so.  I don't know if anybody is working on that right now.  I know that we have projects to do it, but it's not the highest priority, I think.  And it's a cool thing to have, but we'd rather have better moderation tools first.  Talking of better moderation tools, we have a question, which is,  are there any automated moderating process like this morning?  There had been a spam wave with massive amounts of mentions.  This could be detected automatically.  Do we have tools to work in that direction?  So we have many experiments in progress towards doing that.  Mjolnir has a few automated moderating processes right now,  and we are in the process of expanding them, but we're also playing with many other mechanisms.  One thing I didn't mention is that all the things we're doing towards moving towards  decentralized moderation also are good ways to plug in bots that could implement any kind of policy  you want.  Again, Mjolnir comes in with a number of policies, but the idea is to make it easy for people to  implement their own.  Greg, in the previous talk, mentioned that communities could defend each other,  thanks to Federation, I guess.  So can you expand a little on how it works today?  And you covered a bit that in your talk, but what are the limitations of that?  Do we have a way to finally discriminate, for example, if I'm banning somebody because of spam,  or if I'm banning them because of conduct violations?  So I'm afraid I could not hear everything you said because of my sound issues, so I'm going to answer the part I understood.  If you want to ask something else, please write it down.  So there are already mechanisms largely implemented by Mjolnir to share some policies between servers, for instance.  If, say, evil.com is a malicious home server and it's well known to be used by spammers,  there are mechanisms so that you can post information in a room and have Mjolnir on your home server subscribe to that room to be able to download this information.  And there is no centralized policy for this.  So your Mjolnir can subscribe to many rooms. You can post to many rooms.  So it's a form already of federated defense of distributed trust.  And basically we want to add more things like this and make it more fine-grained.  I don't quite understand the context of the question that was asked.  So there is no good mechanism that I know of right now to discriminate between...  No, sorry, that's actually false. You can actually discriminate between COC violations, spam, etc.  In terms of blocklists, you can have different blocklists, one for COC, one for terms of service, etc.  But not all the tools will be necessarily able to understand that. And when you just ban someone, there is no magic thing that knows why you have banned someone.  So I guess to follow up on that question, various communities should probably have at least two lists, one for spam bans and one for COC violations because they have different COC.  And it should be fairly safe to subscribe to other communities spam blocklists.  We are running a bit low on time. We have 15 seconds left.  So I suggest that people move to the All Things With Moderation Room to ask more questions and we'll move on to the next talk.  Thank you very much.  Thank you.
matrix_moderation_0_3047.png matrix_moderation_3048_6839.png matrix_moderation_6840_6971.png matrix_moderation_6972_12323.png matrix_moderation_12324_12959.png matrix_moderation_12960_13199.png matrix_moderation_13200_13271.png matrix_moderation_13272_13727.png matrix_moderation_13728_13775.png matrix_moderation_13776_13823.png matrix_moderation_13824_13871.png matrix_moderation_13872_15563.png matrix_moderation_15564_16127.png matrix_moderation_16128_16187.png matrix_moderation_16188_16235.png matrix_moderation_16236_16571.png matrix_moderation_16572_19643.png matrix_moderation_19644_20315.png matrix_moderation_20316_20399.png matrix_moderation_20400_20555.png matrix_moderation_20556_20651.png matrix_moderation_20652_20903.png matrix_moderation_20904_22079.png matrix_moderation_22080_22331.png matrix_moderation_22332_22799.png matrix_moderation_22800_27155.png matrix_moderation_27156_35411.png matrix_moderation_35412_35879.png matrix_moderation_35880_36875.png matrix_moderation_36876_37691.png matrix_moderation_37692_38207.png matrix_moderation_38208_40163.png matrix_moderation_40164_42779.png matrix_moderation_42780_43151.png matrix_moderation_43152_43691.png matrix_moderation_43692_43943.png matrix_moderation_43944_45065.png