Badges Page
Badges Page is where Nostr recognition becomes an event you can create, award, accept, reject and display. The app is simple on purpose; the social rules around it are the hard part.
Badges are not stickers
It is tempting to describe Badges Page as a little badge maker and move on. That would miss the whole point. In Nostr, a badge is not just an image on a profile. It is a signed object issued by a public key, awarded to other public keys, and accepted or displayed by the recipient through their own signed event. That makes it closer to a portable reputation signal than a decorative sticker.
The official Badges Page homepage says the app is about supporting creators and showing endorsements for artists, developers and projects. NostrApps calls it "a manager for your Nostr badges" and lists the practical jobs: create badges, award badges and manage badges awarded to you. The page is simple because the concept is already heavy enough.
Think about what changes when recognition becomes portable. A community can give a builder a contributor badge. A game can award a league badge. A conference can badge speakers or attendees. A publishing circle can recognize reviewers. A creator can award supporters. None of that has to live only inside one platform's private database. The badge can travel as a Nostr event, and other clients can choose whether to show it.
That last sentence is important: clients can choose. A badge is not a universal truth. It is a claim by an issuer, displayed by a recipient, interpreted by a viewer and rendered by a client. Badges Page gives the object a workflow. It does not solve the social meaning for you.
The three-event dance
NIP-58 is the standard underneath Badges Page. It uses several event types, and the dance is worth understanding before you create anything. First comes the badge definition, an addressable kind 30009 event. The issuer signs it. It has a d tag that identifies the badge and can include a name, description, image and thumbnails. NIP-58 recommends a square high-resolution image, with 1024 by 1024 pixels as the badge image size.
Second comes the badge award, a kind 8 event. That event references the badge definition with an a tag and includes one or more p tags for the pubkeys being awarded. NIP-58 describes awarded badges as immutable and non-transferable. In plain language: the issuer can define a badge, then say these public keys received it. The award is not a token the recipient can send onward.
Third comes the profile badge event, currently a kind 10008 replaceable event shaped as a NIP-51 list. This is where the recipient decides which awarded badges to display and in what order. NIP-58 also defines badge sets, kind 30008, so accepted badges can be grouped. That acceptance step is easy to miss, but it matters. The issuer can award. The recipient chooses whether to wear.
This is why a badge manager matters. If you had to hand-write all of those events, only protocol people would play with badges. Badges Page gives normal users an interface for the protocol's ceremony: define, award, accept, display.
What Badges Page actually does
The app's public surface is direct. The official homepage says "Get started," shows badges, creators and awardees, and says it is powered by ngine, a Nostr application framework by Verbiricha. NostrApps lists it as a web app with a simple interface. The Bitcoin Manual's 2023 guide describes it as one of the first clients to offer a badge creation experience.
In use, the workflow is close to what NIP-58 describes. You create a badge by giving it a name, description and image URLs. You sign the definition. You award it by entering a recipient's Nostr identity, usually an npub. The recipient later reviews awarded badges and accepts or rejects the ones they want on their profile. Clients that support badges can then display the accepted set.
The app is useful because it turns a strange protocol object into a recognizable social action. "Award this person" is easier than "publish kind 8 with an a tag and multiple p tags." "Accept this badge" is easier than "publish kind 10008 with paired a and e tags." Good protocol tools do not dumb the protocol down; they give humans a handle.
Badges Page also belongs under governance because badges are about authority. Who is allowed to define a badge? Who is trusted to award it? Who should display it? Which clients should render it? Which issuers should a community whitelist? Every badge becomes a tiny governance decision.
Creators, awardees and the acceptance step
The most humane part of NIP-58 is that recipients do not have to display everything awarded to them. Someone can award you a badge you do not want. Someone can create a joke badge, a spam badge, a badge that misrepresents you, or a badge from an issuer you do not trust. The profile badge event gives you a way to accept, reject and order what appears.
This turns badges into a two-sided social object. The creator signs the definition. The issuer awards. The recipient curates. The viewer interprets. That is more mature than a one-way trophy pop-up. It also means the value of a badge depends heavily on the issuer. A "core contributor" badge from the project maintainer means something. The same image copied by a random key means far less.
NIP-58 explicitly says users may be awarded badges for recognition, gratitude, participation, appreciation of a goal, task or cause. That range is broad enough for real communities, but broad enough for noise too. Badges Page gives the tools. Communities still need rules.
The issuer key is the kingmaker
The biggest risk is not technical difficulty. It is misplaced trust. The Bitcoin Manual's guide makes the warning concrete: because anyone can create and award badges, users need to curate which badge lists they display. Fake badges can be used for scams. A badge creator can rebrand a badge later. If the issuer's private key is stolen, the badge's meaning can be hijacked. If the issuer sells the key, the social meaning can change hands.
That is not a reason to dismiss badges. It is the same problem every reputation system has, only more visible. Credentials are not valuable because they exist. They are valuable because the issuer is trusted, the rules are understood and the viewer knows what the badge claims.
This is where Badges Page should be used with a signer and a cool head. Creating a badge, awarding a badge and accepting a badge all involve signing events. If the app asks for a raw private key, prefer a safer signer path where possible and understand exactly what is being signed. A badge manager is not as financially dangerous as a wallet, but it still acts as your identity when it publishes.
Where it already shows up
Badges are not only an abstract standards toy. THNDR's Nostr badge guide points users to Badges Page as a place to view and accept gaming badges tied to their Nostr identity. Their example is useful because it shows the shape of a real use case: an external community or product awards badges for participation, status or achievement, then the user's Nostr profile becomes the place where that record can be shown.
The Bitcoin Manual's guide is another early clue. It walks through creating a badge, awarding it and receiving it, including image sizes and the need to sign updates. It also notes that clients such as Amethyst, noStrudel and Nostter have shown badge support in profiles at different times. That matters because a badge manager is only part of the story. A badge becomes socially useful when other clients render it.
For Crays, the interesting angle is broader than profile decoration. Badges can be used for contributor recognition, venue participation, verified roles, event attendance, creator support, grants, awards and community status. But each use case needs a rulebook. Who issues? What earns it? Can it expire? Can it be revoked or superseded? What happens if the issuer key is compromised? The app can publish the event. Governance decides whether the event should matter.
How to test a badge without making a mess
Use a test identity first. Create a harmless badge with a clear name, a square image and a description that says exactly what it means. Award it to a second test identity. Then log in as the recipient and accept it. Open the result in another badge-capable client and see whether the badge appears as expected.
Then inspect the event trail. Find the kind 30009 definition, the kind 8 award and the kind 10008 profile badge event. Check the tags. See which relays received the events. If another client cannot display the badge, ask whether the issue is image hosting, relay availability, client support or the acceptance event.
Finally, test your social policy before issuing real badges. A good badge name should not be ambiguous. A good badge description should explain why it was awarded. A good issuer should keep the private key safe. A good community should tell people whether badges are symbolic, functional or tied to access. Badges Page gives you the publishing surface; you bring the responsibility.
Badges Page sources worth opening
This article keeps claims close to the live app, NostrApps, NIP-58 and practical badge guides.
