From 1ccfe60931de5fea87a6bf25721122f23916e80b Mon Sep 17 00:00:00 2001 From: Peter Gervai Date: Thu, 29 May 2025 11:03:29 +0200 Subject: [PATCH 1/5] Add ignore invites proposal. --- proposals/0666-ignore-invites.md | 64 ++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 proposals/0666-ignore-invites.md diff --git a/proposals/0666-ignore-invites.md b/proposals/0666-ignore-invites.md new file mode 100644 index 00000000000..024a551099a --- /dev/null +++ b/proposals/0666-ignore-invites.md @@ -0,0 +1,64 @@ +# MSC0666: Ignore and mass ignore invites + + +## Proposal + + +### Introduction + +Invite spam is getting more problematic and clients have no good way to handle massive invite spamming without server support. + +**Ignoring** users seem to help this but it has two serious problems: + +- completely igoring users make them completely disappear for the user, and if the user is also a moderator/adminstrator it makes impossible to detect and handle further abuse +- servers are not _required_ to clean up [invites] after ignored users (by the spec). + +**Rejecting ignores** also creates problem for clients: + +- Invite rejections are _room based_, so when a user is invited to massive amount of rooms by `spammer` then rejections require numerous `leave` API calls +- API calls are rate limited so massive rejections may be impossible without seriously disturbing user communication +- There are no mass invite rejection feature based on `sender` + +This proposal suggests a separate ignore for invites, and proposes compulsory server cleanup of invites, giving one solution for all of the listed problems. + +### Proposed solution + +Ignores are currently handled by `m.ignored_user_list` (`account_data` [APIs](https://spec.matrix.org/v1.14/client-server-api/#put_matrixclientv3useruseridaccount_datatype)). + +Current spec only handles `ignored_users` list. + +I propose to have it extended by `ignored_inviters` list the following way: + +- the type is `m.ignored_inviters_list` +- it is a mapping of userId to empty object, similar to `ignored_users` +- the limit of the amount of the entries shall follow the same guidelines as `ignored_users` + +#### Server behaviour + +- Following an update of the `m.ignored_user_list`, the sync API for all clients should immediately start ignoring (or un-ignoring) all invites from all the listed users. +- Servers are **required** to reject all pending invites from all the ignored users. +- Servers could choose to provide a boilerplate `reason` for rejection (but see security considerations below) + +## Potential issues + +When the server doesn't support this feature it should give appropriate error to the client, and the client have to handle that. + +Clients should be aware of the success of the ignore somehow since they need a method to clear pending invited from the user UI. The method should be the same as for `ignored_users`. + +This proposal does not handle rejection of all future invites. + +This proposal does not handle rejection of future invites of various logical classification, like "invites from actors not sharing a room with the user", "invites from actors matching a pattern or regex", "invites from actors on a given server". These are often requested features but would make this proposal much more complex, which would slow down its acceptance. These could be covered in a later proposal. + +## Alternatives + +Manual rejection, hitting rate limits, losing connection, spam invites piling up. Sadness. + +## Security considerations + +This function is fuctionally similar to `ignore_users`, any security consideration there may apply here. + +When a server autorejects invites on the user behalf it may choose to include a boilerplate `reason` for the rejection. However this would cause an unnecessary information leak towards the abuser (informing whether the server provides mass ignore or not), so choosing to have an absent `reason` may be prudent, this way it is indistinguishable from manual rejections. This proposal provides no way for the user to provide a `reason` field, which may or may not cause discomfort. + +## Unstable prefix + +This proposal use the already established `m.ignored_user_list` feature, extending its functionality. From ce4afa13a0b076bdfac006a0d56af2601845a631 Mon Sep 17 00:00:00 2001 From: Peter Gervai Date: Thu, 29 May 2025 11:06:42 +0200 Subject: [PATCH 2/5] Rename file to PR number. --- proposals/{0666-ignore-invites.md => 4294-ignore-invites.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{0666-ignore-invites.md => 4294-ignore-invites.md} (100%) diff --git a/proposals/0666-ignore-invites.md b/proposals/4294-ignore-invites.md similarity index 100% rename from proposals/0666-ignore-invites.md rename to proposals/4294-ignore-invites.md From 4907dbc6272aef524ed1221bd5a25bfe103229ff Mon Sep 17 00:00:00 2001 From: Peter Gervai Date: Thu, 29 May 2025 11:11:31 +0200 Subject: [PATCH 3/5] Rename doc internal title Now that I know the number. --- proposals/4294-ignore-invites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4294-ignore-invites.md b/proposals/4294-ignore-invites.md index 024a551099a..710d2479327 100644 --- a/proposals/4294-ignore-invites.md +++ b/proposals/4294-ignore-invites.md @@ -1,4 +1,4 @@ -# MSC0666: Ignore and mass ignore invites +# MSC4294 Ignore and mass ignore invites ## Proposal From 52c5d9bc3e276c8ced14dc34534855466994f0b4 Mon Sep 17 00:00:00 2001 From: Peter Gervai Date: Thu, 29 May 2025 11:18:34 +0200 Subject: [PATCH 4/5] MSC4294: specifying relation between ignore and ignored_inviters Better phrasing to distinguish between generic ignore and invite ignore. Server behaviour specified. --- proposals/4294-ignore-invites.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/4294-ignore-invites.md b/proposals/4294-ignore-invites.md index 710d2479327..d914987d196 100644 --- a/proposals/4294-ignore-invites.md +++ b/proposals/4294-ignore-invites.md @@ -1,9 +1,7 @@ # MSC4294 Ignore and mass ignore invites - ## Proposal - ### Introduction Invite spam is getting more problematic and clients have no good way to handle massive invite spamming without server support. @@ -27,7 +25,7 @@ Ignores are currently handled by `m.ignored_user_list` (`account_data` [APIs](ht Current spec only handles `ignored_users` list. -I propose to have it extended by `ignored_inviters` list the following way: +I propose to have it extended by **`ignored_inviters`** list the following way: - the type is `m.ignored_inviters_list` - it is a mapping of userId to empty object, similar to `ignored_users` @@ -36,7 +34,7 @@ I propose to have it extended by `ignored_inviters` list the following way: #### Server behaviour - Following an update of the `m.ignored_user_list`, the sync API for all clients should immediately start ignoring (or un-ignoring) all invites from all the listed users. -- Servers are **required** to reject all pending invites from all the ignored users. +- Servers are **required** to reject all pending invites from all the ignored inviter users. - Servers could choose to provide a boilerplate `reason` for rejection (but see security considerations below) ## Potential issues @@ -49,6 +47,8 @@ This proposal does not handle rejection of all future invites. This proposal does not handle rejection of future invites of various logical classification, like "invites from actors not sharing a room with the user", "invites from actors matching a pattern or regex", "invites from actors on a given server". These are often requested features but would make this proposal much more complex, which would slow down its acceptance. These could be covered in a later proposal. +`ignored_users` and `ignored_inviters` may overlap. It seems to be logical to remove already completely ignored users from `ignored_inviters`, however this would cause loss of information, since when the user unignores someone then their invites would be automagically unignored as well. Servers **should not** deduplicate and let the clients decide how they handle this situation and what interface they provide to the users to handle this. Internally, servers should ignore processing `ignored_inviters` for already ignored users at all. + ## Alternatives Manual rejection, hitting rate limits, losing connection, spam invites piling up. Sadness. From b68209bd2e63a26934110eb584d1e38756d9127e Mon Sep 17 00:00:00 2001 From: Peter Gervai Date: Thu, 29 May 2025 11:23:26 +0200 Subject: [PATCH 5/5] Update 4294-ignore-invites.md Typo fix. --- proposals/4294-ignore-invites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4294-ignore-invites.md b/proposals/4294-ignore-invites.md index d914987d196..c62fab01f72 100644 --- a/proposals/4294-ignore-invites.md +++ b/proposals/4294-ignore-invites.md @@ -8,7 +8,7 @@ Invite spam is getting more problematic and clients have no good way to handle m **Ignoring** users seem to help this but it has two serious problems: -- completely igoring users make them completely disappear for the user, and if the user is also a moderator/adminstrator it makes impossible to detect and handle further abuse +- completely ignoring users make them completely disappear for the user, and if the user is also a moderator/adminstrator it makes impossible to detect and handle further abuse - servers are not _required_ to clean up [invites] after ignored users (by the spec). **Rejecting ignores** also creates problem for clients: