NIP-58: Badges
Recognition must not be trapped inside one client
Badges are small, but they carry social meaning. They can mark contribution, participation, membership, support, reputation or inside jokes. If badges live only in one app database, they disappear when the user changes clients.
NIP-58 gives badges a portable shape. An issuer defines a badge. The issuer awards it. The recipient decides whether to display it. That last step matters: a badge is not something another account gets to pin onto your identity forever.
The standard therefore balances recognition and user control. Awards are immutable and non-transferable, but display is chosen by the recipient.
Definition, award, profile display and badge set
Badge definitions are addressable kind 30009 events with a unique d tag, optional name, image, description and thumbnail tags. Badge awards are kind 8 events that reference a badge definition and one or more awarded pubkeys.
Profile badges are kind 10008, a NIP-51 standard list. It contains ordered pairs of badge definition and badge award references, so the user can choose what appears on their profile and in what order. Badge sets are kind 30008 and let users group accepted badges into labeled collections.
The image guidance is practical: square badge images, high-resolution originals and smaller thumbnails. A badge is both a credential-like event and a visual object.
Badges moved closer to NIP-51 list semantics
Ricardo Arturo Cabral Mejia added the visible badge event and profile badge work in February 2023. Later fixes removed proof-of-work material and cleaned terminology as addressable-event language matured.
The major recent change came in April 2026, when Alex Gleason changed Profile Badges to kind 10008 and added kind 30008 Badge Sets. That brought display and grouping closer to NIP-51 list behavior.
The page needs to therefore explain badges as both social recognition and list-backed profile curation.
A badge UI has to show issuer trust
A client rendering badges needs to show who issued the badge, what award event backs it and whether the recipient actually chose to display it. Otherwise a badge becomes a decorative sticker with unclear meaning.
Issuer reputation matters. The source recommends that clients may whitelist badge issuers to preserve value for users. A badge from a known conference, open-source project or community may mean something; a badge from an unknown pubkey may not.
The useful product flow is: inspect badge definition, inspect award, accept or reject, order on profile, optionally group into sets. Anything less makes the recipient a passive target.
Badges can become fake authority
A badge can look official even when the issuer is random. Clients need to avoid visual authority that is stronger than the trust relationship behind it.
There is also social pressure. If communities treat hidden badges as suspicious, user control weakens. NIP-58 gives users display control for a reason.
Read NIP-58 in the wild
NIP-58 gives badges a portable shape. A badge can mean contribution, membership, attendance, sponsorship, status or a joke inside one community.
The issuer is the story. A badge from a respected project and a badge from an unknown key may look visually similar. Show issuer, definition, award and recipient before giving it social weight.
What changes when you actually use it
For you, NIP-58: Badges 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-51 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-58: Badges 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
The official file is organized around Badge Definition event, Badge Award event, Profile Badges Event, Motivation, Recommendations, Example of a Badge Definition event, Example of Badge Award event, Example of a Profile Badges event. Inspect draft, d, a, p, e, Badge Award, name, image because these are the pieces most likely to surface as product behavior. Read it beside NIP-51 before treating it as isolated.
NIP-58: Badges 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-58: Badges 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-58: Badges 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-58: Badges is treating every signed claim as a moderation decision. A label, report, badge, assertion or poll can inform judgment without becoming policy. Read NIP-51 and keep issuer, target and consequence separate.
Language that keeps the feature honest
Good product copy for NIP-58: Badges 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-58: Badges 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-58: Badges 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: NIP-51 Lists, PR #2276, NIP-58 readable mirror, Nostrbook kinds. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-58 source is the anchor for exact wording, and NIP-58 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-51 Lists, PR #2276, NIP-58 readable mirror. 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-58: Badges: first the human promise, then draft, d, a, p, e, Badge Award, then the implementation record, then the real-world failure case. That order keeps NIP-58 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
draft,d,a,p,ein the official file and check where the UI exposes the same concept. - Read NIP-51 as context before treating NIP-58 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-58: Badges in that order: Official NIP-58 source for the current wording; NIP-58 commit history for the change record; NIP-51 Lists, PR #2276, NIP-58 readable mirror 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.
