Remove/delete rooms & spaces

[rgpublic]

Like matrix-org/matrix-spec-proposals#722, which has been falsely closed as a duplicate of matrix-org/matrix-spec#242, I still think it should be possible to delete rooms without any shell script or other magic. We're using Matrix for some weeks now and are VERY happy with it, but the inability to really delete rooms (and NOT just hide them) is a major annoyance. I dont want to give all my coworkers SSH access to the chat server and tell them to run a shell-script just so they can delete rooms they've created. I'm aware of the fact that when federation is enabled you cannot really guarantee that the room is actually deleted. But: We have already the option during room creation to define a room as server-local. At the very least these rooms should be deletable IMHO.

[turt2live]

This is more of a server concern than the client. The server has the opportunity to delete rooms that have been abandoned, and synapse (at least) doesn't use this opportunity.

The best issue I can find that relates is: matrix-org/synapse#2338 (I could have sworn there was an issue for deleting rooms when they are abandoned though)

[richvdh]

(I could have sworn there was an issue for deleting rooms when they are abandoned though)

So could I. Anyway, matrix-org/synapse#4720, until we track it down.

[fnorf]

Maybe "forcing abandonment" would be a different name then. If the admin of a room wants to make it "gone", they should be able to easily remove all its users, "lock" it so no one can resurrect it and suggest the server to drop all history it knows.

[karl007]

For everyone who search for a secure solution to delete a room (or something nearby), I create a php script as replacement for the nuke-room-from-db script, but use the API to kick all users and then let the garbage collector remove the empty room instead of deleting membership in the DB (and maybe miss something or screw up the DB): https://gist.github.com/karl007/521f6ab84a398ee27118ab89aae7a9dc

php riot_delete_room.php https://matrix.org "MDA...kYK" "#alias:domain.de"

The script only shows all members and the stop and ask if the members should kick. Then ask for a reason and a possible userId which should not kicked.

[Fnux]

It's weird for end-users not to be able to "delete" a room: it does not really matter if the room is left abandonned, but it would make sense for admins to have a "delete" button that kicks everyone, lock and leave. Homeserver GC can take care of the rest, but I think it doesn't matter from the user point of view.

It should not be hard to implement in riot.

[t3chguy]

It would be hard because as soon as there's multiple admins one admin cannot do this on their own, all admins would have to leave/derank themselves then the final one click this button. Admins cannot kick each other.

[Fnux]

Good point.

Issue we got at work today: someone created a duplicated room by error, and invited 5-8 users. It was confusing for them, as they had to do everything by hand. We could add an "Abandon room" button in settings for rooms with a single admin, which should already cover most use cases. Not perfect, but still better than the current situation. Would you be open to such a patch?

[mahemoff]

It would be hard because as soon as there's multiple admins one admin cannot do this on their own, all admins would have to leave/derank themselves then the final one click this button. Admins cannot kick each other.

I don't see this as a big enough hurdle to block an expected feature. If there's 2+ admins, just fade out the delete button with a message to reduce to 1 admins in order to delete it.

[kollokollo]

My use case for deleting a room was: I created a room with encryption on. Now I want to have no encryption (because I do not want to veryfy every user). This is not possible. So I want to delete the room, but create a new one with the same name(!), then without encryption. Would that be possible?

[malcolmbastien]

My use case for deleting a room was: I created a room with encryption on. Now I want to have no encryption (because I do not want to veryfy every user). This is not possible. So I want to delete the room, but create a new one with the same name(!), then without encryption. Would that be possible?

Just another voice echoing a use case similar to kollokollo's. I mentioned this in the #matrix channel what I did and brought up the usability issue of letting (at least in Element) a user set encrypt a public room with a published address in the first place.

But yes I would like to delete (or have Matrix clear the empty room) so that I can reclaim the published address and do it correctly the second time around. Thanks all.

[rgpublic]

In the meantime, I've discovered there seems to be an API in Synapse to do just that:

https://github.com/matrix-org/synapse/blob/develop/docs/admin_api/rooms.md#delete-room-api

I wonder why this can't somehow be wired to show up as a button for admins in the frontend? Shouldn't be too hard to do...

[t3chguy]

Because its a Synapse specific (not Matrix) API and requires a Matrix Access Token of a Synapse Admin and the /_synapse/ paths to be reverse proxied, so will not work for most users on the majority of servers.

[rgpublic]

Thanks a lot for the explanation @t3chguy . Understood. But I thought Synapse was the most widespread server a.k.a. "standard implementation"? Couldn't Element detect, if this server feature is available and then add this as an additional menu entry/delete button?

[t3chguy]

Sure, but Element strives to be a Matrix client, not a Synapse one.
Plus pretty much all instructions on running a Synapse tell you to only reverse proxy /_matrix/ and not /_synapse/ so it will not work on 99% of deployments and of the 1% of deployments it'll work for the small handful of Server Admins only.

[ara4n]

It's embarrassing that this is such a longstanding issue - it's a common general complaint against Matrix that "you can't even delete rooms!!!". I've been thinking about it today, and may have a way forward:

• Room Settings exposes a 'remove room' button (greyed out if the user has insufficient PL to do the operations below)
• This gives a dialog box offering the various flavours of removal:
  1. Delete the room's addresses and unpublish it from your server's directory (doesn't impact the users currently in the room, but often the user is just trying to recover the alias to set up the room again rather than actually delete the room's contents from their server).
  2. If you're the only room admin, you can kick out all users too. (The room history will still be stored in your server though, given as a room admin you can't force users to forget the rooms they've been in. We also don't yet have a bulk kick API, so your client would have iterate over the users kicking them.)
  3. If you're the server admin, you can block the room from your server and delete its history (https://github.com/matrix-org/synapse/blob/develop/docs/admin_api/rooms.md#delete-room-api). The displaced local users can optionally be joined to an alternative room instead.

