Feedback on community moderation

[imax9000]

This post is a consolidated feedback from operators of multiple moderation accounts. We understand that changes we are proposing would take a lot of careful work to design and implement. But the current state is not sustainable and a change is sorely needed.

If you are running a moderation account and would like to have your signature added at the bottom - ping @imax in the #moderation channel on Bluesky API Touchers Discord.

Number one request

Customizing report flows. Hardcoded categories don't make sense for almost every moderation account out there. This results in user confusion and operators receiving a lot of out-of-scope reports.

This would also necessitate removal of the ability to send a report to multiple moderation accounts at once, since selected categories wouldn't necessarily exist for some of them.

Also add to this:

• Specifying circumstances for when a given moderation account should or should not appear in the reporting UI, e.g.:
  • Reporting a post that has no images to XBlock makes no sense.

Organizational & safety of operators

We need you to start cooperating with moderation account operators w.r.t. forwarding reports: have an established communication channels and policies/guidelines. Obviously, nobody expects you to immediately trust anyone who starts a new moderation account out of the blue. But you're still responsible for platform-wide moderation and we need to have clear communication on what you would and would not handle.

As for safety, community moderators are currently doing a lot of work for free, while being at an increased risk of harassment. This needs to change, harassment of individual moderators must be dealt with swiftly. The worst thing moderation accounts should worry about is users no longer trusting them, not being attacked by angry mobs.

Conceptual changes

Abstraction of a "labeler" might've made sense for Bluesky internally, where it is a part of moderation infrastructure that you're obliged to have. But releasing it publicly as-is feels rushed and not fitting to capabilities and assumed responsibilities of community moderation accounts.

We propose introducing a new account type: "moderation account". By itself this flag probably shouldn't do anything aside from hinting the UI that this not a regular microblogging account. What would make this flag meaningful is the ability to add more building blocks on top:

• Moderation lists
• Labels
• Accepting in-app reports

Allowing the account to select which it does want to provide and not use the rest would make for a more coherent experience. Part of it would be showing selected lists with a UI similar to label configuration, along with the ability to specify the default subscription option (none/mute/block) that takes effect automatically upon subscribing to the moderation account.

It would also make sense to break apart "labels" and "accepting in-app reports" into two independent pieces: account that only maintains lists might still want to accept reports, and not every labeler might want to receive them.

Social contract between moderation account and its users

Labelers have had the ability to emit !hide label for so long, that now it's an integral part of their toolkit. It is however still obscure and potentially misleading to users.

We propose to make it a more explicit part of the agreement between community moderators and their users. Keeping in mind that users still have the option to unsubscribe from the labeler altogether, allow moderators to disable some of the options of their advertised labels and lists, effectively enforcing subscription to them as a condition for continued use of their services.

Once this is implemented, start completely ignoring any undeclared labels emitted by a labeler. This would make it a lot more transparent to users, and support the use case that currently exists for the !hide label.

Important to note here that there are still cases where a labeler might want to have a generic force-hide label for things that are harmful, but don't necessarily fit into any of the more specific labels (e.g., abuse of the labeler itself). Moderation account should be able to declare such a label; whether it can be named !hide or not is to be decided.

Communication and transparency

Add an API for users to see the list of their reports and feedback on them. We've been long promised this, and there's even a proposal published, but it didn't get anywhere so far.

Important

The following paragraph is an over-arching concern that must influence the design of all other changes.

Another important thing on the communication front: from the very start take into account that label definitions, set of lists, and their default settings are mutable. Think through how to communicate the changes in them to users. Currently existing interfaces and functionality are geared towards "fire and forget" approach: any changes made from the moderation account side are not brought to users' attention and often go unnoticed.

Few other things that are also needed:

• A way for a moderation account to communicate with their users (that shows up in notifications)
• An appview tab with a sample of recent label actions

Ozone improvements

Finally, some requests for Ozone specifically:

• Hydrate item reported at time of reporting rather than at time of moderator viewing
• One click copying of at-uri and post text
• One click copying of did and displayName, handle, and description
• When post is labeled, create a comment in Account level ozone view-e.g., "Label action {id} recorded for {did} at {at-uri}"
• Batch export of reports to CSV (Not just the account info, but meaningful information about reports)
• One click forwarding of reports to one of pre-configured labelers
• Add support for LLM/AI services to help classify the reports and/or concerning content from firehose (e.g., Clavata.ai), with the ability to auto-acknowledge reports that are out of scope of a given labeler
• Outgoing webhooks for slack/etc notifications
• Ability to assign tickets to someone
• Ability for multiple people to effectively work through the queue

Signatures

• imax - maintains moderation lists and a labeler for the Ukrainian community
• scarnecchia - running skywatch.blue

[nekorug]

There are a lot of good suggestions here. Adding some of my own thoughts:

Personally I think users should be able to block users with certain labels instead of lists being made more prominent on a moderation profile. Labels are what moderation accounts use to provide data to the user, and the user should be able to act on that data alone without the need for moderation lists.

My number one request for moderation is to let users threadgate using labels from moderation services, ideally setting a default value and being able to customize it per thread. If I'm posting about topic Y and there's a good labeler who has a label for "Y haters" then even if I don't want to fully hide/block those users, I would want to specify that in those specific threads their replies are not welcome and would not be shown to anyone, as if I blocked the users (or at least hidden like if I hid the reply). If many people did this for their threads, this would make the "community" aspect of "community moderation" a lot more prominent. I really think that consensually saying "I want this labeler to protect my thread" is what could make third-party moderation actually viable.

I know the developers have not wanted to make third-party moderation services too visible now in their early stage, I still think it'd be nice to see what services a user has "liked" on their profile. This could also be visible in Ozone for a user, as for certain labelers that could be a signal for "I consent to be moderated by this service" or "I am in need of protection by this service."

[imax9000]

Thank you!

Personally I think users should be able to block users with certain labels instead of lists being made more prominent on a moderation profile. Labels are what moderation accounts use to provide data to the user, and the user should be able to act on that data alone without the need for moderation lists.

I think this part is better addressed by elevating lists to the same level as labels in terms of visibility and UX. Big point of this post is that labels aren't and shouldn't be the centerpiece of moderation - they should be just one of the available tools that integrates well with the rest.

[arkangel-network]

These are good suggestions.

[scarnecchia]

Signing onto this for Skywatch!