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.

[Hoid]

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.

I 100% agree with this! I feel like we should be able to curate spaces that we can post in that are still public but in which we don't have to worry about engagement with people you don't want to engage with. I firmly am of the idea that you Should Not Fight With People You Don't Know Online. What that looks like could be vary, but at its core for post content I think it looks like open viewing, semi-closed interacting.

One way you could do this is by setting up your own list of people you consider part of your "bubble" online. It's the people you feel safe interacting with. By default, this should include everyone you follow, but you should be able to remove someone you follow from that list too if you just want to follow them and not have them interact with your posts. Maybe you can choose whether people inside or outside your bubble can DM you, reply to your posts, quote reply to your posts, etc. This also gives you the ability to give people ways to intentionally step out if their bubble and see new kinds of posts. I can imagine feeds where you have a feed for every degree of separation from your bubble, so that you could have a feed of posts that are specifically within your bubble's bubble, or wider, which allows you to see a gradually broader horizon of content.

Specifically for labelers, I think your idea to threadgate on labels would add another layer on top of this that's really interesting. And perhaps you could integrate labels into this "bubble" such that anyone with certain labels isn't considered to be a part of your bubble online.

[scarnecchia]

So I view this as an entirely different product—a valuable one at that, but essentially it would have the constructed as an add on. I essentially envision a service that you sign into, the service subscribes to labelers on your behalf, and then gives you a UX to pick the labels you want to subscribe to from each, along with an allow list, and then it creates a custom labeler for you that emits the combined labels.

However, I'm firmly in the camp of not abrogating the ability of community labelers to actually do moderation as they see fit, so I personally only see it as something that should be offered through a third party service. See also my post here: #3278

[arkangel-network]

These are good suggestions.

[scarnecchia]

Signing onto this for Skywatch!

[bnewbold]

I'm working on a long reply to this, but it isn't ready quite yet.

[imax9000]

Thank you! Looking forward to hearing from you.

Also note that I have already started work on publishing a more comprehensive moderation stack: https://github.com/bsky-watch/modkit

[bnewbold]

There is a lot here! We will probably have some separate writing in coming months about the overall stackable moderation situation, categories of problems, and proposals to address them. This post is more of a point-by-point reply, though I might not hit them all.

Report routing, meaning that users send (and mod services receive) reports which are relevant and in-scope for them, is definitely a top issue and something we are planning improvements to. This will probably not ever be perfect, and the initial improvements might be "coarse" rather than "granular". Eg, we might make things clearer by broad category of report to start, then come up with some separate solution to things like "no image posts" (or "only image posts") as a follow-on.

Governance of moderation services, and safety of moderators: these are definitely big concerns! I think governance should probably be independent, not contingent on Bluesky PBC, even if Bluesky helps support and provides resources. How to assess and meta-moderate services is important. Harassment of any individuals in the network isn't acceptable, and resources for at-risk folks (like moderators) would be good. Managing trust and responsiveness between moderators and their community is just hard in general. Mechanisms to clarify scope and "constituency" could help with this, and mechanisms to improve communication and transparency, might all help, but at the end of the day managing trust is a challenge.

Conceptual grouping of functionality: yup, we are discussing ways to "re-bundle" things, and clarify the intent, powers, and behaviors that services can have. For example, some projects using the "badging" functionality are lower-stakes and appropriate to run as a single developer with arbitrary audience. Other more high-context moderation work probably has a more specific relationship with a specific "constituency", and both clarifying expectations and even formalizing those relationships could help.

Moderation history (aka, status of reports): we are working on that feature, as proposed. There have been a lot of other urgent tasks, but you can track progress on this in git across multiple repos if you go digging.

Comms: as things are today, labelers are full accounts and can make Bluesky posts. There might be ways to improve this functionality, like "strong follows" that come through as push notifications, or making it more obvious to "follow" labelers in addition to "subscribing".

Recent label actions from a service: I can see some upside to this, but it also seems like it could go wrong or frequently be unhelpful. In general, I personally think that assessment of moderation should move more away from individual cases to broader patterns. Context like "number of labels by type for each of the past 7 days" feels like it might be more helpful. For folks that really want to dig in, I think a separate web tool (instead of in-app) might be better.

Ozone is a large project, and we need to balance the needs of our own mod team with independent mod teams. The surges in late 2024 required a lot of urgent features and fixes for our team. In general, having the UI and backend shared has worked well to ensure basic bugs and usability issues get solved; imagine the contrast if we were building a tool which we didn't use ourselves. At the same time, it isn't clear if that alignment will work well forever. One somewhat unexpected thing is how many independent Ozone instances have large teams which need to work queues concurrently; this is a sort of "at scale" feature we use ourselves.

The "snapshot" functionality in Ozone (to cache records at time of report, to review in case of edits or deletions) has been needed for a long time, both for us and others. One-click copying sounds good, please open an issue if there isn't one. For account-level comments, it is possible in the UI to see full-account actions (including reports), though it requires some clicking from the quick-action modal. We are working on some account-level overview statistics which should help with context.

For CSV exports, would a CLI tool work? The API exposes a lot of lists and data which could be pulled down via goat. We have experimented a bit with CSV in the UI, but different folks tend to want different things (even in the same team).

Report forwarding between instances: open to something like this, but raises issues around user expectations and privacy. One option would be a way to send back a message to the user recommending that they report to a different service. Giving specific projects or individuals special attention when passing along reports will require careful thought and policies: if we treat any report coming from a labeler as special, that rapidly sets up an incentive for folks to create labelers just so they can get leverage.

