Profile badges event should use kind 10008 instead of 30008

[alexgleason]

This is very cursed https://github.com/nostr-protocol/nips/blob/master/58.md#example-of-a-profile-badges-event

A holdover from when NIP-51 addressable lists got deprecated in favor of replaceable events? https://github.com/nostr-protocol/nips/blob/master/51.md#deprecated-standard-lists

It should definitely be a kind 10008, not 30008. 30008 should be "badge sets".

[fiatjaf]

I agree.

https://badges.page/ is offline. Who else has implemented this? @vitorpamplona @sondreb

Let's change.

[sondreb]

So 10008 for primary badges, like primary bookmarks, and 30008 for sets of badges, like bookmark lists/folders?

I'm ready to change it!

[sondreb]

So 10008 for primary badges, like primary bookmarks, and 30008 for sets of badges, like bookmark lists/folders?

I'm ready to change it!

[alexgleason]

I'm currently working on transitioning it in Ditto. Here's the strategy:

The Problem

NIP-58 defines "Profile Badges" as kind 30008 (addressable/parameterized replaceable) with a fixed d tag of profile_badges. But since every user only ever has one Profile Badges event (the d tag is always profile_badges), it's functionally a replaceable event, not an addressable one. The addressable kind range (30000-39999) is meant for events where users have multiple events of the same kind distinguished by different d tags -- like bookmark sets, emoji sets, or badge sets.

This is the same pattern that happened with NIP-51 lists: kinds like mute, pin, and bookmarks were originally addressable (30000/30001) with fixed d tags, then deprecated in favor of proper replaceable kinds (10000, 10001, 10003).

Kind 10008 is currently unassigned and would be the natural home for Profile Badges, since it sits right between the other NIP-51 standard lists (10007 = search relays, 10009 = simple groups).

Backwards-Compatible Migration

The standard approach used by NIP-51's own deprecation cycle:

1. Clients writing (publishing) should switch to kind 10008 immediately

When a user updates their profile badges, publish as kind 10008 with no d tag (replaceable events don't need one, though including ["d", "profile_badges"] is harmless).

2. Clients reading should query for both kinds during the transition

const events = await nostr.query([
  { kinds: [10008], authors: [pubkey], limit: 1 },
  { kinds: [30008], authors: [pubkey], '#d': ['profile_badges'], limit: 1 },
]);

// Use whichever is newer
const profileBadges = events.sort((a, b) => b.created_at - a.created_at)[0];

This is exactly the same read-both-pick-newest strategy that clients used (and still use) for the NIP-51 list migration from 30000→10000, 30001→10001, etc.

3. Optionally tombstone the old event

When publishing the new kind 10008 event, clients can publish an empty kind 30008 with ["d", "profile_badges"] and no badge tags to clear the old entry from relays. This prevents stale data from lingering.

4. NIP-58 update

Add a deprecation note to NIP-58 (or update it outright), similar to the deprecation table in NIP-51:

kind	"d" tag	use instead
30008	profile_badges	kind 10008 profile badges

And kind 30008 gets freed up for "badge sets" -- which is what the addressable range is actually for (users maintaining multiple named collections of badges).

Why This Works

• No data loss: Old events remain valid and readable
• Gradual adoption: Clients that haven't updated yet still work fine reading 30008
• Precedent: This is exactly what NIP-51 did for 4 different list kinds
• Relay-friendly: Replaceable events (kind 10000-19999) are simpler for relays to handle since they don't need d tag indexing
• Frees 30008: The addressable kind can be repurposed for actual badge sets (named collections like "my gaming badges", "my community badges")

The pattern is well-established and low-risk. The main work is getting client developers to adopt the dual-read strategy during the transition window.

---

[derekross]

@hzrd149 @fabianfabian

[derekross]

@verbiricha @v0l

[alexgleason]

Ditto has been updated to use kind 10008 for profile badges: https://gitlab.com/soapbox-pub/ditto/-/commit/cf9d409166be61fb87a83661381fda80a0f4d116

It upgrades profile badges from kind 30008 using the strategy above.

[purrgrammer]

lgtm

[alexgleason]

Let's get #2276 merged. Has anyone else implemented it?

[purrgrammer]

implemented in Grimoire

[derekross]

I implemented it in https://badgestr.shakespeare.wtf 🤓

[purrgrammer]

@derekross can you buy badges.page and point it there? i'm poor and can't afford the domain no more