Ignore/Block invite should remove _all_ invites from the same spammer; ignore all

[grinapo]

Your use case

What would you like to do?

1. Reject all invites from a specific spammer
2. Reject all pending invites

Why would you like to do it?

Mass Invite Spam.

How would you like to achieve it?

1. If I reject+block an invite, element shall remove all invites from the blocked account
2. in the invites ... menu there should be a "reject all" or "reject+block all" option.

Have you considered any alternatives?

Manually. Suboptimal.

Additional context

No response

[t3chguy]

Blocking (Ignore API) happens on the server, so its up to your HS to apply

[grinapo]

@t3chguy I did not mean that. I am talking about element (the client) rejecting all invites automagically instead of expecting the user to reject them one by one.

Steps

1. user gets 12345 invites from @evil:example.org
2. user selects first invite, reject+block
3. element blocks invites from @evil:example.org (on server)
4. element hides all invites from @evil:example.org (in the client)
5. element rejects all invites from @evil:example.org (on the server)
6. if more invites arrived from @evil:example.org while doing that (so the server wasn't fast enough to handle the block) do not show those, and reject them when possible

Or analogous to that.

When doing reject+block all then the same for all spam senders (possibly by storing the current senders in a list then process the list, to prevent later arriving valid invites to be accidentally mass blocked).

[t3chguy]

Once a Matrix client hits the Ignore API on something it loses access to it (except unignoring) so things from that user may not even be possible to interact with, Synapse for certain actions will entirely hide the existence of events from an ignored user, as if they never existed, which can get in the way of moderation actions.

[grinapo]

I am not sure what you are referring to, how does this relate to this issue. If you imply that there is no "ignoring invites" and it is using "completely ignore user" matrix API then yes, there ought to be a warning for moderators but that is the way it is working right now, so my proposal contains no change to that.

My point is to have a one-click interface to

1. remove all invites from a user, and reject future ones
2. remove all pending invites from all users, and reject future ones from those

(Technically I could suggest that elementweb keep a local list of invite-ignored people so only ignores would be hidden, but I don't dare to suggest that since even smaller local-storage ideas were immediately closed with detectable dismay.)

[t3chguy]

The spec states

The server may optionally reject the invite on behalf of the client.
...
Servers may optionally decide to reject the invite, however.

Doing it on the client would leak when you are offline even if presence is otherwise unavailable.

(Technically I could suggest that elementweb keep a local list of invite-ignored people so only ignores would be hidden, but I don't dare to suggest that since even smaller local-storage ideas were immediately closed with detectable dismay.)

You could, but it would likely be closed in favour of the existing (wider) ignore mechanism, having to display to the user two lists of users to manage for ignores would be added complexity which I doubt the Product team would take onboard.

[grinapo]

The spec states

The server may optionally reject the invite on behalf of the client.
...
Servers may optionally decide to reject the invite, however.

Doing it on the client would leak when you are offline even if presence is otherwise unavailable.

Maybe you misunderstood the specific case:

Problem

• user gets 666 invites from perviously unknown (and thus not ignored) spammer1, and another 333 from another from previously unknown spammer2.
• user does not want or need these invites.

Non-Solutions now available

Right now the user can:

• delete 999 invites one by one, 3 clicks per entry, require mouse aiming. It will be about 3000 clicks. That would take about 5000 seconds (83 minutes without break).
• click on the first and choose "reject and ignore user"; this cause only the first invite to disappear, so 998 more to go. It would prevent new invites to arrive (in theory), but doesn't help removing the already arrived ones. (Bascially same as before.)

Proposal

What I proposed are various solutions for this case:

• The user can click on first invite, choose "reject and ignore user", and the client ignore spammer1 and remove all invites from spammer1
• OR the user choose "…" on first invite, choose "ignore+reject all from this user", and all invites from spammer1 would disappear (gets rejected or delayed or whatever mechanism you prefer for being offline)

These require two times a few clicks, one for all of the invite for spammer1 and one for all for the spammer2 invites. (about 10 seconds).

Further possible funtionality

Alternatively:

• the user choose "…" on invites box, choose "ignore+reject all invites" and all invites from spammer1 and spammer2 and whatever was waiting would disappear at once. (About 5 seconds, but it's a bit risky, since it may reject valid invites, so I don't endore this too much.)

Why in client?

Of course it would be best if the server would do that instead, but it doesn't, as far as I know, but I'm open to new knowledge.

Ignoring the complete user instead of ignoring the invites is a problem

Yes, it is a problem, since ignoring a user makes moderation of the user technically impossible, but that is a specification and servers problem, and this issue cannot solve that, it is out of scope here.

[t3chguy]

The user can click on first invite, choose "reject and ignore user", and the client ignore spammer1 and remove all invites from spammer1

Yes, the spec says this is up for the server to do as an implementation-detail, rejecting 333 invites would take probably over an hour with rate limits on servers like matrix.org otherwise, and would stop if you close/restart/update the client.

Of course it would be best if the server would do that instead, but it doesn't, as far as I know, but I'm open to new knowledge.

Sure, which is why you should open an issue to tell them why this is important to you, otherwise it just falls down this crevice as it already has.

[grinapo]

Did you mean like this?

matrix-org/matrix-spec-proposals#4294

Would this make the feature in Element covering all the problems I have listed above?

[t3chguy]

Only if the SCT deem that to be a mandatory submodule of the spec or the Element product team choose to implement it, would likely only be once the MSC reaches FCP. Having Synapse reject all invites based on an ignore using the existing mechanism would likely take less time

[grinapo]

Only if the SCT deem that to be a mandatory submodule of the spec

I cannot make them.

or the Element product team choose to implement it,

That is you.

would likely only be once the MSC reaches FCP.

That assumption was implicit. Yes.

(In fact I have written a rather long response detailing why your suggestion will not work and how the MSC process is completely broken, but choose to remove that and provide a sample instead. We'll see, I hope I was wrong.)

Having Synapse reject all invites based on an ignore using the existing mechanism would likely take less time

Synapse is just one server, this is about Matrix as a whole, all servers. I could open an issue for all half the dozen servers, but it sounds suboptimal.

Also intro contains your well placed (but possibly unintended) warning about ignores versus moderation.

But I take this as a "yes". Hopeful!

[t3chguy]

That is you.

I have nothing to do with the product team, I am an IC, not management.