This is a placeholder for a policy we need:
- Who has admin permissions in :fedoraproject.org rooms?
- What about moderator permissions?
- What about other more granular permissions?
- What about :fedora.im rooms? Same rules or different?
Would it make sense to follow FAS permissions in rooms that are synced to a team? Like map FAS roles to admin/mod/user?
1 Like
it might need to be manually. let me ask.
It is not possible to involuntarily demote people from PL 100 (Admin) without very messy things like impersonating the user or resetting their FAS account and logging in as them.
I suggest that we only give a very small group of core admins PL 100, and give everyone else PL 50 (Mod). Room permissions can be set so that PL 50 can do basically everything, so I don’t feel people would really lose any functionality by “only” being Mod.
2 Likes
Would it be at all useful to make up a new permissions level, like PL75 or something, to separate room owners from moderators? I don’t really have a firm grasp of exactly what the permissions allow, so I don’t know if this is a good idea or not. 
I’m looking at the permissions now, and I’m thinking there’s some we probably don’t want to give out to most moderators:
- change main address for room
- enable room encryption
- change history visibility
- change permissions
These, I’m unsure of giving to moderators:
- change room avatar (I’m hoping to have a consistent set of icons made by the Design Team, and I don’t want people changing them at will, which I know they will if they can, because I personally understand this to be very tempting to be funny with).
- change server acls (I am unsure what exactly this does)
- upgrade the room (we probably always want our rooms “upgraded”, right? what’s the harm?)
- change settings (super unclear what settings these apply to)
- modify widgets (necessary for jitsi, which we want to make easily available, but I’m unclear on what other havok this could wreak)
These I think we definitely want to give out to moderators:
- kick users (moderator ultimate power, after all)
- ban users (no, wait, this one is the ultimate power)
- remove messages sent by others
- notify everyone
- change topic
And, this defaults to “Moderator” permission, but I think maybe should be given to everyone?
- invite users
So based on that, maybe the “unsure” category should be set to PL75, and given to people who don’t need overall admin access but who have agreed to handle these things in line with our overall goals?
Mostly sensible, but a couple of points
Moderation. In addition to banning users, you can ban whole Matrix homeservers, which is what this is (I think, anyway - I see our moderation bot setting ACLs, so I’m assuming a little bit).
The harm is quite substantial actually. It depends on what the upgrade needs to do, but as an extreme example, #social:ansible.im is room version 1, so upgrading that would:
- create a new room
- copy the permissions, topic, settings, etc
- invite every user to the new room
- tombstone the old room (i.e. make it un-usable)
Now, that’s mostly a seamless operation, and users going to the old room will be told where to join the new one - but it’s still disruptive. Worth thinking about, especially in relation to Spaces, since the new room would need to be added to the space and the old one removed.
A higher-level user could add the Jitsi element early and leave it there, right? No need for other widget powers. In terms of havoc, there is a “Custom iFrame” widget, so technically you can embed anything into a Room.
Worth noting that I think only Element has widget support so far, so you may want to put the Jitsi url in the room topic or something to make it possible for other users to find it.
You may as well - it’s kinda moot on public rooms anyway since if a user can’t invite they could just share the room alias and tell people to join it.
1 Like
Thanks, that’s helpful. I notice a number of our rooms need to be upgraded — we should probably do that across all of them before Official Launch
1 Like
I’m thinking that for consistency, we should set all of these permissions using config management. @nb, @kevin, can we do this with the API and ansible?
I’m imagining giving a bot account permission level 95 and setting the level for “change permissions” to 95 on all rooms, and then turning it lose.
I think the answer here is yes… but not 100% sure. I played around with the api some this morning and I think we can make a ansible-playbook to set these. I’ll play around with it some more and see what I can come up with.
2 Likes
Admin permissions should never be used on Matrix, because one admin can’t demote another. Lots of groups were destroyed with this.
1 Like
It’s something you do have to be very careful with, yes. In Ansible we’re using Mjolnir to manage the community rooms, so only Mjolnir (and appservice, in bridged rooms) have PL100. Everyone else is Default or Moderator, and Mjolnir can promote people if there’s something that must be done manually.
I like that this means it’s not immediately obvious who does the kicking (because a member of the team with tell Mjolnir to kick/ban in the control room), the user only sees “Kicked by Ansible Admin: reason” which makes it less obvious who to spam if they are in the mood to retaliate.
I want to note there have been times I have used other widgets that were helpful. The etherpad in particular, as a “guestbook” for events. (would be nice if there was a hackmd.io widget 
)
1 Like
Yeah, I’d like to make this much less restricted — possibly lower than moderator only, even. I need a matrix expert to explain the risks, though.
1 Like
Most of Matrix widgets are too dangerous, IMO. They are iframes, loaded from the third-party servers (except self-hosted, of course).
I’d agree with that. I’d love it if mods could set an approved list of widgets, such that users could not just embed arbitrary iframes, but that’s not the case right now.
Also be wary of client support. Just because Element can do a thing does not mean all the clients can. This is especially true of widgets, I think. EDIT: I already said that above. Curse you, brain!
Is it possible?
Yes, most native Matrix clients has no widgets support because this feature needs full HTML iframe support and an embedded web browser (libcef or QtWebEngine).
Not today. I’ve not investigated what would be needed to enable it, but my guess is that it would need a spec change. Although widgets are pretty much Element-only, so perhaps it could all be handled client-side…
We definitely need moderators. #devel:fedoraproject.org suffers from spam.
2 Likes