NIP-32: Labeling
Moderation and classification needed portable metadata
NIP-32 gives Nostr a way to say something about an event, person, relay, addressable object, URL or topic without changing the original thing. That sounds abstract until you look at the use cases: distributed moderation, content warnings, license assignment, language tags, collection management, topic association and reputation systems.
A label can be self-applied or published as a separate kind 1985 event. That separation is important. A creator can label their own note as English or location-related. A moderation service can label someone else's event as spam, violence or approved. A curator can label a set of events under a topic or license.
The network effect is clear: labels let many parties annotate the same public object without needing a central database. The hard part is namespace discipline. Without namespaces, labels become words floating without context.
Namespaces, labels and label targets
The L tag declares a label namespace. It can be a standard name, a reverse-domain namespace or a special marker such as #t to associate a target with a normal Nostr tag value. The l tag contains the label itself and normally points back to the matching L namespace.
A kind 1985 label event targets one or more objects through e, p, a, r or t tags. That means the same mechanism can label an event, pubkey, addressable object, relay/URL or topic. The event content field can carry explanation when the short label is not enough.
NIP-32 also allows self-reporting by placing l and L tags on other event kinds. In that case the label applies to the event itself. The distinction between separate labels and self-labels lets the same vocabulary support moderation services and normal author metadata.
A moderation primitive became a general semantic layer
Jonathan Staab added NIP-32 in May 2023 and shaped much of the early file: namespaces, self-labeling, multiple targets, relay hints, replacement decisions and concise examples. The early history shows a standard trying to avoid both chaos and over-formalization.
Later updates refined the naming and constraints. Sandwich clarified summarization language. Jon Staab relaxed L requirements, added ontology notes and later strongly encouraged marks on labels. Alexander Lopatin added the language example. The 2024 addressable-event renaming touched the file as the wider terminology changed.
The file now reads like an active compromise. It wants namespaces to be unambiguous, but it also says namespaces are public and not proprietary. It encourages reuse of existing vocabularies before inventing new ones. That is exactly the tension a decentralized label system has to carry.
Labels become useful only when clients choose vocabularies carefully
Nostrbook's kind 1985 page describes labels as a mechanism for moderation, classification, licensing and semantic connections. Nostr Compass frames NIP-32 as structured metadata that clients can use for categorization, content warnings, reputation systems and moderation. Those explanations line up with the spec's real purpose: labels are a shared annotation layer.
A useful implementation starts with a small vocabulary. A moderation tool may choose a namespace for review outcomes. A media client may use labels for licenses. A discovery client may use labels for topics or languages. The mistake is to create a vague label vocabulary that no other client can understand.
Query behavior matters too. Since L and l are tags, relays can index and filter them. Publishers are encouraged to limit a label event to a single namespace to avoid ambiguous queries. Bulk labels can be retracted with NIP-09 deletion requests and replaced by new label events.
Labels can help moderation or become a new reputation battlefield
The main risk is false authority. A label is a signed claim by a publisher, not an objective fact. A trusted moderation service and a random hostile account can both label the same pubkey. Clients need trust decisions around whose labels they display or act on.
The second risk is vocabulary fragmentation. If every app invents its own namespace for the same concept, labels become less interoperable. If everyone reuses a namespace without understanding it, labels become misleading. NIP-32 gives the structure; communities still need governance around vocabularies.
Read NIP-32 in the wild
NIP-32 gives labels a signed structure. A label can describe content, people, topics, moderation categories or trust claims, but it remains a claim by a key, not an objective fact.
Use it carefully. Labels can help discovery and safety, but they can also become censorship tools or reputation attacks. The interface needs issuer, target, reason and scope visible enough that you can judge the label rather than obey it.
What changes when you actually use it
For you, NIP-32: Labeling is felt when someone makes a claim about content, people, trust, status or community behavior. Reports, labels, badges, assertions and polls can help you navigate an open network, but they can also become quiet authority. Read NIP-01, NIP-09 so you see who speaks, what is targeted and how much weight the claim deserves.
What changes for builders and operators
For builders and moderators, NIP-32: Labeling means preventing claims from becoming invisible law. Show issuer, target, reason, timestamp, evidence and conflict. Let people understand why a label, report, badge or assertion appears before it changes what they can see.
What the official file makes concrete
Inspect kind 1985, kind 1, draft, kind:1985, e, p, a, t because these are the pieces most likely to surface as product behavior. Read it beside NIP-01, NIP-09 before treating it as isolated.
NIP-32: Labeling is a claim layer. Reports, labels, badges, assertions and polls only help when issuer, target and scope stay visible.
Where it breaks
The failure mode in NIP-32: Labeling is authority theater. A report, label, badge, assertion or poll can look official because it is signed and rendered cleanly. The signature proves the issuer, not the fairness or accuracy of the claim.
Where this appears outside the markdown
In the ecosystem, NIP-32: Labeling belongs to the social safety and coordination layer. It can help people filter noise, recognize contribution, report abuse, run polls or make assertions. It can also concentrate influence quietly if the issuer disappears behind the label. The hub has to preserve that tension instead of selling governance as solved.
The nearby-standard trap
The nearby-standard trap in NIP-32: Labeling is treating every signed claim as a moderation decision. A label, report, badge, assertion or poll can inform judgment without becoming policy. Read NIP-01, NIP-09 and keep issuer, target and consequence separate.
Language that keeps the feature honest
Good product copy for NIP-32: Labeling names the claimant. It says who reported, labeled, awarded, asserted, voted or counted, and it leaves room for conflict. That is how a safety feature avoids becoming invisible authority.
What this page does not promise
NIP-32: Labeling does not make a community decision neutral. Signed reports, labels, badges, assertions and polls can improve safety or discovery, but they still come from people, services or institutions with incentives. The standard helps expose the claim. It does not make the claim fair, complete or universally binding.
Read it as a field test
Start NIP-32: Labeling with the claimant. A label, report, badge, assertion or poll has meaning only when issuer, target, reason and consequence remain visible. The article needs to preserve that social context because signed data can still be biased, stale or disputed.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-32 mirror, nostr-nips.com NIP-32 mirror, Nostrbook kind 1985, Nostr Compass NIP-32. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-32 source is the anchor for exact wording, and NIP-32 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-32 mirror, nostr-nips.com NIP-32 mirror, Nostrbook kind 1985. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-32: Labeling: first the human promise, then kind 1985, kind 1, draft, kind:1985, e, p, then the implementation record, then the real-world failure case. That order keeps NIP-32 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who issued the claim, label, badge, report, assertion or poll, and what exactly is the target?
- Can you see evidence, conflicts, expiry and scope before the claim changes what you see?
- Does the design leave room for disagreement instead of hiding authority behind a clean badge?
What to verify before you rely on it
- Find
kind 1985,kind 1,draft,kind:1985,ein the official file and check where the UI exposes the same concept. - Read NIP-01, NIP-09 as context before treating NIP-32 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-32: Labeling in that order: Official NIP-32 source for the current wording; NIP-32 commit history for the change record; nips.nostr.com NIP-32 mirror, nostr-nips.com NIP-32 mirror, Nostrbook kind 1985 for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
