Update on Protocol Moderation
Where account takedowns happen is important
s I said recently, I’ve been compressing my descriptions of AT to two major roles. This is a simplification, but it captures the important dynamics:
As lots of applications can access your account and data, the relationship is rather more like this:
If an application decides you’ve crossed its moderation policies, it should pause and/or filter your activity in the application for the duration of the suspension. This should have an effect that’s localized to the application, which is where moderation is applied.
Separately, if a PDS decides that you’ve crossed its moderation policies, it should pause hosting your account and announce it is no longer available. This affects the account across all applications:
If the user subsequently migrates to a new PDS, the account will be restored to the applications:
An account takedown on a PDS is a big deal because it affects all applications. PDS operators should be reserving the takedown for network abuse and illegal content, if possible. Migrations should also be available post takedown, to the extent that a PDS can offer it without enabling complete resource abuse.
I was surprised to discover recently that our account suspension system has been operating entirely at the PDS level. This appears to be due to a workstream that got dropped in the early 2024 rush to open the network. What should be happening is that we apply a strong label such as `!takedown` which applies locally to our application.
This is rather important for a number of reasons:
- The idea of a suspension on Bluesky that could affect Leaflet or Tangled is bad
- Suspensions at the PDS level are ineffective; a PDS migration circumvents it
- The Bluesky application server allows clients to replace the labeling system, which lowers the cost of running alternative moderation; using labels for account suspensions would better enable that
This is being fixed. Takedowns and suspensions which are not due to legal or network-abuse reasons will be handled using labels, which will be removable using the labeler header.
You’ll also be hearing some news soon from the protocol team about improving migration and supporting independent PDSes more effectively.
