NIP-58
Portable status needs visible provenance.
NIP-58 is one of the governance-flavored NIPs because it turns status into signed data. A badge can describe a role, achievement, membership or recognition. An award can attach that badge to a public key. The result is portable status: a client can show it without owning the identity itself.
That portability is powerful and easy to abuse. A badge is a claim, not a court ruling. If the issuer matters, the badge matters. If the issuer is unknown, compromised or unserious, the badge should be treated carefully. The UX should make that distinction obvious.
Definition and award are separate claims
The definition says what the badge is. The award says this public key received it. Keeping those events separate lets communities publish recognizable badges and issue them over time. It also lets software inspect both sides instead of treating a badge image as proof.
For a membership badge, that means the definition can carry the name, image and meaning while awards identify members. For an event badge, it can distinguish attendance from speaker, sponsor or organizer. For reputation, it can separate achievement from mere endorsement.
Display is a governance decision
A client that displays every badge equally is making a poor governance decision. Some badges deserve prominent placement; others should be tucked behind issuer details. A serious interface asks: who issued it, what does it mean, when was it awarded, and does the current community recognize the issuer?
This is the point where design becomes trust infrastructure. Small affordances matter: issuer key, definition link, award date, source event, copyable reference, report option and a way to hide low-value badges.
Revocation and dispute remain social
NIP-58 does not magically solve revocation, appeals or fraud. Communities still need conventions. An issuer can publish later events, change a website, update a list or issue new claims. Clients can decide how to show conflicting status. People can contest whether a badge was earned.
That is not a failure. It is the honest boundary between a signed record and social meaning. Governance pages should make that boundary plain before badges become too important.
A badge is not a JPEG with status; it is a signed governance object
The important move in NIP-58 is not that profiles can display pretty badges. The important move is that recognition can become portable, inspectable Nostr data. A badge definition tells you what the badge claims to mean. A badge award attaches that definition to a public key. A client can then show status without hosting the account, owning the profile or keeping a private database of achievements. That is a big shift for communities, associations, events, creator programs and contributor networks.
The same shift creates risk. If every image that looks like a badge is treated as status, the feature becomes noise. If clients display unknown badges as if they came from trusted institutions, users get misled. If an issuer key is compromised, old awards may need public explanation. If a badge grants access, there must be a rule for loss of eligibility. The standard gives Nostr a data shape. It does not solve institutional trust by itself.
Issuer identity is the center of the design
The first question is always who issued the badge. A badge from an event organizer, a developer collective, a relay operator, a project maintainer, a company, an association or a joke account should not feel the same. The issuer gives the claim weight. In practice, clients should make the issuer visible, link to the definition event, show award date where available and avoid turning badges into a single global reputation score.
For Crays-style membership, awards and community recognition, that distinction is critical. A membership badge can affect access. An award badge can affect prestige. A contributor badge can affect hiring or collaboration. A playful badge can simply mark culture. The page should make those categories legible before badges start carrying real privileges.
Revocation, expiry and dispute are product responsibilities
NIP-58 can describe and award badges, but the hard governance questions live in product behavior. Can a badge expire? Can an issuer publish a correction? Can a client warn when an issuer is no longer trusted? Can a community distinguish a historical badge from an active credential? Can a person hide spam badges from their profile without losing meaningful ones? Those are not minor UX details. They decide whether portable reputation becomes useful or chaotic.
A serious badge page should therefore teach you to inspect before you celebrate: definition, issuer, award event, community recognition, current relevance and any dispute trail. That is the difference between status as decoration and status as a usable public record.