Sitemods

[not-layla]

Sitemods are privledged users that can remove comments/posts etc across the instance, but don’t have access to site configuration like admins do.

[Nutomic]

So the main purpose of this would be to avoid that a single hacked/malicious sitemod can change the instance config, right? Another way to implement that would be that all such changes need to be approved by eg 50% of admins before being applied. That would be more in line with https://github.com/LemmyNet/lemmy/issues/417, and it has more potential, as the same logic can be applied to community changes, and in other places.

[dessalines]

Also if the sole purpose of this is to just not allow instance config changes, I'd be totally find with removing that, as it doesn't really work right now anyway. Then we could avoid all this extra complication of adding types and layers of admins.

[not-layla]

@dessalines It's not just for changes to the configuration file, it's for anything under /admin.

@Nutomic The point is instance owners can get help with site-wide moderation without having to trust them with access to /admin. I suppose voting could solve this issue but (a) it still means making new admins have equal power as old admins, and (b) democratic moderation is still a very very long way away I'm guessing.

[dessalines]

We should probably re-organize these all under the /admin route, but the current admin API actions are:

• Dealing with registrations
• Adding other admins
• Banning users
• Transferring communities
• Removing communities
• Removing user content ( doesn't DB delete anything )
• Getting and saving the site config
• Transferring the site (only available to the top admin, so not applicable)

Before creating complicated layers of admins, we need to discuss which of those actions if any need to be restricted in some way to a subset of admins. A note that none of those actions can actually delete anything in the database. Any removed content, or even community can be restored at the click of a button.

The only one that has the potential to bork the site, is saving site config.

IMO rather than creating a separate type of admin, we should mark out the ones that maybe only the top admin should be able to do. The only one I see there, is saving the site config, and maybe removing communities.

[TheCoolZone]

The distinction between moderators and admins is a decades old concept, so I'm not really seeing why the idea is contentious? Attaching examples of phpBB configs that have been around since at least the early 2000s. The granularity is there because there are time when admins trust a global moderator just enough to manage individual users or support comm moderators but don't trust them with management of comms themselves.

IMO, part of this has to do with user perception of moderation activities. If bad mods are promoted to too high of a level too early and need to have a bunch of their decisions reversed, then it immediately lowers user trust in site moderation generally. This is something I've personally witnessed on other sites and is just a realistic potential outcome of things regardless of design ideology.

[dessalines]

We have community moderators and site admins, similar to reddit.

As far as breaking up site admins into various layers / groupings of abilities, what do think those layers and abilities should be?

[pixlguru]

imho for now it would be ok to just hide the server-config from the UI until there is a more evaluated solution. this is basically preventing me from assigning others as admins right now.

[dessalines]

@Nutomic What are your thoughts on just removing the config_hjson stuff? That's caused more trouble than its worth IMO, and it does expose some dangerous things.

[Nutomic]

I am mostly fine to that, but not having direct access to federation allowlist/blocklist would be a big limitation. Same might be true for the slur filter, but probably less important.

So if we do that, I think we need to move at least the allowlist and blocklist into database.

[dessalines]

So if we do that, I think we need to move at least the allowlist and blocklist into database.

I def think that's a good idea, also even for the slur filter too. I'll open up an issue.

[not-layla]

Hey, so is this something y'all are interested in? I got the impression from the initial discussion it wasn't, but I saw this recently

[poVoq]

I think it is useful, even if not for purely technical reasons.

First of all it allows giving people some recognition for vital moderation work and also allows making the admin accounts a bit more fully featured than they are right now.

[dessalines]

This is probably moot now, since we've moved all the site wiring into the lemmy.hjson, and the configuration into the database.

The only destructive things that admins can really do now, is purging (which deletes things from the database, and they're not restorable).

Besides that, I can't think of any action that would differentiate a "Sitemod" from an admin.

[not-layla]

The remaining concern I have is mainly semantic but I still think it's worth discussing.

I think there's still value in having a concept of a sitemod versus an admin. An admin is seen to be a leader of the community, someone who makes decisions and steers the community as a whole. A sitemod means someone who's a mod on all communities. The difference being that admins make decision on site policy/announcements, sitemods are there to help deal with spam, trolls, etc.

We could probably make all sitemods on Hex admins, but the hierarchy won't be obvious anymore.

[poVoq]

I agree that the distinction is worth-while, however I see admins more as those running the infrastructure and due to the inherent power-imbalance resulting from that, might rather feel especially reluctant to intervene in community disputes or make policy decisions unilaterally BDFL style (although sometimes that's unavoidable).

[not-layla]

At least the way Hexbear is set up, developers and infrastructure people are not admins. Admins are what I describe above (non-technical community leaders), developers/infrastructure people do just that, and sitemods are there exclusively for moderation.

[Nutomic]

I agree that it makes sense to have such a site mod role.

[dessalines]

I'd need a specific list of abilities / actions that differentiate the two.

[poVoq]

For example: block local & remote users instance wide, but not block full instances?

[dessalines]

I disagree with that one, sitemods should def be able to block instances, that's the main way lemmy servers are being attacked currently (open federation, someone spins up a malicious instance, and does nazi-spam).

[poVoq]

Maybe temporary instance blocks only?

[not-layla]

A temporary instance block sounds like a good compromise to me. Something the Admins can then decide on making permanent, which imo is above what a sitemod should be able to do.

[dessalines]

We don't have temporary instance blocks even for admins yet, so that's a separate issue.

[not-layla]

So do we agree that sitemods will be able to do the following?

• Temporarily block instances (will require a new issue)
• Remove posts comments anywhere on the instance
• Ban users
• Lock posts
• Appoint/remove mods
• Feature posts instance-wide

There are probably some things I'm missing, but hopefully that gives a rough idea of the privileges sitemods should have.

[poVoq]

Appoint/remove mods

I think that will also require a separate issue as Admins also seem to be unable to do that? I know there is a way to do it somehow, but I have not yet found it in the UI.

[not-layla]

On Hexbear, admins and sitemods make somebody a mod by pressing the appoint as mod button on a comment the account they're modding made in that community. I recently made a community on Lemmygrad and it seems to work similarly for a comm-mods, not sure about admins on Lemmy though.

[poVoq]

Ah, never mind. Its the same on Lemmy. The problem is just that a site Admin can not do it on themselves it seems.

[dessalines]

@not-layla None of those are things that admins can't already do. Again I need a list of things that differentiate the two, not the things they'd have in common.

[poVoq]

As a subset they will obviously have a lot in common. Just take everything the Admins can do, substract the list above, and you got the difference.

[not-layla]

Is there a full list of actions an admin can do? If not, I think these are the differences:

• Sitemods can only block/defederate instances temporarily
• Sitemods can't access any site configuration (if it still exists, I don't have a local Lemmy instance running anymore, but e.g. they can't access anything under /admin).
  • Create/remove communities
  • Disabling/enabling community creation
  • Turn off/on registration
  • Turn off/on downvotes
• Sitemods can't promote other users to sitemod
• Sitemods can't promote community users to community moderator
• Sitemods can't mass-delete/purge an account's history