UI for deactivate and other admin functions

[ara4n]

We should provide UI for users who have the admin flag set that lets them manage their HS - particularly deactivating malicious accounts (and setting admin flag on other users). Unclear if this should be in Riot or a separate admin console for HSes.

[e-lisa]

It would also be nice if there was a way to see if the same user is creating spam accounts (since email addresses are easy to create).

Maybe a way to display the IP/Hostname of a user on your HS in Riot for Admin?

This would be great! And paired with a ban feature make this useable for our orgs :)

[cavebeat]

other admin function is usually "reset the password of a specific user".

[BloodyIron]

Yeah, this kind of thing is really needed to be able to properly administrate Matrix/Riot ecosystems, whether it's self-hosted or publicly federated. Naturally, be it per-channel, and HS-wide depending on access set.

Resorting to API/SQL is really inefficient and time-costly from an admin perspective.

Any chance we can get this revisited? :)

[anoadragon453]

Would be good to have as a web UI so that people using various clients could just use the web interface, though providing something through the C-S API would be good long-term.

[BloodyIron]

@anoadragon453 completely agree! :D

[ara4n]

we're prioritising the riot redesign over this sort of admin interface. contributions from the community would be very welcome on it.

[BloodyIron]

@ara4n certainly understandable! Mostly trying to help report issues observed and maintain visibility on things.

Will the redesign incorporate admin-aspects, for when they are ready? (UX aspects made, even if not used at first).

[freedomtrain]

Is there any update on when the admin UI might be available ?

[t3chguy]

Deactivate was added as can be seen above ^

[r4dh4l]

It would be nice to have the possibility to register new accounts and change account passwords from within Riot. I would imagine something like this:

1. I open a room used just by me created on my home server.
2. I type /adduser alice (or /adduser @alice:myhomeserver.com) and @alice:myhomeserver.com is created with a pre generated password.
3. I type /passwd alice NewPassword (or /passwd @alice:myhomeserver.com NewPassword) and the new password of @alice:myhomeserver.com is set to NewPassword.

[skobkin]

Yes, it would be very good to have such interface. Especially for people coming from XMPP where most of the tasks could be done using the client.

[r4dh4l]

Yes, it would be very good to have such interface. Especially for people coming from XMPP where most of the tasks could be done using the client.

I remember it is possible with XMPP to allow certain users to create users without access to the server. This would be a great feature for Matrix servers as well, even more if there would be some kind of "moderated account creation" feature: If one of this users create an account I get a notification and can confirm the registration (/adduserconfirm MXID).

[e-lisa]

Hi! I just wanted to reply that 3 years later, and this is still a major issue for projects that use Element-Web.

When bad actors come on our network our only option is to shut down the entire Element-Web interface and contact a sysadmin to implement a ban. Banning the user by IP address this way can take over a day sometimes in the real world. This is even more frustrating when the malicious actor has access to multiple IP addresses.

I am responding to this issue as its come up again, we are currently at the point where we had to shut down Element-Web due massive abuse. Since the admin's have no way of banning by IP address our only option is to keep our Element Web service down until further notice.

When bad actors hit our chat server, they can simply make a new account with a disposable email address. And they can do this forever, with impunity keeping our chat administrators more than busy. There needs to be a way to completely block a malicious user with out needing to call the API by hand...

Please let me know if you have any questions about our use case.

I hope this user story helps people see why this features is well past due.

(edited to add more information)

[ptman]

There's https://github.com/Awesome-Technologies/synapse-admin

[MurzNN]

Also exists https://github.com/matrix-org/mjolnir that automate banning for prevent spam.

[e-lisa]

@ptman & @MurzNN thank you for the links! I will see if these tools can fill the void. They seem like they may fall short, but I will evaluate them nonetheless.

I think the root cause here is the lack of a Server ACL scheme, so I will chase this in tandem with the Synapse side of things. That said "mjolnir" on the surface seems to address some of the major concerns. Here is to hoping we can end the abuse in spite of lacking an admin UI!

[ptman]

https://matrix.org/docs/spec/client_server/r0.6.1#server-access-control-lists-acls-for-rooms & https://github.com/matrix-org/synapse/blob/master/docs/sample_config.yaml#L596 or please expand what you mean with Server ACL

[e-lisa]

@ptman Referencing the reply on this ticket matrix-org/synapse#7731

That ticket was created because of this ticket: element-hq/element-web#14130

A user with pretty much the same problem our team has (no ability to moderate server in a meaningful way)

[e-lisa]

@ptman & @MurzNN We have evaluated both tools, neither allow enforcement of server-wide bans. Server wide bans with mjolnir are just room level bans enforced by a bot.

The bad/malicious actor is not "really" banned...

[ara4n]

Mjolnir is not just a bot, it's also a synapse module which can enforce blocks serverwide (rather than on a per-room level): https://github.com/matrix-org/mjolnir#synapse-antispam-module. For instance, the code which blocks users serverwide irrespective of room is https://github.com/matrix-org/mjolnir/blob/master/synapse_antispam/mjolnir/antispam.py#L89. It could also enforce per-IP bans if that's what's needed (but that's not been hooked up yet, given it's an infrequent ask, as you can see by the lack of upvotes on matrix-org/synapse#1216)

[e-lisa]

@ara4n Mjolnir does not support server-wide bans, it just implement's room-level bans server wide...

Per the Mjolnir documentation: https://github.com/matrix-org/mjolnir/blob/master/docs/moderators.md

This is not the same thing, the server owner needs the ability to remove malicious users, end of story. Server level bans, even with Mjolnir are not implemented on a basic level. Abusive users are free to ban evade until the cows come home...

[ara4n]

Your screenshot is referring to when Mjolnir is acting a bot (as per the title of the document: "Moderator's guide to Mjolnir (bot edition)". The functionality you are asking for is implemented by Mjolnir when acting as a synapse module, as per the links I gave in the previous comment: https://github.com/matrix-org/mjolnir#synapse-antispam-module. This is explained in the main readme for Mjolnir:

If you're not willing to listen to us or accept our help on this we cannot help you further.

[MurzNN]

@e-lisa also lookup https://github.com/devture/matrix-corporal project, it have some server-side moderation features too

[e-lisa]

@ara4n That does not address the issue of server level bans based on IP addresses and netblocks, at all. Thanks. Not having moderation features is a serious issue. Please stop acting like these band-aids are solutions.

@MurzNN Looking into it, thanks!

[ShadowJonathan]

I think the ambiguity core to this is issue is the one of "Synapse vs Matrix".

Synapse is a Matrix homeserver implementation, which for the longest time served as its most practical reference implementation, and has its own admin API. However, in 2022, there exists two other high-profile matrix servers; Dendrite and Conduit.

Synapse's admin API is baked into some applications as a result, but this is an unfavorable situation, as when those tools are (re)used on other server implementations, they'd suddenly not work.

The matrix spec exists to solve this problem with a generic API for these kinds of purposes, and as a starting point, a while back, i made MSC3593, which seeks to address and standardize the most core admin APIs, among them a user deactivation endpoint (POST /_matrix/client/v1/admin/user/{user_id}/deactivate).

That proposal can address this, and also allow other tools to target matrix in a more generic way.