This solution seems to make it quite hard to review invites that have been "ignored", how does the client review ignored invites?

My personal take on it is that each client may additionally cache a list of individual event_ids for invites that have been ignored, without needing to share it. But now that you mention it, this probably doesn't make sense, as we want to ignore invites across all devices/sessions.

Patching.

So, the latest version adds ignored_event_ids to give users the ability to ignore individual invites across clients. However, it's not entirely clear to me whether this is sufficient to inspect, as the invites are going to be filtered by the server.

I'm surprised this is the shape it is, ignoring users happens at the server level, why wouldn't ignoring rooms work the same?

(FTR I have made an attempt to show what it would look like on the server, but it's not very serious yet matrix-org/synapse#13177)

this looks very close to what a policy room offers. We could adapt this sort of account data to support a list of policy rooms which the server can inspect for rules and apply them on behalf of the user. If needed, the user/client could also create a private policy room to share with the server via account data to hold some of the personal rules.

Future extensions would be adding recommendations for m.block and m.ignore (to outright error and consume invites, respectively), but for now the m.ban recommendation is probably good enough.

So, to achieve feature-parity with this proposal, we would need:

1. An account data event to subscribe to policy rooms.
2. An account data event (or an optional field on the above) to specify which policy room is the main policy room for the user.
3. A new recommendation m.ignore_invites.

Right? On the downside, it's going to be harder to implement and slower, but on the upside it's going to be more orthogonal and extensible. I can write the spec for that.

I think you just need point 1. Point 2 isn't really needed, and point 3 adds complexity we might not be comfortable with introducing here (it adds time).

I don't understand your reasoning:

• point 3 is the sole objective here – we really, really want to give users the ability to ignore invites;
• without point 2, I don't see how users can publish their own policies from a client.

The way I see it, if anything, point 1 is the one that we could live with for a MVP.

Opened a variant at #3847 building upon your idea.

m.ban has enough room in its specification to support m.ignore_invites semantics is largely my argument.

It might be good if this proposal could mention #2270 as prior art on the same topic.

Overall: Based on #4192, I feel as though this MSC would be best positioned as an extension to #4155 rather than being a dedicated mechanism (for the parts that aren't already covered).