As @t3chguy mentioned above, exposing the server admin features is a bit unpleasant as they are currently synapse specific, but better that than not have the feature exposed at all. https://github.com/matrix-org/matrix-doc/issues/1411 tracks speccing server admin functions properly.

Finally, a common reason to 'remove a room' is actually to merge it into another one. Therefore a second 'merge room' button could be added in Room Settings which sends a tombstone into the room to point it at a destination.

[hex-m]

As a user my expectation of "remove room" would be just that: the room should not exist anymore. (not having any members, not be join-able by anyone, deleted after some grace-period)

often the user is just trying to recover the alias

The management of aliases (actually called Addresses in the UI) is a different issue imo and I would not click a "delete room" button when I search for that feature.

I would expect a workflow like this:

1. click "delete room"
2. if there are other admins get message: "ask all other administrators to demote themselves or leave the room first"
3. "Warning: you and all other members will loose access to this room and its content!"
4. "Should the Room Address '#room1234:server.tld' be pointed to a different room? Should the current members be invited to join that room?"
5. all aliases/addresses get deleted, all members kicked, history visibility is set to members only, room is set to invite-only and garbage collected sooner or later.

If you're the server admin [..]

Should Element-Web really include administration-functionality? There are issues (#1237, matrix-org/synapse#2032) requesting a dedicated interface for such things.

[richvdh]

As @t3chguy mentioned above, exposing the server admin features is a bit unpleasant as they are currently synapse specific, but better that than not have the feature exposed at all. matrix-org/matrix-doc#1411 tracks speccing server admin functions properly.

please, please, please, don't use synapse's admin APIs in clients. Once you do so, other clients are pressurised to do the same, and they become a defacto part of the spec. (Also: synapse's deployment instructions specifically advise against exposing the admin API to the internet, since it gives attackers who get hold of an admin's access token a huge amount of power.)

[t3chguy]

Element already uses some Synapse Admin APIs @richvdh

[richvdh]

that is very much a bug, not a pattern to be repeated.

[t3chguy]

It was done by product demand for a Deactivate button on the user info panel within Element.

[richvdh]

Given https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-admin-whois-userid already exists, the second of those is particularly surprising.

[richvdh]

It was done by product demand for a Deactivate button on the user info panel within Element.

yes I appreciate there are good reasons for wanting these features, but the way to do it is with specced APIs, not by skirting around the spec process by using unspecced APIs.

[rgpublic]

The only thing I really don't understand is: Why is it a non-admin/general-user feature to create a room but there are so many complications around just doing the opposite and reversing the action I might have just done? It seems weird to me in the first place to include one thing in the spec and not the other.

[t3chguy]

@rgpublic because a room admin has shared control of the room with other room admins (users of equal permission) - you cannot kick or demote them, this is to prevent a rogue admin/hacked account from doing irreversible damage. The ability for an admin to delete a room would cause irreversible damage.

In any case, a discussion for the matrix spec and not Element

[hex-m]

Even using the Admin API to delete a room turns up odd behaviour. It may be useful to track that as a separate issue from a room admin trying to delete the room but I'll put this here for now.

• I deleted the room on the server it was created (according to the room_id) and would expect that this would kick all users from the room - not only the ones that are on my server.
• Users on servers don't get any notification except for "User X left the room". They have no idea the room was "deleted".
• The local (kicked) user still has the room in the "Historical" section, and when she tries to join again gets the message: "No known servers". This feels extra wrong as I didn't set the block flag at the delete-call.
• A federated user left in the room can re-invite the kicked users and thus undo the "delete"-operation. After re-joining the user has the power level she had before.

Suggestions that would be possible without spec change:

• send a message into the room explaining what is happening
• set a reason explaining why you were kicked
• element-web: allow access to the history of rooms you were kicked from. we no longer show history if you're kicked from a room? #465
• if all admins are on my server: kick all users from the room (including federated ones). Otherwise warn that the room can not be deleted until the federated admins leave.

Possible spec changes:

• new room state deletion_proposed that informs all admins about the wish to delete the room. either server-admins or room-admins can confirm. If all users/servers confirmed the room gets deleted.
• new room state deleted that tells all servers to remove their users and forgets about the room. (maybe keeping it read-only for some grace period)
• as having more or less than one admin is a problem for many things, define a unique owner/creator-role for a room. https://github.com/matrix-org/matrix-doc/issues/652

[t3chguy]

@hex-m that's because rooms don't exist/belong on a single server. They are decentralized amongst all servers which have users in that room, so you're only deleting your own server's copy of that room.

Synapse supports operations for preventing reaccessing the room from an invite etc, offtopic for this repo.

Your suggestions apply to Synapse specific implementation and the Matrix spec, not for this issue.

I suggest spinning up issues in relevant repositories for those.

[shmerl]

Use case: 1:1 room, one user got locked out from the account, so they can't leave the room. There should be an ability to remove such room by the other user (who is also admin).

[tanriol]

If you mean that in an 1:1 room any user should be able to delete the room without any traces, I'd be opposed to that. As a user, I don't want the person I'm chatting with to be able to completely remove our communication history.

[shmerl]

It's kind of already possible for individual messages, including "Remove recent messages" for more bulk deletions. So not conceptually very different, just a bigger scale.

[movahhedi]

Still waiting for an update on this. It's very annoying

[BMaxV]

Got here from trying to leave a test room and making it disappear.

Turns out you can't. That's pretty funny.