Documentation for how to delete a user

[KlausHans]

I want to delete testusers, how can i do this?
The documentation only points out how to register a new user.

[Torxed]

I'd like to point out that doing:

DELETE FROM users WHERE name='@user:domain.com';

Is a bad idea, just as INSERT INTO users VALUES (...);, these are not fullfilling the requirements of a new user internally in Synapse.

[ara4n]

the right way to delete a user is to use the deactivate API:

curl -X POST 'https://matrix.org/_matrix/client/r0/admin/deactivate/%40someone%3Amatrix.org?access_token=...' --data '{}'

we do not recommend blindly deleting rows from databases, as it could leave things in a very inconsistent state.

[rorymbyrne]

@ara4n How is this implemented in a self hosted version?

[ghost]

I'd also like to know how to delete users, in layman terms if possible.

[Kleingeldprinz]

I wan't to delete users in self-hosted environment, like @rorymbyrne
How is this done?
EDIT: @ara4n @rorymbyrne This works in a local environment too. Just use your own servername and the local id of the user.

[rorymbyrne]

Matrix really needs a simpler UI/UX for being able to add and delete users.

[cavebeat]

searching for the same delete button. a testuser has regged with beginning capital characters, and so it makes problems to interact with him...

delete and rereq does not work. because it's already created... gnaahhh

and haven't found yet a admin console or interface ...

[slipeer]

@ara4n i found that deactivate API call don't remove user record from users table (checked at 0.22.1 release) - and user can't register again afte deactivation with same login.

[richvdh]

i found that deactivate API call don't remove user record from users table (checked at 0.22.1 release) - and user can't register again afte deactivation with same login.

If you want to be able to reuse the userid, you don't want to deactivate: just reset the password.

[richvdh]

Matrix really needs a simpler UI/UX for being able to add and delete users.

and haven't found yet a admin console or interface ...

https://github.com/vector-im/riot-web/issues/4125 concerns this

[rajil]

I tried to delete an account, but received

{
    "errcode": "M_FORBIDDEN",
    "error": "You are not a server admin"
}

How can i delete the account?

[alecdwm]

@rajil this might help, from the admin api docs:

This directory includes documentation for the various synapse specific admin APIs available.

Only users that are server admins can use these APIs. A user can be marked as a server admin by updating the database directly, e.g.:

UPDATE users SET admin = 1 WHERE name = '@foo:bar.com'

Restarting may be required for the changes to register.

[mohnish82]

@cavebeat @slipeer
As an admin, you can reset another user's password.

• Login as admin user and obtain access token.
  curl -XPOST -d '{"type":"m.login.password", "user":"<userId>", "password":"<pasword>"}' "https://localhost:8448/_matrix/client/r0/login"
• Then using that access token, reset any user's password.
  curl -XPOST -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"new_password":"<new_password>"}' "https://localhost:8448/_matrix/client/r0/admin/reset_password/<userId>"

PS: <userId> is fully qualified. E.g. @user:server.com
Ref: Docs

[rgpublic]

Okay, I've created a script for now to deactive an account:

https://gist.github.com/rgpublic/8457d98b0fcc0c54893b9907f9b8b825

Nevertheless it just sucks with at least a 3x factor:

Suck element-hq/element-web#1: No decent UI
Suck element-hq/element-web#2: Can only deactivate; not really delete
Suck element-hq/element-web#3: User isnt automatically removed from rooms/communities

[rgpublic]

Hm. With my script, there's one user I cannot delete. I always get "Failed to remove threepid from ID server". Is there anyone who knows what this might mean? Argh, it's a nightmare. I wonder how companies with more employees than us handle this. People sometimes happen to leave the company and then.... what? One of the really sad points of an otherwise really user-friendly, stable and great chat software. We're very happy with it, but the fact that you can always easily create stuff but you never can remove stuff the same way i.e. via Riot (Rooms, Account) is just terrible IMHO.

[bjo81]

ack! We had ~200 spamming IRC users via the freenode-bridge in a room and kicking them via riot is quite annoying.

[ArchangeGabriel]

I need a way to delete users definitively from the DB (my use case is that a change in an IRC Bridge configuration left a lot of ghosts users in the DB).

[dmitrygashnikov]

the right way to delete a user is to use the deactivate API:

