From b442e6cfb98bb939049f92f16e22542ab62599fd Mon Sep 17 00:00:00 2001 From: Rory& Date: Mon, 13 Oct 2025 23:33:46 +0200 Subject: [PATCH 1/2] Canonical ignore lists v1 --- proposals/9999-canonical-ignore-list-rooms.md | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 proposals/9999-canonical-ignore-list-rooms.md diff --git a/proposals/9999-canonical-ignore-list-rooms.md b/proposals/9999-canonical-ignore-list-rooms.md new file mode 100644 index 00000000000..6a9405b3e02 --- /dev/null +++ b/proposals/9999-canonical-ignore-list-rooms.md @@ -0,0 +1,86 @@ +# MSC999: Canonical ignore list rooms + +Keeping up with spam in ignore lists can be hard, and currently requires either a lot of manual labor +or thoughtfully designed bots to bridge policy lists with user's ignore lists. This has a chance to +majorly impact server performance at scale. I wish there was a better way to achieve this. + + +## Proposal + +I would like to propose adding a `ignored_user_list_rooms` property to `m.ignored_user_list`, to serve +as an "include"-list for Moderation Policies as they exist today. + +Some of you may already be familiar with a feature that works a lot like this: Element Web's +"New Ways To Ignore Users" Labs feature! + +I would like to have the server help out with this, and prevent clients from receiving the events +in the first place, as well as eliminating the need to use bot to achieve this behavior. + +Example of an updated `m.ignored_user_list`: +```diff +{ + "content": { + "ignored_users": { + "@someone:example.org": {} + }, ++ "ignored_user_list_rooms": { ++ "!fTjMjIzNKEsFlUIiru:neko.dev": { ++ "use_globs": true, ++ "use_server_bans": true, ++ "use_banned_rooms": true, ++ "apply_retroactively": true ++ } ++ } + }, + "type": "m.ignored_user_list" +} +``` + +You may notice these additional properties in the schema, that may not make it into the final version of this MSC. +All of these are optional: +- `use_globs`: Whether to enable parsing globs, as commonly used in policy lists. These can be a performance hazard. +- `use_server_bans`: Whether to also ignore users matched by a `m.policy.rule.server` policy. +- `use_banned_rooms`: Whether to automatically leave rooms banned by a given policy list (including invites). +- `apply_retroactively`: Whether clients should explicitly remove locally cached messages upon a new policy being written. + +To follow a banlist, the user MUST be a joined member of the policy list. This allows servers to always have at least +one local member in the room. + +I would RECOMMEND that clients consider hiding events from users ignored through a policy list retroactively, +as policy list maintainers or server administrators may wish use this mechanic as a way to hide or remove illegal +content content, or content that otherwise violates the homeserver's Terms Of Service/Acceptable Use Policy. + +## Potential issues + +Clients that do clientside filtering for cached messages may not scale very well with this, and will need to be updated +to handle enforcing policy lists. + +## Alternatives + +- Keep using a bot for this. Clients that filter their local timeline with the ignored users list will have performance +ramifications if banlists are being imported with >10k policies (see eg. #community-moderation-effort-bl:neko.dev). + +- Implement the bot solution as part of clients. This will cause synchronisation issues as they all race to update the +ignored user list. + +- Do the bridging server side by expanding `ignored_users`. This has the same performance ramifications as the previous +2 alternatives, as clients aren't being expected to explicitly handle the case of having 10k+ ignore list entries. + +## Security considerations + +I did not find anything relevant in the OWASP TOP 10. + +Thinking logically, there is two ways this could be exploited, that I personally would consider intentional: +- Servers may be adding a set of required ignore lists on behalf of users. This may be considered beneficial in order to +keep local users safe in accordance to local server policies. + +- Malicious policy list writers may cause mayhem by banning rooms or other users. It is up to the user to pick policy +lists to follow, that they themselves place trust in. + +## Unstable prefix + +`s/ignored_user_list_rooms/gay.rory.msc9999.ignored_user_list_rooms/` + +## Dependencies + +No known dependencies. \ No newline at end of file From 7c918e5525e681c412543a1ffb5ff8d705bada2e Mon Sep 17 00:00:00 2001 From: Rory& Date: Mon, 13 Oct 2025 23:35:34 +0200 Subject: [PATCH 2/2] MSC number --- ...nore-list-rooms.md => 4365-canonical-ignore-list-rooms.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename proposals/{9999-canonical-ignore-list-rooms.md => 4365-canonical-ignore-list-rooms.md} (97%) diff --git a/proposals/9999-canonical-ignore-list-rooms.md b/proposals/4365-canonical-ignore-list-rooms.md similarity index 97% rename from proposals/9999-canonical-ignore-list-rooms.md rename to proposals/4365-canonical-ignore-list-rooms.md index 6a9405b3e02..134d2a232c6 100644 --- a/proposals/9999-canonical-ignore-list-rooms.md +++ b/proposals/4365-canonical-ignore-list-rooms.md @@ -1,4 +1,4 @@ -# MSC999: Canonical ignore list rooms +# MSC4365: Canonical ignore list rooms Keeping up with spam in ignore lists can be hard, and currently requires either a lot of manual labor or thoughtfully designed bots to bridge policy lists with user's ignore lists. This has a chance to @@ -79,7 +79,7 @@ lists to follow, that they themselves place trust in. ## Unstable prefix -`s/ignored_user_list_rooms/gay.rory.msc9999.ignored_user_list_rooms/` +`s/ignored_user_list_rooms/gay.rory.msc4365.ignored_user_list_rooms/` ## Dependencies