It makes no sense that tags can be strings or numbers, but kinds are restricted to numbers

[melvincarvalho]

Background

• Nostr events already allow tags to be either strings or numbers, lovely bit of flexibility that lets people innovate without filing github issues.

• Kinds, on the other hand, are hard-wired to integers. If you want a new one, you pull a random number (hope it doesn’t collide) or wait for the registry gnomes to bless a low integer.

Why this asymmetry is weird

1. Developers have to keep two mental models.
   One field is permissive (tags), the other is a numeric straight-jacket (kinds). That’s cognitive load for no real win.

2. Strings already proved their worth.
   We’ve watched ActivityPub, ATProto, Matrix, etc. scale just fine with straings as identifiers. Interop is easier because the intent is encoded in the string.

3. Integers don’t buy much performance in JSON.
   A couple of bytes here and there aren’t going to sink relay throughput. Meanwhile, constant look-ups to translate 31923 → CalendarEventTime definitely burn cycles (both CPU and human).

4. Permissionless innovation matters.
   Want to prototype a new feature this weekend? With numbers you’re either (a) camping on someone else’s provisional value or (b) rolling the collision dice. Strings fix that.

Proposed tweak

Let kind accept a string or an integer:

type Kind = number | string; // e.g., 1  OR  Note"

• Low, well-known integers keep working forever — no migration panic.
• New work can mint strings today, ship tomorrow.
• Relays treat the field as an opaque token; clients decide what they care about.

Impact

• Backward-compatible. Old clients ignore unknown string kinds; new clients recognise both.
• Zero additional registry overhead. Anybody can innovate; the global NIP table keeps curating the canonical ints.
• Easier debugging & AI tooling. Logs (and LLMs!) understand readable strings without a cheat sheet.

[vitorpamplona]

After working with W3C VCs for 5 years, I can clearly say that kinds as strings quickly become a clusterfuck of vocabularies that don't mean anything, and because they don't mean anything, devs CAN'T interoperate with one another and everyone just creates their kind variations. Having kinds as numbers that were clearly defined, both syntactically and semantically, somewhere was a breath of fresh air. Kinds as strings are great for companies that want to fake interoperability and create vendor lock-in: They want to say they are using "interoperable" W3C stuff, but can't parse or create anything anyone else does.

Kinds as numbers have advantages:

1. There is no first-come, first-served name market. If I come in and specify what a "video" kind is, nobody else can re-use that specific word. No other "video" kind can be done. Because our data lives forever, this means the crappy first implementations can poorly define the terms, and common words will quickly run out, get deprecated, and be removed from the vocabulary. This also happens with numbers, but numbers don't have meaning. Two years ago, I made NIP-94 1063 kinds for videos. If we had called them "video", we couldn't have switched over to the better-defined NIP-71 "video" kinds. Today, NIP-94 is not used for videos anymore, just for general files. That happens all the time in Nostr, since there is no version in kinds or NIPs. The version is a separate NIP, with new kinds, that redefine all the previously used terms and waits clients to migrate if they new one is truly better.

2. Numbers cannot be misunderstood or misleading. Devs will create a "video" kind and store audio in it. Since you are proposing that there will be no central authority reviewing names/vocabularies on Nostr, any dev can just create "payroll" and ship porn content in it. So much so, that the W3C had to create a centralized vocabulary process to control the use of common terms. Numbers don't care what you put in them.

3. Numbers are better references. Remembering the difference between kind 1 and kind 1111 is easier than the difference between a "note" and a "comment". Numbers are just more precise. If I say, I am doing kind 1111, everybody knows exactly what I am talking about. If I say I am doing kind "note", I still need to reference the NIP to make sure people go to the right place.

On top of that, I have not seen any dev struggling with our number system in a way that string kinds would solve it.