MSC2270: Proposal for Ignoring Invites #2270
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,47 @@ | ||||||
| # Proposal for ignoring invites | ||||||
|
There was a problem hiding this comment. This proposal sounds more like ignoring rooms rather than ignoring invites, and I guess could be used as a way to prevent being hotel-california-ed in a room. (Ignore the room, and then even if the server thinks you're in the room, it won't send you any events from it.) There was a problem hiding this comment. It feels like there is potential for more damage to be caused by ignoring a join vs an invite, just because there is an expectation on the remote side that you are actually present. I can see users easily confusing themselves with thinking they have left because the room no longer shows up, because they hit some friendly looking button. Not to mention the bridge consequences for not leaving cleanly.. This proposal should not be considered anything close to a fix/workaround for people being stuck in rooms. There was a problem hiding this comment. I thought a bunch more about this a few months ago, and realised that the problem of "ignore this invite" or "ignore this room" or even "ignore this user" could be handled much more generically and powerfully via antiabuse tooling rather than continuing to bolt adhoc APIs onto the matrix spec like the one proposed here (complete with the many limitations it has which are listed below). In other words, the user could publish a "i don't like this room" to their personal MSC #2313 reputation list, and then their server subscribed to that list using something like Mjolnir's https://github.com/t2bot/synapse-simple-antispam can go and pick it up and block the undesired content for them. This can then trivially extend to empowering the user to filter out any content for any reason, and we have most of the building blocks already. Right now they using custom APIs, but we can start there and then MSC them later as a more generic thing rather than bolting on stuff like cc @Yoric thoughts? |
||||||
|
|
||||||
| ## Problem | ||||||
|
|
||||||
| There is currently no way to ignore an invite in Matrix without explicitly | ||||||
| rejecting it and informing the inviter of the rejection. There are many social | ||||||
| situations where a user may want to silently ignore the invite instead. | ||||||
|
|
||||||
| The closest you can currently get is to ignore the user who sent the invite - | ||||||
| but this will then ignore all activity from that user, which may not be | ||||||
| desirable. | ||||||
|
|
||||||
| ## Solution | ||||||
|
There was a problem hiding this comment. Unclear on semantics:
There was a problem hiding this comment.
|
||||||
|
|
||||||
| Currently we support ignoring users by maintaining an `m.ignored_user_list` event in | ||||||
| account_data, as per https://matrix.org/docs/spec/client_server/r0.5.0#id189. | ||||||
|
|
||||||
| We could do also silently ignore rooms (including invites) with an equivalent | ||||||
|
There was a problem hiding this comment. The language here suggests that this is an alternative solution and not the proposal, which I don't believe is the intent?
Suggested change
|
||||||
| `m.ignored_room_list` event, with precisely the same semantics but listing | ||||||
| room IDs rather than user IDs. | ||||||
|
|
||||||
| ## Tradeoffs | ||||||
|
|
||||||
| * We're limited to ~65KB worth of room IDs (although we could change the | ||||||
| limits for account_data 'events', given they're more freeform JSON than | ||||||
| events) | ||||||
|
There was a problem hiding this comment. It looks like this limit is already only enforced on room and state events but not account data. |
||||||
| * We waste initial sync bandwidth with account_data info for ignored rooms | ||||||
| which we may never care about ever again. | ||||||
| * The list will grow unbounded over time (unless the user occasionally | ||||||
| unignores and explicitly rejects the invites), especially if invite spam | ||||||
| accelerates. | ||||||
| * We could instead have a dedicated API for this: | ||||||
| * `PUT /user/{userId}/ignore/{txnId}` | ||||||
| * `PUT /rooms/{roomId}/ignore/{txnId}` | ||||||
| * `GET /user/{userId}/ignore` | ||||||
| * `GET /rooms/{roomId}/ignore` | ||||||
| * `GET /ignore` (for querying the current lists) | ||||||
| * ...and a custom block in `/sync` responses to synchronise ignore changes | ||||||
| * ...except it feels that yet another custom API & custom response block | ||||||
| is even more complicated and clunky than making account_data a bit more | ||||||
| flexible. | ||||||
| * Alternatively, we could extend `/leave` with a `silent` parameter of some kind, | ||||||
| and rely on the invitee's HS to track these 'silent' leaves and ignore the | ||||||
| room on behalf of the invitee. However, it may be nice to let the user track | ||||||
| ignored invites cross-client so they can undo if necessary, which account_data | ||||||
| gives us for free. Plus semantically it seems a bit wrong to use `/leave` | ||||||
| to describe the act of ignoring an invite, when you're not actually leaving it. | ||||||
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.