Slack notifications: we use external tooling for this. Different teams use different tools (Discord, email, IRC, telegram, matrix, etc), and I think keeping "integrations" external as plugins tends to work out better in the long run. Could be wrong though.

Assigning tickets to individuals: this is a workflow pretty different from how we use the tool. It would be possible to approximate this with tagging, but if this overall modality is more important than things like tags, it might require a different architecture or alternative tooling.

Multiple people working queues concurrently: Ozone does have basic functionality for this, and we use it heavily. It isn't very ergonomic to set up, and not documented, we might iterate on it.

[imax9000]

Comms: as things are today, labelers are full accounts and can make Bluesky posts. There might be ways to improve this functionality, like "strong follows" that come through as push notifications, or making it more obvious to "follow" labelers in addition to "subscribing".

You've missed the point: such communication must not require any additional action from the user beyond subscribing.

[imax9000]

Recent label actions from a service: I can see some upside to this, but it also seems like it could go wrong or frequently be unhelpful. In general, I personally think that assessment of moderation should move more away from individual cases to broader patterns. Context like "number of labels by type for each of the past 7 days" feels like it might be more helpful. For folks that really want to dig in, I think a separate web tool (instead of in-app) might be better.

Yeah, the goal is to help users to assess how the moderation account applies its policies. Label counts would be good too, but I strongly believe that having at least a few concrete examples is also critical.

For digging in I can already do go run bsky.watch/labeler/cmd/dump@main --from https://mod.bsky.app. But users should have, inside the app, enough information to make the assessment for themselves.

[imax9000]

Report forwarding between instances: open to something like this, but raises issues around user expectations and privacy. One option would be a way to send back a message to the user recommending that they report to a different service. Giving specific projects or individuals special attention when passing along reports will require careful thought and policies: if we treat any report coming from a labeler as special, that rapidly sets up an incentive for folks to create labelers just so they can get leverage.

Yeah, I mentioned that you don't have to trust any random moderation account. It's expected that growing mutual trust requires time.

There are two aspects to this particular request:

1. Forwarding mis-directed reports to an appropriate place: has nothing to do with trust, it's simply a remedy to the current confusing UI.

2. Treatment of the forwarded reports on the receiving side: in short, it's out of scope for the Ozone request specifically. It's fine to treat it just as any regular report.

   In a greater picture though, for having a clearer communication between you and us, ultimately the only thing it would do is allow you to have a sub-slice of reports with a higher signal-to-noise ratio (thanks to underlying assumption that it was already looked at by someone doing moderation and decided that it was worth your attention). Of course, it's for you to decide which moderation accounts to include in that slice, it absolutely shouldn't be automatic just on the condition that it is a labeler.

   And the same applies for relationships between different community moderation accounts: @skywatch.blue might want to forward reports to @blacksky.app if the reported content is racist, and it's up to @blacksky.app to decide if it deserves to be treated differently from the bulk of the reports.

As for privacy and technical details, I already gave it some thought:

• No need for any new API, just use the existing createReport method
• Send the report as the moderation account - no need to reveal the identity of an individual moderator or the user who reported it to them
• Configuration fields to specify a set of destinations to select from

Basically, make a streamlined version of the in-app reporting flow, maybe pre-filling reason and reasonType.

[imax9000]

Slack notifications: we use external tooling for this. Different teams use different tools (Discord, email, IRC, telegram, matrix, etc), and I think keeping "integrations" external as plugins tends to work out better in the long run. Could be wrong though.

You can add a relatively simple webhook support: both Slack and Discord support them, and you can add a third payload format that is Ozone-specific and isn't bound by limitations of Slack or Discord.

[imax9000]

As for the rest of Ozone-specific things - I'll defer to people who actually use Ozone

[bnewbold]

Here are a few things on our radar which I don't think you mentioned:

Persistent confusion about "account-level" and "post-level" actions (and sometimes profile-record-level as a third option). This certainly applies to how badges are displayed in the app, but they also impact Ozone usability.

The out-of-box setup process isn't as smooth as it could be. Particularly around debugging label stream issues between Ozone and AppViews.

Basic built-in statistics around report volume and action rate would be helpful for everybody.

Queue filtering and sorting by priority, including leveraging the "tag" functionality in a generic way.

More documentation and examples around how to use Ozone for infrastructure-level moderation, now that alternative PDS instances, Relays, and AppViews are becoming more common.

Moderation lists are quite powerful, and there isn't a mechanism to "override" them for individuals today. Sometimes this is requested as "boolean combinations of lists" or "allow lists". One option would be weaking the "block" functionality of mod lists compared to regular blocks, and allowing "follow" relationships to override (including for visibility).

Re-visiting label rate-limits. This might just mean justifying the current limits better, if we can't increase them.

[imax9000]

A few of these issues would not exist if you took advantage of any existing ticket management system, instead of letting your NIH syndrome to create Ozone :)

[imax9000]

Moderation lists are quite powerful, and there isn't a mechanism to "override" them for individuals today. Sometimes this is requested as "boolean combinations of lists" or "allow lists". One option would be weaking the "block" functionality of mod lists compared to regular blocks, and allowing "follow" relationships to override (including for visibility).

Yeah, I even filed at least one of those requests myself, and there are already an extensive discussions on this out there. Only thing I want to reiterate about this is that "follow" should not automatically override a block/mute-list. In such cases "follow" and "list subscription" are both an explicitly expressed user intents, and when they come into conflict the resolution requires user attention. When that happens, user might not always want to add an exception, but also consider unfollowing the account or unsubscribing from the list.