curl -X POST 'https://matrix.org/_matrix/client/r0/admin/deactivate/%40someone%3Amatrix.org?access_token=...' --data '{}'

we do not recommend blindly deleting rows from databases, as it could leave things in a very inconsistent state.

Great! Is there any way to reactivate users?

[rubo77]

I think the main reason why it is not implemented to really delete a user is that this would make it possible to overtake an old Account of another User that was deleted by Registering again with the same name.

So couldn't we add a real deletion only for users that either never said anything or where all the user's messages are already redacted?

[menturion]

Can a user really not be deleted?

If this is the case, Matrix Synapse would not be GDPR compliant, since the "Right to Erasure ("right to be forgotten")" would not be fulfilled upon user request, see e.g. here ...
https://gdpr-info.eu/art-17-gdpr/

The provider of the homeserver would be obligated to delete all user data manually.

Same with respect to changing the matrix user ID, which is visible and cannot be edited after registration. This might not comply to the "Right of access and right to rectification", see https://gdpr-info.eu/art-15-gdpr/ and https://gdpr-info.eu/art-16-gdpr/. A user must be able to access and edit his personal data.

[Torxed]

Can a user really not be deleted?

If this is the case, Matrix Synapse would not be GDPR compliant, since the "Right to Erasure ("right to be forgotten")" would not be fulfilled upon user request, see e.g. here ...
https://gdpr-info.eu/art-17-gdpr/

The provider of the homeserver would be obligated to delete all user data manually.

Same with respect to changing the matrix user ID, which is visible and cannot be edited after registration. This might not comply to the "Right of access and right to rectification", see https://gdpr-info.eu/art-15-gdpr/ and https://gdpr-info.eu/art-16-gdpr/. A user must be able to access and edit his personal data.

Aside from laws and regulations which might be subject to change.
The fact that one can't administrate their own infrastructure is ludicrous and has been for a long time now. I'm not sure how this project has gotten away with it to be honest.

[neilisfragile]

