Does Bluesky want full-stack community moderation or just metadata labelers?

[scarnecchia]

Yesterday, @bnewbold posted the following:

"meta" labels like !hide are powerful because they are silent. subscribers should have more control over these for non-mandatory labelers, or even just disabled them for those cases.

I'm strongly opposed to it and would likely shut down Skywatch if the ability to apply these labels was removed from community moderation services or if an opt-out was given to users (beyond unsubscribing to the labeler).

The choice the labeler wants the user to make is to not use it if you would prefer to see something we’ve hidden behind a !warn or !hide label. We want to force that choice and offer an editorial voice. Otherwise, you essentially neuter community moderation and I don't see any point in running ozone with all its overhead to create what amounts to a glorified mutelist. As rahaeli notes:

Either the purpose of a labeler is to issue opinionated statements about what content its subscribers should not be exposed to, or they're just one overridable signal among many others. And the former conceptualization is an absolute necessity if you want full-stack moderation services to exist.

At the end of the day, something needs to be done to distinguish between fun labelers that apply badges and moderation services, but by removing the !warn and !hide option as currently implemented will simply remove the only actual moderation tool available to moderation services.

[scarnecchia]

And to illustrate how we use the !warn and !hide labels:

We apply !hide to posts which share things like animal crush videos, some other examples of extreme gore, or some violent extremist content. We pair this with a report to Bluesky moderation.

We apply !warn to to accounts which are explicitly branded as certain types of extremists along side the appropriate label. We also will selectively (but very rarely) apply !warn to other accounts as an editorializing action—one that is intended to say "If you follow this account and use our service, you need to understand that this service does not think its users want to see this content." Again, we want to shape the information space by making it inconvenient to follow that user and thus force the binary choice between the using the service and following said user.

If users disagree, they will unsubscribe (this is where having more metrics would be very useful) and register their complain. The market will take care of abuse of these labels, and if there is disagreement with certain choices we make but a need for other labels we offer, then the market will fill that by standing up another labeler.

[bnewbold]

We definitely want to enable full-strength / full-stack moderation services in the network.

Our original conceptualization of how and when moderation services are "mandatory" versus "user configurable" was different from the distinction you have laid out around the bang-labels, and in some ways stronger. I'll describe that a bit first, then come back to your specific point.

One layer of moderation in the network is infrastructure. We want to minimize the degree to which moderation decisions and governance are bound to the capital and operational costs needed to run infrastructure, but there will always be some degree of infrastructure moderation. The labeling system does not necessarily factor in to that, but "moderation services" as an identity and concept can. There are not a ton of independent PDS, Relay, and AppView instances in the network today, but when they emerge, they will need moderation, and Ozone instances and independent moderation teams should have the power to participate in that type of moderation, if they are interested and able to do so (and negotiate a relationship with the infrastructure operator). Takedown actions at the infrastructure label are as strong and "full stack" as they get: no user of that infrastructure can access the content. This probably feels far from the situation today, but we hope and expect alternative infrastructure to start taking off early this year, and "situations" will arise rapidly. I'm also using it to make the point that at least some moderation services have a path to being as full-stack as the Bluesky moderation service over time.

Another layer of moderation are "mandatory" labelers, which are entangled between clients and API services like the AppView. When clients make API requests, they indicate which labelers they want applied; they can also indicate for each labeler if that is a "mandatory" or "regular" configuration. If a mandatory labeler uses the special !takedown label, the result are completely removed from the API request by the server. In this way, they are a kind of hybrid between infra moderation and client-level. They are intended to be baked-in to client software, and not user-configurable. The user can "exit" this decision by using a different client app (which would mostly access the same network, users, and content). The thinking with this is to move power and decision making away from infrastructure (the AppView) towards the app client, which is more likely to be a "brand" which the end user is familiar with, and more directly engaged with moderation (and the product decisions which impact moderation) than a pure infrastructure provider.

The last layer is labelers as they exist today, which are selected and configured by users.

The !hide and !warn labels were an escape-hatch we built in to respond to new moderation issues quickly, without having to roll out client code changes or label definitions. That was happening a lot at the time! We did not think carefully about whether they should only work with "mandatory" labelers. The current situation is not well documented, legible to users, etc.

That is all history. Where we are today is that the system has had months to bake, and expectations and workarounds have grown up. Alternative infrastructure and clients have not gotten a lot of traction in the network, so those aspects of moderation and community dynamics have not emerged. There is pressure to make moderation services more powerful to compensate, which could be via the labeling mechanism, or mod lists, or other new mechanisms.

I'm not sure the bang-labels are going to be the right tool in the long run. But I don't think we will make any sudden changes to the system without time for feedback on the changes. And we are likely to add strength/capabilities to labelers at the same time if we were going to take any away.