-
Notifications
You must be signed in to change notification settings - Fork 401
MSC2270: Proposal for Ignoring Invites #2270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: old_master
Are you sure you want to change the base?
Conversation
@mscbot fcp merge |
This FCP proposal has been cancelled by #2270 (comment). Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people: Concerns:
Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
It would probably be nice to have this but I'd rather make the ignore function itself more granular. That way you could choose to hide all invites from a user but see messages (or muffle messages) or the opposite. See my thoughts earlier in https://github.com/matrix-org/matrix-doc/issues/1803 |
mm, i'd missed the muffling user idea. i don't think it's incompatible with this, though - just need to make sure that an object is handed to the user (or room) rather than just a blunt true/false... |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The language here suggests that this is an alternative solution and not the proposal, which I don't believe is the intent?
We could do also silently ignore rooms (including invites) with an equivalent | |
We could do also silently ignore rooms (including invites) with an equivalent |
but this will then ignore all activity from that user, which may not be | ||
desirable. | ||
|
||
## Solution |
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.
Unclear on semantics:
- Should the server mark the room as
left
down sync? - What should the client do? (obviously hide the room, but that should be spelled out)
- What should the client do when it sees the account data update? (see above)
- What happens when the user un-ignores a room?
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.
- please state what the client should do if
membership
!=invite
for a room in the list as above
@@ -0,0 +1,47 @@ | |||
# Proposal for ignoring invites |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -0,0 +1,47 @@ | |||
# Proposal for ignoring invites |
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.
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.
but this will then ignore all activity from that user, which may not be | ||
desirable. | ||
|
||
## Solution |
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.
- please state what the client should do if
membership
!=invite
for a room in the list as above
Cancelling FCP proposal as this MSC lacks an implementation. @mscbot fcp cancel |
@@ -0,0 +1,47 @@ | |||
# Proposal for ignoring invites |
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.
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 m.ignored_room_list
.
cc @Yoric thoughts?
|
||
* 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this limit is already only enforced on room and state events but not account data.
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.
Rendered