@kescher Re: purging, do you mean in the sense of "users automatically leave a room if their instance has been unreachable for X time", or something else?

Re: defederating instances, I assume you mean on a server level rather than on a room ACL level? For what reason(s) would they be defederated? (As it's a technical impossibility to literally defederate without breaking rooms, and workarounds are potentially viable but need a more precise problem description to get right)

Re: banning individual known-bad users, I assume this goes beyond room bans, and you (conceptually) mean something along the lines of "defederating between your homeserver and a particular remote user" instead?

@joepie91 Purging as in instance reachability, but also for bad actor users.

Defederating on a server level (yes this is a protocol hindrance), not even accepting events/sending events to others anymore.

And yes, goes beyond room bans, my homeserver should have the ability to reject events from/sending events to specific users.

@kescher Right, so the main problem why Matrix can't (literally can't!) do that is because the entire concept of decentralized rooms relies on all participating servers having an identical view of the rooms internally. They may choose to (not) show things to users, but they must have an identical event graph. If one participant blocks another server's events entirely, their room state diverges and the room breaks for them. That can't be designed around, at least with any decentralization model I know about.

The only way I know of to defederate servers anyway (on a server level, not a room level) is to basically get rid of the 'decentralized' property of rooms, and making them more like MUCs in XMPP, where a channel exists on a specific authoritative server, and if that server ever goes down, the channel is gone. This has historically gone very poorly because people's entire communities just suddenly disappear with no warning, there's no resilience in the system at all.

There are some workarounds in decentralized rooms like "accept their events but only store a redacted version locally, never the contents" that *could* work if the protocol is designed for it, but that won't necessarily be sufficient in 100% of situations, hence why I'm trying to understand the specific circumstances in which defederation might be wanted, to see if such an approach could work here, and make sure I'm not overlooking any details.

@joepie91 tbh, "accept events but immediate redaction without storing actual content" could maybe also work.