Labelers
Publish AT Protocol labels that Standard Reader shows — and can warn on or hide by — as readers read.
Overview
A labeler is any DID that publishes AT Proto labels. Readers add one by DID on the Labelers page, and Standard Reader then shows that labeler's labels — and can warn on or hide labeled posts — as they read. Labelers are discovered the standard way; nothing about them is specific to us.
Running a labeler
1. Identity & signing key. Give it a DID (a did:web is simplest) whose DID document advertises an #atproto_labeler service endpoint and an #atproto_label public signing key.
2. Serve labels. Sign and emit com.atproto.label.defs#label objects, and expose the standard com.atproto.label.queryLabels (HTTP) and com.atproto.label.subscribeLabels (WebSocket) endpoints.
3. Declare your label values. Publish an app.bsky.labeler.service record in your repo describing each value — severity, default warn/hide, blur behavior — and advertise #atproto_labeler in your DID document. That is the standard AT Protocol declaration, documented in the labels specification; there is nothing Standard Reader specific to do.
We used to also accept a labeler registered by a Standard Reader‑specific descriptor record. That is gone. It existed only so a did:web labeler — which has no repo, and so cannot publish the standard declaration — could join the directory. If you already run a labeler for the wider network it works here unchanged, which was always the point: a labeler can label any content on the network, so there is no reason for this app to invent its own way of describing one.
Labels may apply to a document's at:// URI or to an account DID. Account labels are shown on that account's author and publication pages and on every document it published, so a label about a publisher does not need to be re-emitted per post.
4. Let readers subscribe. When a reader subscribes we write an app.standard-reader.labeler.subscription record to their repo, carrying their per-label warn/hide preferences.
That record also carries an enabled flag. A reader can mute your labeler here — keeping the subscription and their per-label settings, but not applying your labels while they read — without unsubscribing, which is useful when they follow a labeler on another app that they don’t want acting on long-form reading. Its absence means enabled.
Further reading
Labelers are an AT Protocol concept, not a Standard Reader one, so the protocol documentation is the reference: labels covers the label object, its signature and the queryLabels / subscribeLabels endpoints, and moderation covers how labels are meant to be applied. Anything that satisfies those works here.
Standard Reader no longer ships labelers of its own. Running one taught us nothing the network doesn't already provide, and for the one signal we did use — an account declaring itself a bot — the answer was already in its profile record, so we read it there instead of asking a labeler to repeat it.