MSC4164: Leave all rooms on deactivation

[Kladki]

While most servers already do this, I think it would be good to actually recommend this in the spec directly, so that future servers know to implement this as well.

Rendered

Implementations:

• Synapse: Part user from rooms on account deactivate synapse#3201
• Dendrite: Add evacuateUser endpoint, use it when deactivating accounts dendrite#2545
• Conduit: https://gitlab.com/famedly/conduit/-/commit/b81939841b272206991041ce7643a1c572590db3

[Johennes]

I'm curious if this could even be a MUST potentially?

[Kladki]

There may be some usecases where you would want deactivated users to stay in rooms, but I'm not aware of any.

[clokep]

If we can't come up with a usecase than I suspect it makes sense to be strict.

The main use-case I can think of is stranding a room without an admin. E.g. you might not want to remove the user from the room if they're the user with the highest power level. (See also your MSC4165.) By leaving the user in the room the server admin could "recover" the room.

[Half-Shot]

I think this leaves the deactivation in a bit of an unknown state and makes the whole thing a bit sticky. I'd be minded to instead have your client, assuming it's got a full set of powerlevels across rooms, to inform you if you're about to leave some rooms stranded.

That way, you can take action in advance of the deactivation to fix the rooms...or ignore it and deactivate anyway. Leaving a room without an admin isn't a problem if the user consents to doing so, imo.

[turt2live]

Implementation requirements:

• Server

[turt2live]

Implementations:

• Synapse: element-hq/synapse@bf98fa0
• Dendrite: Add evacuateUser endpoint, use it when deactivating accounts dendrite#2545
• Conduit: https://gitlab.com/famedly/conduit/-/commit/b81939841b272206991041ce7643a1c572590db3