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