@menturion users are deactivated rather than deleted, for matrix.org, our Privacy Policy (https://matrix.org/docs/guides/privacy_notice.html) describes how we satisfy our GDPR obligations, in particular the Right to Erasure.

Admins for other homeservers are of course free to publish their own privacy policy and implement it as they see fit.

More generally we agree that having easier to use and more powerful admin tools would be beneficial and it features on our roadmap (https://github.com/orgs/matrix-org/projects/9). The only reason we are not working on it right now is a question of bandwidth.

[rgpublic]

@neilisfragile Well, I think this is a bit of a view with rose-tinted glasses on. Fact is, the e-mail address is considered to be "personal data" in regard to the GDPR. Currently, it is stored on the server for an indefinite amount of time with no way to ever remove it. This is IMHO a clear GDPR violation. You can publish policies all you want but that doesn't turn illegal stuff into legal stuff. I can write my own policy that I intent to drive consistently at 100 mph but that doesnt make it legal.

What's more, I as an admin of an "other homeserver" would very much like to publish my own privacy policy stating that we delete the account completely. Unfortunately, I cannot realize that policy without decent means to delete anything. What I'm currently planning to do is completely wipe the server once per year and start with a fresh Matrix server. Otherwise I think there is currently not really a decent way to make sure that old stuff is not kept around forever. I have currently a crazy set of helper scripts which fumble around with the DB to delete rooms, accounts etc. But whether they really remove everything I just don't know. This should be clearer and easier.

We are using the scheme @company.de for our email addresses. If a new coworker arrived with the same lastname as a previous one, we couldn't create a new account for him/her. With email accounts, for example, this is not a problem at all.

Finally, if you look at the recent matrix.org security breach and the fact that encrypted messages are still not the default in Riot I think it makes very much sense to reduce the amount of data stolen if the worst case happens and the server is hacked. It is quite unnecessary when passwords etc. might be at risk even though you don't even use a server anymore.

Furthermore, even if Matrix doesn't want people to delete their account properly then IMHO extra care should be given that people are at the very least able to deactivate their account. Even that doesn't work. I have multiple accounts here at our own server where I only get "Failed to remove threepid". I initially created my own account on matrix.org but then realized I'd much prefer to setup our own homeserver. Now, I'm not able to even deactivate my account on matrix.org. I can login. But when I try deactivate it says: "Unknown error".

I think the whole situation is simply a mess and really a bad point of an otherwise quite excellent product.

[neilisfragile]

Well, I think this is a bit of a view with rose-tinted glasses on. Fact is, the e-mail address is considered to be "personal data" in regard to the GDPR. Currently, it is stored on the server for an indefinite amount of time with no way to ever remove it. This is IMHO a clear GDPR violation. You can publish policies all you want but that doesn't turn illegal stuff into legal stuff. I can write my own policy that I intent to drive consistently at 100 mph but that doesnt make it legal.

For clarity, deactivating an account does the following:-

• Removes all third party identifiers, including email
• Deletes all devices for the user
• Deletes all access tokens for the user
• Over writes the password hash

You can verify this for yourself here https://github.com/matrix-org/synapse/blob/master/synapse/handlers/deactivate_account.py#L69

As you might expect we sought specialist legal advice to ensure our policy and implementation are GDPR compliant.

However we would like to go further and treat the MXID as an opaque string, this proposal describes our current thinking. matrix-org/matrix-spec-proposals#1228

What's more, I as an admin of an "other homeserver" would very much like to publish my own privacy policy stating that we delete the account completely.

As an open source project and you are free to modify as you see fit, though you would need to consider carefully how to manage previous interactions that the user participated in.

We are using the scheme @company.de for our email addresses. If a new coworker arrived with the same lastname as a previous one, we couldn't create a new account for him/her. With email accounts, for example, this is not a problem at all.

This paragraph seems orthogonal to your main point on data privacy - there is a just as strong an argument for avoiding the possibility of mistaken identity and many companies do not recycle email for exactly that reason.

That said the point will become moot once matrix-org/matrix-spec-proposals#1228 is realised.

Furthermore, even if Matrix doesn't want people to delete their account properly then IMHO extra care should be given that people are at the very least able to deactivate their account....

This is a bug. It sounds like #5097 (Do you agree?). In any case element-hq/element-web#5097 will be fixed promptly.

[rgpublic]

@neilisfragile Thank you for your detailed response. Very interesting read. Yes, I agree element-hq/element-web#5097 sounds like my problem. I have this problem here on our own server as well as with my matrix.org account, so good to know this is being worked on.

One question though regarding what's deleted: Two people talk in a private chat with each other. Now, both leave the company and deactivate their account. We assume their conversation is not encrypted. Now, years later, someone hacks the home server and gains access to the data. Will the hacker have access to that conversation? What I gather from your response, I'd say yes. This is my main point: It's very unfortunate because the conversation can of course easily contain personally identifiable data etc.

What's currently badly missing IMHO is to have some options for users and/or admins to be able to reduce the attack surface in general. I would like, for example, to clear any messages older than xy days - or even clear all my messages from time to time. Slack, e.g., even has the ability to define a retention policy:

https://get.slack.help/hc/en-us/articles/203457187-Customize-message-and-file-retention-policies

I think this should be possible for our own home server. After all, I can simply wipe the server anyway and start from scratch. So why is it so difficult to actually remove stuff?

[neilisfragile]

Will the hacker have access to that conversation?

No they would not, because when the first user is deactivated they are removed from all rooms that they are a part, the conversation persists because the other user is still in the room and that conversation is as much theirs as the deactivated user.

When the second user is deactivated, then since there are now no other users who can see the messages the messages are deleted.

The relevant quote in the privacy statement is "Any messages or files that were only accessible by your account will be deleted from our servers within 30 days."

On your second point there is a big difference between a server having a generic retention period where all users of the server are aware of the policy and then separately, someone unilaterally removing half of a conversation where both parties can lay claim that they share the data. This is why we do not remove shared conversations under GDPR.

Generic data retention policies where all content older than X is deleted is something we'd like to do (though harder to see how this would work for federated rooms), and it's only really bandwidth that prevents us doing so.

[rgpublic]

Ah. This is extremely(!) useful information. Thanks a lot, @neilisfragile. Wish I had known all that earlier. I'm much more relaxed about the deactivation feature now. I think the (usability) problem is: The UI tells people that they can "deactivate" their account but there is no clear obvious information on what that means. I assumed that "deactivation" just means that. In particular, that you can just reactivate such an account later and you'll find everything (message history etc.) in a state where you left off. As it seems, this is not the case.

And I noticed the sentence "Any messages or files that were only accessible by your account..." but I didn't really understand what it meant as usually there are at least two persons who can access the messages. Now I understand it really means: "After all accounts having access to a specific message have been deactivated, the corresponding message itself is deleted from our servers within 30 days. Even if any of those accounts is reactivated later, the messages won't be available"

Just one more question: On our own synapse homeserver I use the CURL call:

https://localhost:8448/_matrix/client/r0/admin/deactivate/...

to deactivate the user. What needs to be done to ensure the deletion after 30 days really takes place? Is there are cron job that needs to be installed on the server or how does it work?

[t3chguy]

Even if any of those accounts is reactivated later, the messages won't be available

Deactivation is one-way in Matrix, in theory, a server admin could resurrect an account but this is on the whole unsupported

[Torxed]

@e-lisa Turn user registration off, and create your own invite system (Note that this "addon" has not been maintained but serves as an example of how to solve this problem).

Matrix is far from complete and should still be in beta IMHO.
Altho major names have started to adapt it, there's a lot of basic issues that causes major concern if implemented in certain environments. But it's the best worst we have on the market.

[erikjohnston]

Hey all, this thread has digressed a bit from the original intention (though its been useful!). I'm going to close this now in favour of other issues, simply to make it easier for us to track what's going on. As always if there isn't already an issue for your problem then please do create one.

Relevant issues:

• Add a basic admin API Collapse RightPanel before LeftPanel when shrinking element-hq/element-web#2032 and UI for deactivate and other admin functions element-hq/element-meta#1237
• Registration approval After you log out there are multiple dialogs element-hq/element-web#6911
• New user permissions Switch away from babel yearly presets element-hq/element-web#7731
• Better tooling around anti-spam Make auth validation smoother and less annoying element-hq/element-web#8293

---

@e-lisa Sorry to hear that! We've started adding some features to help combat that sort of thing, but they're currently quite rough to use and under documented. Please feel free to add any notes to element-hq/element-web#8293 with suggestions that could help.

[e-lisa]

Commenting to add to @erikjohnston's list:

• Ban by IP Address (for homeservers): Client IP-based channel bans as per IRC. (SYN-62) #1216

[e-lisa]

@Torxed That is not a solution, nor does it have anything to do with my problem. (it does not even address my use-case). Please see element-hq/element-web#1216 if you need more context.

Telling users to "write their own sign-up system" has nothing to do with being able to ban an offending IP address.

[Torxed]

@e-lisa You said, and I quote: There needs to be a way to manage [abusive users and] SPAM users..

What I suggested solves that problem. If you had another more intricate use case/problem - feel free to ignore the advice. But as other users might end up here searching for the same issue it's important to share solutions to those problems. So saying that, and I quote again, That is not a solution is an extremely generic response to a wider context and audience. Bare that in mind :)

Again, your issue is actually issues - and there's not one fix for them.
But that (again) would solve one of the issues. And I agree that there should be more moderation tools and better ways to control this platform - otherwise we're heading to a direction where all other social media is heading - chaos.

[TwoTwenty]

Hi we have an LDAP system where users can be activated and deactivated, is there a way to reactivate an account even if the history is lost for that user?
It could be very annoying if someone deletes their own account from the ui and we can never fix that for them too.

[clokep]

Hi we have an LDAP system where users can be activated and deactivated, is there a way to reactivate an account even if the history is lost for that user?
It could be very annoying if someone deletes their own account from the ui and we can never fix that for them too.

https://github.com/matrix-org/synapse/blob/master/docs/admin_api/user_admin_api.rst#id14 should help you with that, but please don't comment on closed issues with unrelated questions. #synapse:matrix.org is available for support.

[hmn566]

Hi.
Still no threat to delete accounts? in some places maybe it has law restriction. but in some places it is vice versa. it is better for self-hosted to let admin choose disable this option or not . there are many messengers like rocket chat or mattermost and ... that will allow you delete accounts permanently so it can't be against any thing widely.
I don't know if matrix is still developing but if yes please put this option for users or at least server admin to delete accounts.
Thanks Admins.

[lalilaloe]

You can deactivate accounts, if you want to reuse them again try:

Checking if the account is deactivated

curl --insecure -XGET -H "Authorization: Bearer ACCES_TOKEN" -H "Content-Type: application/json" -d   '{}' "https://localhost:8448/_synapse/admin/v2/users/@user:domain.com"

Update user information to new user

curl --insecure -X PUT -H "Authorization: Bearer ACCES_TOKEN" -H "Content-Type: application/json" --data '{"deactivated": false, "displayname":"NEW_DISPLAYNAME", "password":"NEW_PASSWORD"}' "https://local
host:8448/_synapse/admin/v2/users/@user:domain.com"

Then login with your refreshed user account

Also see https://github.com/matrix-org/synapse/blob/master/docs/admin_api/user_admin_api.rst#id15 for more info,

[hmn566]

Thanks lalilaloe,
How about if we don't want to use them again. for example we have 1000 of clinets and want to reduce them to 100.
Also what happened to the files and chats when we deactivate a user? Are they deleted or remain on the server? How to get rid of them?

[dmitrygashnikov]

Thanks lalilaloe,
How about if we don't want to use them again. for example we have 1000 of clinets and want to reduce them to 100.
Also what happened to the files and chats when we deactivate a user? Are they deleted or remain on the server? How to get rid of them?

Hi @hmn566 ,
as i know - there is no legit way to comleatly delete users. Only deactivate.
And they will remain on server forever and ever.... that behavior is one of topic for at least 20 last messages in that thread.
About groups and etc. they will remain in server too. And only way to autoremove groups and connected with them files is if all users will leave that group(or admin remove them from it some how). But consider that photos and files still be in server(you just cannot to access them from API).
If I am wrong is some point - will be glad to have some remarks from everywhone. It's a big problem, that such product so poorly documented.
And also - sorry for my bad English.

upd:
As i know - the only way to delete files remaining is delete files older than some date in media folder. But be careful - this may produce errors for active users.

[hmn566]

Well. it seems there is no solution for matrix problems. It is better to forget about matrix and go fo other IM solutions.

[TwoTwenty]

Well. it seems there is no solution for matrix problems. It is better to forget about matrix and go fo other IM solutions.
Hmn566 I looked at all the other solutions, they are all a no go for a matrix of reasons. Matrix is the best and will get better.

[hmn566]

Well. it seems there is no solution for matrix problems. It is better to forget about matrix and go fo other IM solutions.
Hmn566 I looked at all the other solutions, they are all a no go for a matrix of reasons. Matrix is the best and will get better.

Of course there are lots of solutions in 2020. For example Rocket chat has complete admin UI with full control on users. the only thing i don't like in that is jitsi but can handle it easier than not having control on users. matrix has only few commands and that's all.
About getting better i doubt it. This topic has started in 2016 and still no solution !!!. What i see is matrix has stocked with no attenttion to what admins may need. in 2017 it was supposed to make a builting admin UI in 3 weeks. now it is 3 years.

[fandrej]

Delete user @user:server.com with database consistency

Since most tables in the user_id field contain fully-qualified user_id, but some, for example user_filters, only the username, we got such strange queries.

delete from users where name='@user:domain.com';
delete from access_tokens where user_id='@user:domain.com' or user_id='user';
delete from devices where user_id='@user:domain.com' or user_id='user';
delete from user_ips where user_id='@user:domain.com' or user_id='user';
delete from room_account_data where user_id='@user:domain.com' or user_id='user';
delete from room_memberships where user_id='@user:domain.com' or user_id='user';
delete from users_who_share_private_rooms where user_id='@user:domain.com' or user_id='user' or other_user_id='@user:domain.com' or other_user_id='user';
delete from account_data where user_id='@user:domain.com' or user_id='user';
delete from blocked_rooms where user_id='@user:domain.com' or user_id='user';
delete from deleted_pushers where user_id='@user:domain.com' or user_id='user';
delete from device_inbox where user_id='@user:domain.com' or user_id='user';
delete from device_lists_outbound_last_success where user_id='@user:domain.com' or user_id='user';
delete from device_lists_remote_cache where user_id='@user:domain.com' or user_id='user';
delete from device_lists_stream where user_id='@user:domain.com' or user_id='user';
delete from e2e_device_keys_json where user_id='@user:domain.com' or user_id='user';
delete from e2e_one_time_keys_json where user_id='@user:domain.com' or user_id='user';
delete from e2e_room_keys where user_id='@user:domain.com' or user_id='user';
delete from e2e_room_keys_versions where user_id='@user:domain.com' or user_id='user';
delete from erased_users where user_id='@user:domain.com' or user_id='user';
delete from event_push_actions where user_id='@user:domain.com' or user_id='user';
delete from event_push_actions_staging where user_id='@user:domain.com' or user_id='user';
delete from event_push_summary where user_id='@user:domain.com' or user_id='user';
delete from event_reports where user_id='@user:domain.com' or user_id='user';
delete from group_attestations_remote where user_id='@user:domain.com' or user_id='user';
delete from group_attestations_renewals where user_id='@user:domain.com' or user_id='user';
delete from group_invites where user_id='@user:domain.com' or user_id='user';
delete from group_summary_users where user_id='@user:domain.com' or user_id='user';
delete from group_users where user_id='@user:domain.com' or user_id='user';
delete from local_group_membership where user_id='@user:domain.com' or user_id='user';
delete from local_group_updates where user_id='@user:domain.com' or user_id='user';
delete from local_media_repository where user_id='@user:domain.com' or user_id='user';
delete from monthly_active_users where user_id='@user:domain.com' or user_id='user';
delete from open_id_tokens where user_id='@user:domain.com' or user_id='user';
delete from presence where user_id='@user:domain.com' or user_id='user';
delete from presence_allow_inbound where observed_user_id='@user:domain.com' or observed_user_id='user' or observer_user_id='@user:domain.com' or observer_user_id='user';
delete from presence_list where user_id='@user:domain.com' or user_id='user' or observed_user_id='@user:domain.com' or observed_user_id='user';
delete from presence_stream where user_id='@user:domain.com' or user_id='user';
delete from profiles where user_id='@user:domain.com' or user_id='user';
delete from push_rules_stream where user_id='@user:domain.com' or user_id='user';
delete from ratelimit_override where user_id='@user:domain.com' or user_id='user';
delete from receipts_graph where user_id='@user:domain.com' or user_id='user';
delete from receipts_linearized where user_id='@user:domain.com' or user_id='user';
delete from remote_profile_cache where user_id='@user:domain.com' or user_id='user';
delete from room_tags where user_id='@user:domain.com' or user_id='user';
delete from room_tags_revisions where user_id='@user:domain.com' or user_id='user';
delete from user_daily_visits where user_id='@user:domain.com' or user_id='user';
delete from user_directory where user_id='@user:domain.com' or user_id='user';
delete from user_directory_search where user_id='@user:domain.com' or user_id='user';
delete from user_threepids where user_id='@user:domain.com' or user_id='user';
delete from users_in_public_rooms where user_id='@user:domain.com' or user_id='user';
delete from users_pending_deactivation where user_id='@user:domain.com' or user_id='user' or user_id='user';
delete from user_filters where user_id='@user:domain.com' or user_id='user';

After that you can register the same user again.

[richvdh]

please, please, please, do not run the above on your database. Or, if you do, please don't open bugs when everything breaks later.

[army1349]

What else can we do?
I can almost hear screams of that database :)

[Torxed]

please, please, please, do not run the above on your database. Or, if you do, please don't open bugs when everything breaks later.

Take it from someone who tried 4 years ago when I set up the database.
This works, but you do actually get intermittent oddities such as "Jump to last read message" even tho you're on the latest.

Only do this on a server where you don't care if you have to re-install it in a few months or with a very understanding community that due to lack of administration tools (because for some reason the matrix concept is based on decentralized administrative roles and information wants to be free) forces us to do weird stuff to manage our organizations/communities. And where you resign the ability to ask for support in any database related issues.

TL;DR: Matrix is not a community structured chat service - it's a decentralized chat service without a traditional hierarchy. (I might be using the wrong words here, but the jizt of it should be the same)

[wioxjk]

I have just started to use this: https://hub.docker.com/r/awesometechnologies/synapse-admin
Works great, I can recommend using this instead of deleting stuff in your database ;)

