MSC4192: Comparison of proposals for ignoring invites

[Johennes]

This aims to aid progression on the topic of ignoring invites by comparing the various existing proposals. I've decided to submit this as a pull request rather than an issue because this allows for easy commenting. Obviously, there is no intention to merge this pull request ever.

Thanks @clokep for an early review of this document.

Rendered

---

In line with matrix-org/matrix-spec#1700, the following disclosure applies:

I am a Systems Architect at gematik, Software Engineer at Unomed, Matrix community member and former Element employee. This proposal was written and published with my gematik hat on.

[turt2live]

for lack of a better system, I'm tracking this as a proposal.

[Gnuxie]

Something that's kind of missing from the review is that most of these proposals focus on how a user can filter invitations from their client to filter them from one device or from /sync across their devices. The focus is on what an individual user can do, for their own experience and no one else's. There obviously needs to be a way to ignore invitations, but advanced filtering such as globs or rules could be missing the point. If Matrix users are having to set these advanced systems up, and everyone has to do that individually, then that's no good. The bar is too high, and that's a lot of duplicated work that everyone is doing.

The reason for that is because there's no dedicated moderation team in Matrix. If this was a normal social network then there would be a team that would be fed information each time a user rejects an invitation and from that they would be able to generate the metrics to be able to create these complex rules. That would then be applied system wide for all users of the network.

So how do we get an equivalent to that in Matrix that works?

[Gnuxie]

So to an extent, homeservers can already collect data whenever one of their resident users rejects an invitation. And tools can in theory be developed to protect resident users from those invitations. But there's a problem with this because the targets of the invitations on single user homeservers and small homeservers will get exposed to the invitations before there's enough data to protect everyone on the server who is a target.

So there obviously needs to be some collaboration between homeservers if this route was to be explored. Fortunately policy lists are great at that and could be reused, but they would have to be discoverable automatically to be effective and also not accidentally leak unnecessary information, such as who the target of the invitation was.

[Gnuxie]

The other route is to skip the homeserver entirely, and have users publish data about the invitations that they have rejected directly (but again, there needs to be consideration about how not to leak unnecessary information and at the minimum identifiers will have to be hashed). The good news there is that the upcoming profiles MSC4133 actually provides an avenue for personal policy lists to be discoverable (which i must stress has been a major blocker for things like this before).

[Johennes]

Thanks for the input, these are good thoughts.

My focus writing this up was definitely on the end user taking action. gematik is currently using MSC4155 in a private federation to let e.g. doctor's decide what patients, other doctors, etc. are allowed to contact them. The other proposals mostly focus on the invitee taking action, too, though.

Since all of the proposals depend on account data in some form, I believe they would conceptually support the homeserver injecting a certain base configuration – just like you're getting default push rules from the server. We'd just have to put modifying the account data event behind an API.

In order not to let the scope explode, I'm wondering if we should make a separation here. This proposal could focus on providing capabilities for users to set up personalized invite filtering and for servers to inject default configurations. The topic of sharing invite spam information among servers could then be handled separately in other proposals?

[kegsay]

I believe they would conceptually support the homeserver injecting a certain base configuration

If your server is a corporation with their own rules to follow, this makes total sense. However, I somewhat strongly feel that this must not be applied universally for all servers (like push rules are today). A core part of Matrix is that you have the agency to choose which filter bubbles you're taking part in, and it should be visible to the end user.

This proposal could focus on providing capabilities for users to set up personalized invite filtering and for servers to inject default configurations. The topic of sharing invite spam information among servers could then be handled separately in other proposals?

I don't think this is a good separation of concerns because well, they concern the same thing. Say we do this and decide to implement MSC3659 – Invite Rules - for whatever reason. Months later, we want to share the rules with others. Oh no. Now we have two similar but not quite the same systems dealing with allow/blocklists for different categories of things, when if we had a holistic view from the start we may not have made the same decision.

[Johennes]

Point taken. Maybe we should clarify what exactly we want to solve for here:

• Let users manage who can invite them (this is what I originally had in mind when writing this up and what the existing proposals largely focus on)
• Let users share their invite configurations with each other?
• Let users share their invite configurations with their server?
• Let servers share default or recommended invite configurations with their users?
• Let servers share invite configurations with each other?
• Maybe others?

[Gnuxie]

If your server is a corporation with their own rules to follow, this makes total sense.

I'm not so sure, it should make sense everywhere. There should be defaults because a majority of users will never play around with the settings much. That does not mean that power users shouldn't be able to customize or deviate from the default though.

[kegsay]

Given how complex push rules are to implement correctly, I have zero desire to reproduce this here. The complexity issue should be mentioned as a negative.

[Johennes]

How would you say the complexity compares to the policy list proposal above? My hunch is the policy lists could appear less complex only because they currently have fewer matching and action constructs. If the invite rules proposal would be stripped down to be on par feature-wise, would you still consider it a lot more complex to implement?

I'm not necessarily in favor of this proposal. Just trying to make sure I'm not discounting it unfairly.

[joshqou]

@kegsay You can read the full MSC3659 spec for more details. It's just a list of rules which are evaluated in series. I've implemented the spec myself and the implementation is not that complicated.

Even if it comparatively complicated, compared to m.ignore_users, approving and implementing it would give Matrix the critical user safety tools it currently lacks. If we can have spaces and threads, both vastly more complicated, surely we can be able to properly block dms from harassers. If you have any individual critiques about specific rule types then I'd be open to accepting changes

[kegsay]

I never really thought about expressing this as moderation policy lists but I actually love it. This is 100% in the spirit of Matrix as a protocol, where we can share our views of who to ignore and consciously choose to opt-in.

There is the question over which room should your own personal blocklists go, to which profiles as rooms would be the obvious candidate if it ever landed.