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?
This is a placeholder for a policy we need:
Would it make sense to follow FAS permissions in rooms that are synced to a team? Like map FAS roles to admin/mod/user?
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.
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:
These, I’m unsure of giving to moderators:
These I think we definitely want to give out to moderators:
And, this defaults to “Moderator” permission, but I think maybe should be given to everyone?
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:
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.
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
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.
Admin permissions should never be used on Matrix, because one admin can’t demote another. Lots of groups were destroyed with this.
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 )
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.
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.