MSC3840: Ignore invites #3840
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,67 @@ | ||
| # MSC3840: Ignoring invites | ||
Yoric marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Matrix supports an event "m.ignored_user_list" to entirely ignore some users. | ||
|
|
||
| In some cases, ignoring the user is the wrong granularity, e.g. we may wish to: | ||
|
There was a problem hiding this comment. It might be good if this proposal could mention #2270 as prior art on the same topic. |
||
|
|
||
| - ignore invites to rooms entirely; | ||
| - ignore invites from some servers entirely. | ||
|
|
||
| While both features are pretty easy to implement client-side, standardizing how this preference | ||
| is stored as part of the account is necessary to make sure that users can share this ignore list | ||
| across devices and sessions. | ||
|
|
||
| ## Proposal | ||
|
|
||
|
|
||
| Matrix currently supports a type `m.ignored_users_list` with content: | ||
|
|
||
| | Content | Type | Description | | ||
| |---------|------|-------------| | ||
| | `ignored_users` | A maps of user ids to `{}` | A list of users to ignore | | ||
|
|
||
|
|
||
| We adopt a similar `m.ignored_invites` with content: | ||
|
There was a problem hiding this comment. this looks very close to what a policy room offers. We could adapt this sort of account data to support a list of policy rooms which the server can inspect for rules and apply them on behalf of the user. If needed, the user/client could also create a private policy room to share with the server via account data to hold some of the personal rules. Future extensions would be adding recommendations for There was a problem hiding this comment. So, to achieve feature-parity with this proposal, we would need:
Right? On the downside, it's going to be harder to implement and slower, but on the upside it's going to be more orthogonal and extensible. I can write the spec for that. There was a problem hiding this comment. I think you just need point 1. Point 2 isn't really needed, and point 3 adds complexity we might not be comfortable with introducing here (it adds time). There was a problem hiding this comment. I don't understand your reasoning:
The way I see it, if anything, point 1 is the one that we could live with for a MVP. There was a problem hiding this comment. Opened a variant at #3847 building upon your idea. There was a problem hiding this comment.
|
||
|
|
||
| | Content | Type | Description | | ||
| |---------|------|-------------| | ||
| | `ignored_user_ids` | optional `string[]` | Ignore invites from these users. | | ||
| | `ignored_servers` | optional `string[]` | Ignore invites from users in these homeservers. | | ||
| | `ignored_room_ids` | optional `string[]` | Ignore invites towards these rooms. | | ||
|
|
||
| ### Client behaviour | ||
|
|
||
| If a user modifies `m.ignored_invites`, discard silently any matching pending invite | ||
| currently displayed. | ||
|
|
||
| ### Server behaviour | ||
|
|
||
| Wherever the server could filter out an event because of a `m.ignored_users_list`: | ||
| - if the event is an invite; and | ||
| - if `m.ignored_invites` is present in the recipient user's account; and | ||
| - if the issuer is part of `ignored_user_ids` or the issuer is an account on `ignored_servers` or the invite room is part of `ignored_room_ids`, then filter out the event silently. | ||
|
|
||
|
|
||
| The behavior of both client and server is expanded to also ignore any event issued from a server | ||
| in `ignore_servers` wherever we would ignore an event from a user in `ignore_users`. | ||
|
|
||
| ## Potential issues | ||
|
|
||
| There is a risk that the list of ignored invites of some users may grow a lot, which might have | ||
| performance impact, both during initial sync and during filtering. We believe that this risk is | ||
| limited. If necessary, clients may decide to cleanup ignored invites after some time. | ||
|
|
||
|
There was a problem hiding this comment. This solution seems to make it quite hard to review invites that have been "ignored", how does the client review ignored invites? There was a problem hiding this comment. My personal take on it is that each client may additionally cache a list of individual event_ids for invites that have been ignored, without needing to share it. But now that you mention it, this probably doesn't make sense, as we want to ignore invites across all devices/sessions. Patching. There was a problem hiding this comment. So, the latest version adds |
||
| ## Alternatives | ||
|
|
||
| Can't think of any right now. | ||
|
|
||
| ## Security considerations | ||
|
|
||
| Can't think of any right now. | ||
|
|
||
| ## Unstable prefix | ||
|
|
||
| During testing, `m.ignored_invites` should be prefixed `org.matrix.msc3840.ignored_invites`. | ||
|
|
||
| Fields `ignored_user_ids`, `ignored_servers`, `ignored_room_ids` of this new event should remain unprefixed. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall: Based on #4192, I feel as though this MSC would be best positioned as an extension to #4155 rather than being a dedicated mechanism (for the parts that aren't already covered).