petri on Nostr: It seems nostr hosts evil numbers! ...

It seems nostr hosts evil numbers!

quoting
note1vny…pxnd

Someone said some days ago in some NIP proposal discussion that we will run out of kind numbers because currently we’re limited to 40000. Some weeks before someone else had complained that I had written somewhere that the kind number should be a uint16, which can only go up to 65536.

In the meantime, some people make NIP proposals that involve very different events, but that use just one kind number and differentiate events by adding d tags or by other tricks. That is justified in the name of flexibility: the idea is that by having a string in which people can write anything the protocol is automatically more flexible, extensible, powerful, magical.

But this is not true. Using strings to differentiate between what could have been differentiated by a number doesn’t make anything more flexible, it just adds confusion and inefficiency. Take NIP-58 for example. It’s the NIP that defines badge creation, award and acceptance.

It makes sense for the badge creation to be parameterized replaceable (kind 30009) and differentiated by the d tag, as each pubkey can create multiple badges, and it makes sense for the badge award to be a normal, non-replaceable event (kind 8), as badges can be awarded to many people and the awards never change. But it doesn’t make sense that for each badge receiver to craft a list of badges they have accepted and want to display they have to use a parameterized replaceable event (kind 30008) with a d tag set to "profile_badges". Why this magical string?

I believe the idea was that people would be able to craft different badge lists. For example, they would use the "profile_badges" value for badges they want to display in their main profile, and some other value, for example, "hidden_badges" for badges they have accepted but don’t want to display in their main profile, and "rejected_badges" for badges that they want to explicitly reject – or something like that.

The idea makes sense, but does it really? We could have done the same with a kind 10007 meaning profile badges, kind 10008 meaning hidden badges and kind 10009 meaning rejected badges. That would save disk space and bandwidth, it would make it easier for relays to index these events and, most importantly, it would make implementation simpler. In the world of d tags, every programmer that tries to implement creating these badge lists have to go to the NIP and hardcode the kind 30008, then look for the magical string that must be set at the d tag and write it, exactly like in the NIP, as a string, and add that as a tag to the event, the same is valid for when a client wants to support reading the tag lists. While in the multi-kind world you only need to hardcode one magical number. It’s undeniable that {"kinds": [10007]} is a simpler filter than {"kinds": [30009], "#d": ["profile_badges"]}. You may say the differences are negligible, but I’m just trying to illustrate a principle.

I have the impression that in the minds of many programmers to be able to write a string gives them the impression that everything is more flexible and magical: “oh, I can write anything, while if the stuff is in kinds I would have to first get authorization from the NIP overlords”. Maybe the NIP process can be improved, but ultimately this makes little difference. You can definitely write anything in the d tag, but you can also write anything in the kind field too, the actual requirement that exists, and that exists for both, is that others start using the exact same kind number or d string that you’re using, and vice-versa, and there is no shortcut for that, you necessarily have to come to an agreement with others – which is what the NIP process tries to facilitate.