[dmitrygashnikov]

Delete user @user:server.com with database consistency

Since most tables in the user_id field contain fully-qualified user_id, but some, for example user_filters, only the username, we got such strange queries.
delete from users where name='@user:domain.com';
delete from access_tokens where user_id='@user:domain.com' or user_id='user';
etc...

After that you can register the same user again.

Well. As i understand that may not work as planned , especially for long time users with a dozen of topicks, groups, and etc. The thing is synapse also creates a lot of background information about users and it based not only on @user:domain.com, but also on generated token for each user.
So even deleting user such way may cause troubles with database consistency, and they may occure in unpredictable time period and unpredictable way. But when you recreating them with same data may occur bigger problems to absolute crash your database.
It`s my opinion. So if someone is brave enoght to use this script - take the consequences with no tears))
P.S. not forget to take snapshot of database befor using it.
P.P.s. sorry for my bad English.

[rgpublic]

I've been using this somewhat shorter script successfully many times on our homeserver:

https://gist.github.com/rgpublic/afdb4fc42804b15c644cef3bd172717a

Make sure you deactivate the user first:

https://gist.github.com/rgpublic/8457d98b0fcc0c54893b9907f9b8b825

If you can, you should also try to kick the user out of all rooms manually.

In that combination, I found that it works quite well. Other users might have to log out and log in again once for the user to disappear.

It's all not perfect and can have risks. But I don't see any alternative at the moment and for a small homeserver, I found it works quite well without too many glitches. I wonder how the mentioned Docker tool does it?

[rgpublic]

Ah, interesting:

https://github.com/Awesome-Technologies/synapse-admin/blob/master/src/synapse/dataProvider.js

Basically my "deactivateUser" script with "erase: true" argument. So there seems to be a hidden API for this after all...?

Could someone perhaps try to extend my script and test this?

https://gist.github.com/rgpublic/8457d98b0fcc0c54893b9907f9b8b825

I currently have no user to delete because there haven't been any layoffs (fortunately ;-)).

[fandrej]

please, please, please, do not run the above on your database.
Already.

Or, if you do, please don't open bugs when everything breaks later.
ок. :)

[PovilasID]

Suggestion: Renaming deactivated users to @user-deactivated:domain.com

a) It will allow for a new users to create a same handle
b) the history of deactivated user will still be viewable to others

Instead of the work 'deactivate' there can be a slug random slug so that the same name could be registered

There is more fundamental question should two people be allowed to use the same handle? I would 'borrow' how it handled by twitter or FB

[t3chguy]

It will allow for a new users to create a same handle

This is disallowed on purpose. Reusing handles may create privacy and/or security issues. You may receive messages from people thinking you are the old user still. You may still have permissions granted to that userId in some rooms.

the history of deactivated user will still be viewable to others

Nope, the history would still be tied to the old MXID, given those are stored in the immutable event DAG. You can't change the sender MXIDs of old events to rewrite history.

[vmario89]

seems that new api brought changes. i adjusted the script to use

#!/bin/bash
echo -e "\e[97mEnter user you'd like to deactivate\e[0m";
read user

echo -e "\e[97mErase? y/n\e[0m";
read erase

json=`curl -s --insecure -XPOST -d '{"type":"m.login.password", "user":"adin", "password":"password"}' "https://localhost:8448/_matrix/client/r0/login"`
access_token=`echo "$json" | jq -r ".access_token"`
 
if [[ erase == "y" ]]; then
    curl --insecure -XPOST -H "Authorization: Bearer $access_token" -H "Content-Type: application/json" -d '{"erase": true}' "http://localhost:8008/_synapse/admin/v1/deactivate/$user"
else:
    curl --insecure -XPOST -H "Authorization: Bearer $access_token" -H "Content-Type: application/json" -d '{"erase": false}' "http://localhost:8008/_synapse/admin/v1/deactivate/$user"
fi

not sure if we need the access token. you could try to remove that too and check if it still works

reference: https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#deactivate-account

[ki9us]

@erikjohnston Please reopen this.

I want to delete a matrix user from a script and it's not possible. This is not addressed by any of the issues you linked to justify closing this. How come there's a register_new_matrix_user... but there's no delete_matrix_user? And there's clearly a need for such a command: look at all the kludgy and sometimes-dangerous work-arounds in this thread!

This is a bug! Please reopen!

[aaronraimist]

@keith24 it is not a bug. It is an intentional choice. #1707 (comment)