#1174 Allow server admins to request MUC ownership when needed
Reporter
pep.
Owner
Nobody
Created
Updated
Stars
★★ (3)
Tags
Priority-Medium
Component-MUC
Type-Enhancement
Status-Fixed
Milestone-0.12
pep.
on
Description of feature:
As a server admin, I would like to be able to request ownership of a MUC when needed, and not have it on all the time.
Kind of like IRC, but not caused by its limitations.
Motivation: (Why?)
Out of all the rooms I'm in, as server admin, I almost never need more than a participant role.
As a nice side-effect, that would also help avoid me seeing all these realjids flying around, since full-anon MUCs are not a thing.
pep.
on
s/participant/member/
Mikaela Suomalainen
on
I have a problem that I cannot use OMEMO encrypted MUCs with the server admin due to them always being a owner and I think clients consider that as a MITM attack and refuse to encrypt to it or show repeating warnings about the server admin being in the MUC.
* Conversations spams me with warnings often.
* Dino: The server admin cannot decrypt anything in MUCs I send from Dino.
* ChatSecure won't see or encrypt to the server admin at all.
I am not surprised if this affects many other clients also.
Due to this issue one group has moved from a MUC to Signal and I think one user just gave up with XMPP.
I often hear that the problem is that the XMPP admin account should not be used for anything else than admin tasks, but apparently this is mainly known by developers and people who complain about this problem. I don't know if even Prosody documentation states that.
ellenor@umbrellix.net
on
I'm in this post and I don't like it
MattJ
on
From tomorrow's 0.11 and trunk nightly builds, there is a new option, which you can set:
component_admins_as_room_owners = false
will disable automatically making admins listed in the config file become owners of rooms.
The initial request for this issue was different - a mechanism to selectively become owner on-demand. It's not clear how this could be achieved with existing clients. Potentially an ad-hoc command. It would be clunky, but the closest thing to widely supported (except in mobile clients).
Commit: https://hg.prosody.im/trunk/rev/85585910d468
Zash
on
An ad-hoc command for setting any affiliation of any JID in any room added in https://hg.prosody.im/trunk/rev/e4034f6668a5
With this and the above setting a service admin can give themselves ownership when needed as well as give anyone else ownership, or demote them or ban them, revert takeovers etc.
0.11 users with the telnet console can do the same thing via telnet like so:
`muc:room("room@conference.server"):set_affiliation(true, "admin@server", "owner", "because I can")`
Description of feature: As a server admin, I would like to be able to request ownership of a MUC when needed, and not have it on all the time. Kind of like IRC, but not caused by its limitations. Motivation: (Why?) Out of all the rooms I'm in, as server admin, I almost never need more than a participant role. As a nice side-effect, that would also help avoid me seeing all these realjids flying around, since full-anon MUCs are not a thing.
s/participant/member/
I have a problem that I cannot use OMEMO encrypted MUCs with the server admin due to them always being a owner and I think clients consider that as a MITM attack and refuse to encrypt to it or show repeating warnings about the server admin being in the MUC. * Conversations spams me with warnings often. * Dino: The server admin cannot decrypt anything in MUCs I send from Dino. * ChatSecure won't see or encrypt to the server admin at all. I am not surprised if this affects many other clients also. Due to this issue one group has moved from a MUC to Signal and I think one user just gave up with XMPP. I often hear that the problem is that the XMPP admin account should not be used for anything else than admin tasks, but apparently this is mainly known by developers and people who complain about this problem. I don't know if even Prosody documentation states that.
I'm in this post and I don't like it
From tomorrow's 0.11 and trunk nightly builds, there is a new option, which you can set: component_admins_as_room_owners = false will disable automatically making admins listed in the config file become owners of rooms. The initial request for this issue was different - a mechanism to selectively become owner on-demand. It's not clear how this could be achieved with existing clients. Potentially an ad-hoc command. It would be clunky, but the closest thing to widely supported (except in mobile clients). Commit: https://hg.prosody.im/trunk/rev/85585910d468
An ad-hoc command for setting any affiliation of any JID in any room added in https://hg.prosody.im/trunk/rev/e4034f6668a5 With this and the above setting a service admin can give themselves ownership when needed as well as give anyone else ownership, or demote them or ban them, revert takeovers etc. 0.11 users with the telnet console can do the same thing via telnet like so: `muc:room("room@conference.server"):set_affiliation(true, "admin@server", "owner", "because I can")`
Changes