Labels are a protocol primitive for composable annotation of accounts and content across the network. They were primarily designed for moderation, but the mechanism is generic and can be used in many ways beyond simple identification of harmful or violative content.
A limitation with the current system is that a label conveys very little context: basically just a short label value string. In a lot of situations it would be helpful if the creator of the label could convey a bit more information to recipient users. For example, a reference to the specific policy which was violated, evidence backing up the decision, or a longer free-form statement about the assessment. It is important for labels themselves to remain minimal and compact, but they could include references to additional context.
This post proposes adding an optional ctx field containing a flexible reference URI/URL, and describes a couple possible use-cases. This field would be entirely voluntary: labeling services would not need to provide additional context if they do not have the motivation or resources to do so.
Showing Receipts
One use-case would be referencing additional evidence about a label decision. For example, an inauthentic label might link to a blog post describing a recent or ongoing wave of bot accounts. Or a ban-evasion label could reference the original account (by DID, or URL) that was originally actioned.
Detailed Policies
Another use-case would be referencing a specific detailed policy. In the current labeling system (at least as implemented for the app.bsky modality), labelers can declare a set of labels, with a description of each. But there are soft limits on the number of labels that can be declared (on the order of dozens), and the UI does not accommodate verbose description text. There is not room for examples, especially for visual content.
The ctx field could be a web URL pointing to a documentation or support page that goes in to more detail about the specific policy that was violated. This could be be used to resolve granularity mismatches between a set of label values and policies. For example, the label might be spam, and the URL could direct to a more specific policy about engagement farming.
Fact Checking and Investigations
This feature has been frequently requested by fact-checking organizations. For their use-case, there are usually investigating write-ups with in-depth information about a claim. The same investigation is usually relevant to a number of posts; eg, all posts sharing a specific media image or web URL.
The ctx reference could go to a web URL. Or it could go to a summary card record, which includes a title and short description in multiple languages (which could render natively in-app), and then an additional URL (in the summary record) linking to a full write-up (which would open in a browser tab).
Community Notes
The ctx mechanism could be used to implement "Community Notes" features, as a form of collective assessment and contextualization. In this case, an "annotation record" would be referenced by AT URI, and client apps would know how to render them.
Different label values could potentially be used to indicate different levels of confidence: for example, a proposed-note label could be disabled by default, but enabled by users participating in the consensus process.
Technical Proposal
The proposal is pretty simple: just add an optional ctx string field with uri format to the label data schema. This field would fall under the cryptographic signature. The expectation is that it would be passed through (hydrated) to clients in API responses. The label authority could effectively update the field by emitting a new label, with an updated timestamp (cts) and an updated (or removed) ctx field. The field value could be any URI or URL: an AT URI (referencing a record), a web URL, etc. The reference resource could be a unique resource specific to the individual label, or a static resource.
When referencing an atproto record (by AT URI), this would not be a versioned "strong ref" (it would not include a CID). My intuition is that it just isn't needed here; mutability of the referenced content is an advantage; and that we should keep labels as compact/efficient as possible.
If the field value is a web URL, client apps would display a generic link saying something like "More information here". For AT URIs, client apps could parse out the record collection (NSID) to determine the behavior. Appviews might pre-index context records of specific types, or could fetch individual records on demand when the label is indexed. They could then hydrate and render the context record in app-specific ways. If the app did not support a collection type, it could indicate in the URI that there is additional context which could not be rendered.