feat: Policy-list controlled moderation

Jade commented

2025-04-14 21:15:18 +00:00

Owner

We currently have configurable server-wide moderation options that allow completely hiding a server and refusing all federation with it.

It would be useful to allow controlling these options from a Matrix room policy list at runtime.

We currently have configurable server-wide moderation options that allow completely hiding a server and refusing all federation with it. It would be useful to allow controlling these options from a Matrix room policy list at runtime.

nex added a new dependency 2025-04-14 21:22:24 +00:00

#751 feat: appservice callbacks

nex referenced this issue

2025-04-14 21:23:03 +00:00

feat: appservice callbacks #751

nex added the

Enhancement

Matrix/Administration

labels 2025-04-14 23:40:31 +00:00

nex changed title from ~~Policy-list controlled moderation~~ to feat: Policy-list controlled moderation

2025-04-15 00:36:41 +00:00

Jade commented

2025-04-16 14:31:20 +00:00

Author

Owner

Some key points of the discussion for those who can't access it:

I bring up that existing user-level and room-level moderation tools in Matrix are insufficient to handle issues like spam and abusive media, as any level of exposure to some media is unnaceptable
Server-side filtering of messages and invites is brought up
The problem of the spec providing no way to re-add filtered messages to the timeline (particularly problematic in syncv3) is brought up (effectively if something is un-ignored server side, clients require a full resync to be able to see previously hidden events. Not a problem for some stuff, more problematic for other stuff)
Some concerns about servers soft-failing events causing desync. Not a problem for denying outbound federation and media, though.
Talking about per-user server-side policy lists (IMO no-priority for us right now)
There's a bunch of discussion about server plugins for moderation, https://github.com/maunium/synapse-http-antispam is brought up

Some key points of the discussion for those who can't access it: - I bring up that existing user-level and room-level moderation tools in Matrix are insufficient to handle issues like spam and abusive media, as any level of exposure to some media is unnaceptable - Server-side filtering of messages and invites is brought up - The problem of the spec providing no way to re-add filtered messages to the timeline (particularly problematic in syncv3) is brought up (effectively if something is un-ignored server side, clients require a full resync to be able to see previously hidden events. Not a problem for some stuff, more problematic for other stuff) - Some concerns about servers soft-failing events causing desync. Not a problem for denying outbound federation and media, though. - Talking about per-user server-side policy lists (IMO no-priority for us right now) - There's a bunch of discussion about server plugins for moderation, https://github.com/maunium/synapse-http-antispam is brought up

nex commented

2025-04-16 14:33:11 +00:00

Owner

See also: #748, #751

nex commented

2025-04-16 19:00:16 +00:00

Owner

Relevant: https://github.com/matrix-org/matrix-spec-proposals/pull/4284

Jade referenced this issue from a commit

2025-04-19 22:33:20 +00:00

refactor: Centralize server forbidden checks into moderation module

Jade referenced this issue from a commit

2025-04-19 22:36:43 +00:00

refactor: Centralize server forbidden checks into moderation module

Jade referenced this issue from a commit

2025-04-19 22:38:02 +00:00

refactor: Centralize server forbidden checks into moderation module

nex commented

2025-04-21 15:55:28 +00:00

Owner

Discussion held in the dev room:

If the server already has a member in the policy rooms, it already receives relevant events - it'd make more sense to tap rooms rather than have a dedicated subscriber
might be helpful to start with room bans and takedowns as they'll be the easiest to implement

Discussion held in the dev room: * If the server already has a member in the policy rooms, it already receives relevant events - it'd make more sense to tap rooms rather than have a dedicated subscriber * might be helpful to start with room bans and takedowns as they'll be the easiest to implement

nex commented

2025-04-22 01:43:55 +00:00

Owner

Would also be neat to be able to refuse to authorise joins for users or homeservers who are denied by policy lists, similar to what Tulir's fi.mau.spam_checker join rule does, except globally.

Would also be neat to be able to refuse to authorise joins for users or homeservers who are denied by policy lists, similar to what Tulir's `fi.mau.spam_checker` join rule does, except globally.

Jade commented

2025-04-22 01:52:18 +00:00

Author

Owner

We already refuse make_join for forbidden servers, controlled by the same check as the rest of the federation controls

🎉 1

Rows
Columns

feat: Policy-list controlled moderation #750