| 19 Aug 2025 |
Gnuxie 💜🐝 | i think this comment is taken straight from a discussion we had a few days ago in matrix-spec and otherwise meow | 15:55:24 |
Charles | i don't think policy servers are allowed to influence room state (i.e. membership) so not quite | 15:55:52 |
Charles | i am not in the matrix spec room because it has been on room version FOUR forever | 15:56:34 |
emily | someone keeps reverting it | 16:00:57 |
@aloisw:julia0815.de | Probably would be a step in the right direction, but availability when the moderation bot is down is also bad. | 16:28:38 |
emily | the homeserver can arrange to not have availability when the moderation bot is down | 16:29:05 |
emily | so that seems fine | 16:29:15 |
@aloisw:julia0815.de | True but at that point why have a bot at all instead of just baking a moderation interface in. | 16:33:52 |
emily | well, you could do precisely that with a homeserver that owns a room, right? | 16:35:42 |
emily | it would be authoritative for the room's state, so it can do whatever it wants | 16:35:53 |
@aloisw:julia0815.de | Yes, that's a necessary but not sufficient condition. | 16:38:18 |
emily | hm, what's insufficient about "the homeserver decides what the room state is and all changes are gated on it" to implement whatever moderation functionality you want? | 16:40:53 |
Gnuxie 💜🐝 | well a policy server is a way of doing that | 16:41:16 |
Gnuxie 💜🐝 | as for why | 16:41:17 |
Gnuxie 💜🐝 | it's because these are not things you can half ass after the fact | 16:41:25 |
Gnuxie 💜🐝 | which is what would happen if it was a mandated part of homeserver impleemntations | 16:41:36 |
Gnuxie 💜🐝 | it allows the "community management" implementation to be separate to the homeserver. Which is important because homeserver implementations are already very complicated and they would all be providing something that is subpar | 16:43:44 |
Gnuxie 💜🐝 | it's also quite annoying when people think that "moderation" is just something trivial that can be hacked up and included by homeserver implementors in like two minutes | 16:45:43 |
@aloisw:julia0815.de | It needs to actually do that. However it seems I misunderstood you and thought you were only talking about the user list but that was an earlier discussion. | 16:46:26 |
emily | FWIW my assumption was that a homeserver-that-is-authoritative-for-a-room would delegate to a moderation bot implementation via a protocol of some kind (maybe even just reusing the existing Matrix one, letting the bot see state changes "early" and decide what to do about them before they get published) | 16:47:31 |
emily | rather than implementing that stuff itself | 16:47:41 |
emily | (well, sure. presumably homeserver implementations would all need to change to support this new room type with totally different ("no") state resolution logic, anyway) | 16:48:12 |
@aloisw:julia0815.de | That was my assumption too, the "moderation interface" does not need to mean that the moderation policy needs to be implemented in the homeserver, but there should be some privileged interface providing a reasonable mechanism. | 16:49:14 |
@aloisw:julia0815.de | Homeservers actually implementing it is pretty much a hard requirement for actually having a new room type in practice, yes. | 16:50:43 |
| 20 Aug 2025 |
| @federicodschonborn:matrix.org changed their profile picture. | 01:06:53 |
@emma:rory.gay | you can already achieve this with policy servers, minus the availability thing | 10:41:41 |
@emma:rory.gay | this is the entire point of a policy server, but currently they dont scale very well as every server needs to ask the policy server whether an event is allowed (and this only result in soft failure) | 10:44:14 |
emily | the availability is kinda the whole point | 10:44:28 |
@emma:rory.gay | fwiw, there's work from Element's side to make policy servers be able to be authoritative in a future room version | 10:45:06 |
@emma:rory.gay | so we can get rid of the "fail open" semantics they currently have (the current idea being that the origin server has to get a signature from the room's policy server to even commit the event to the DAG) | 10:46:16 |