labels#

labels are signed assertions about content. they're how applications do moderation without affecting the underlying data.

the key distinction#

remember the two roles:

PDS: hosts accounts, affects all applications
Application: consumes data, affects only itself

if a PDS takes down your account, you're gone from all applications until you migrate. this is the nuclear option - reserved for illegal content and network abuse.

labels are the application-level mechanism. when bluesky labels your content, it affects bluesky. leaflet can ignore those labels entirely.

from update on protocol moderation - paul frazee

what labels are#

labels are metadata objects, not repository records. they don't live in anyone's repo. a labeler service produces them and serves them via XRPC.

{
  "ver": 1,
  "src": "did:plc:labeler-did",
  "uri": "at://did:plc:xyz/fm.plyr.track/abc123",
  "cid": "bafyreig...",
  "val": "copyright-violation",
  "neg": false,
  "cts": "2025-11-30T12:00:00.000Z",
  "sig": "<base64-signature>"
}

src: who made this assertion (labeler DID)
uri: what content it's about
val: the label value
neg: true if this negates a previous label
sig: cryptographic signature

signed assertions#

labels are signed using DAG-CBOR + secp256k1 (same as repo commits). anyone can verify a label came from the claimed labeler by checking the signature against the labeler's public key in their DID document.

this enables trust decisions: you can choose which labelers you trust and how to interpret their labels.

labeler services#

a labeler is a service that:

analyzes content (automated or manual review)
produces signed labels
serves labels via com.atproto.label.queryLabels

POST /emit-label
{
  "uri": "at://did:plc:xyz/fm.plyr.track/abc123",
  "val": "copyright-violation",
  "cid": "bafyreig..."
}

from plyr.fm moderation service - runs copyright detection, emits labels for flagged tracks.

stackable moderation#

multiple labelers can label the same content. applications choose:

which labelers to subscribe to
how to interpret each label value
what action to take (hide, warn, ignore)

this is "stackable moderation" - layers of independent assertions that clients compose into a moderation policy.

negation#

to revoke a label, emit the same label with neg: true:

{
  "uri": "at://did:plc:xyz/fm.plyr.track/abc123",
  "val": "copyright-violation",
  "neg": true
}

use cases:

false positive resolved after review
artist provided licensing proof
DMCA counter-notice accepted

label values#

common patterns:

val	meaning
`!takedown`	strong: hide from view
`!warn`	show warning before content
`copyright-violation`	potential copyright issue
`explicit`	adult content
`spam`	suspected spam

applications define how to handle each value. !takedown conventionally means "don't show this" but applications make that choice.

querying labels#

GET /xrpc/com.atproto.label.queryLabels?uriPatterns=at://did:plc:*

{
  "cursor": "456",
  "labels": [...]
}

applications can query labels for content they're about to display and apply their moderation policy.

why this matters#

labels separate moderation concerns:

PDS operators handle illegal content and network abuse
Applications handle policy violations for their context
Users can choose which labelers to trust

no single entity controls moderation for the entire network. applications compete on moderation quality. users can route around overzealous or insufficient moderation by choosing different apps or labelers.

Configure Feed