Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4164: Leave all rooms on deactivation #4164

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
+32 −0
Open

MSC4164: Leave all rooms on deactivation #4164

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b5d3d05
Proposal to recommend accounts leave all rooms on deactivation
Kladki Jul 6, 2024
b7dafca
remove template reminants
Kladki Jul 8, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions proposals/4164-leave-all-rooms-on-deactivation.md
View file
Open in desktop
Copy link
Member

@turt2live turt2live Jul 8, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Server

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementations:

Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# MSC4164: Leave all rooms on deactivation

When an account is
[deactivated](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3accountdeactivate),
it removes all ability for the user to login again. However, as the account is not removed from rooms
it is in, this causes the server to still be sent events for rooms that account is in, even if all
of the accounts in that room are deactivated, and hence no user is able to see them.

## Proposal

Servers SHOULD make the account leave all rooms it is currently in when the account is deactivated.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Potential issues

This makes account deactivation a bit more complicated to implement, however as this has the ability
to save bandwidth, it is deemed worth it.

## Alternatives

None considered.

## Security considerations

None considered.

## Unstable prefix

None required, as no new endpoints or fields are being proposed.

## Dependencies

None.