Skip to content
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

MSC2270: Proposal for Ignoring Invites #2270

Open
wants to merge 2 commits into
base: old_master
Choose a base branch
from
Open

Conversation

ara4n
Copy link
Member

@ara4n ara4n commented Aug 31, 2019

@ara4n ara4n added the proposal A matrix spec change proposal label Aug 31, 2019
@ara4n
Copy link
Member Author

ara4n commented Aug 31, 2019

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Aug 31, 2019

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.

@mscbot mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-merge labels Aug 31, 2019
@aaronraimist
Copy link
Contributor

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

@ara4n
Copy link
Member Author

ara4n commented Aug 31, 2019

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...

@turt2live turt2live changed the title MSC2270 Proposal for Ignoring Invites MSC2270: Proposal for Ignoring Invites Aug 31, 2019
@turt2live turt2live self-requested a review September 5, 2019 19:59
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
Copy link
Member

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?

Suggested change
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
Copy link
Member

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?

Copy link
Contributor

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

@turt2live
Copy link
Member

@mscbot concern Unclear on what the proposal is.
@mscbot concern Unclear on semantics.

@turt2live turt2live added this to Review stages in Client-server r0.6 proposals Sep 10, 2019
@@ -0,0 +1,47 @@
# Proposal for ignoring invites
Copy link
Member

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.)

Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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

@turt2live turt2live added the kind:feature MSC for not-core and not-maintenance stuff label Apr 20, 2020
@richvdh richvdh added this to Awaiting FCP ticks in Spec Core Team Backlog Sep 10, 2020
@anoadragon453 anoadragon453 added this to Ready for FCP ticks in Spec Core Team Backlog Sep 11, 2020
@anoadragon453 anoadragon453 moved this from Ready for FCP ticks to Awaiting SCT input in Spec Core Team Backlog Oct 2, 2020
@anoadragon453
Copy link
Member

anoadragon453 commented Oct 2, 2020

Cancelling FCP proposal as this MSC lacks an implementation.

@mscbot fcp cancel

@mscbot mscbot removed the proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. label Oct 2, 2020
@turt2live turt2live moved this from Awaiting SCT input to Temp column 001 in Spec Core Team Backlog Jun 8, 2021
@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
@@ -0,0 +1,47 @@
# Proposal for ignoring invites
Copy link
Member Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

7 participants