Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Ability to ignore invites #824

Closed
nadonomy opened this issue Sep 21, 2021 · 6 comments
Closed

Ability to ignore invites #824

nadonomy opened this issue Sep 21, 2021 · 6 comments
Labels
A-Invite O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Enhancement X-Spec-Changes

Comments

@nadonomy
Copy link

Your use case

What would you like to do?

Popular or prominent people on Matrix often get invites from people they don't want to or have no intention to ever accept. When rejecting an invite, the other party knows it's been rejected, which can cause aggravation.

How would you like to achieve it?

Have an 'Ignore' interaction alongside Accept & Reject, similar to the semantics of muting a phone call. It might be advantageous to:

  1. Have a way to re-discover a list of ignored invites so it doesn't turn into a de facto blocklist forever with no way out.
  2. Consider a 'Block' interaction instead.

Have you considered any alternatives?

No response

Additional context

No response

@nadonomy nadonomy added S-Major Severely degrades major functionality or product features, with no satisfactory workaround A-Invite T-Enhancement O-Occasional Affects or can be seen by some users regularly or most users rarely labels Sep 21, 2021
@novocaine
Copy link

novocaine commented Sep 22, 2021

The homeserver maintains the state of the invite as its part of room membership, see here:

https://matrix.org/docs/spec/client_server/r0.6.1#m-room-member

The following membership states are specified:

invite - The user has been invited to join a room, but has not yet joined it. They may not participate in the room until they join.
join - The user has joined the room (possibly after accepting an invite), and may participate in it.
leave - The user was once joined to the room, but has since left (possibly by choice, or possibly by being kicked).
ban - The user has been banned from the room, and is no longer allowed to join it until they are un-banned from the room (by having their membership state set to a value other than ban).
knock - This is a reserved word, which currently has no meaning.

The way rejection is handled is for the state to move from invite to leave

Screenshot 2021-09-22 at 13 22 07

So - any client side option to simply hide the request without flagging it has the issue that the decision won't be reflected on the server, which means the invites won't be cleared on other devices (e.g. mobile clients) and the decision won't persist across log out / login. So on re-login all the invites you've ever ignored would come flooding back.

Adding a membership state feels like it'd kind of miss the point because other clients can still observe it - so it's still apparent that the invite has been ignored from an API perspective. So we could arrange for Element clients to not tell the user they've been ignored, but other clients might not show the same courtesy.

One possible way to approach this without the other client being able to tell the message had been ignored would be to add a private list of ignored invites to the home-server - this would require spec and synapse changes, though.

@novocaine
Copy link

MSC for this exact problem: matrix-org/matrix-spec-proposals#2270

@nadonomy
Copy link
Author

nadonomy commented Sep 22, 2021

@novocaine thanks for the extra context! On this:

One possible way to approach this without the other client being able to tell the message had been ignored would be to add a private list of ignored invites to the home-server - this would require spec and synapse changes, though.

Reading through MSC2270, my understanding is:

  1. It looks like the proposal is to store this in account_data, which afaik shouldn't require backend changes.
  2. There's a related 'user muffling' proposal which is compatible and orthogonal.
  3. The MSC stalled on a lack of implementation.

Am I misinterpreting?

If the above is all true, what do you think to making an initial implementation on Element Web to help validate the MSC, and then follow up on other platforms? I appreciate it might not not 'organically' make it to the top of the web app teams priorities but it's biting stakeholders and if it's a small lift could be worthwhile.

@novocaine
Copy link

The proposal suggests it works the same way as m.ignored_user_list which, while stored in account data, is read by the server and filtering is applied by the server.

@nadonomy
Copy link
Author

Gotcha, understood. Thx!

@ara4n
Copy link
Member

ara4n commented Sep 23, 2021

The original issue for this is element-hq/element-web#2341

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
A-Invite O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Enhancement X-Spec-Changes
Projects
None yet
Development

No branches or pull requests

3 participants