He's right, you know. About the numbers.
Discussion
Almost: nostr is not a binary protocol, so it‘s quite easy to make 65535 an indicator of a „long-kind“ event.
Then you'd have 4294967295, right?
So long as there's no limit to the number of kinds one use case can reserve, everyone takes ranges. That'll still fill up. Everything gets exponential really fast.
Also, people will use the kinds as counters, so they'll want a number for every record.
It kind of works with Unicode (see https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/).
And compared to note text, hash and pubkey, the amount of bytes used for a kind doesn‘t really matter.
You mean, solve it by allowing all characters?
Using numerals-only would reduce the incentive to claim ranges and offer a gazillion more combinations.
No defined range between U&A!iz6 and ++63%ddR
No, just allowing bigger numbers.
Maybe an example helps:
- 0..65534 uses 16bits
- 65535..2^32-2 uses 32 bits
- 2^32-1..2^64-2 uses 64bits
and so on. Small numbers use up less space than big ones. This is complicated for binary protocols, but not for nostr.
Oh, right.
I kind of like the range-discouragement inherit in random strings, but that's probably too wonky, for most developers.
😁 now I am at a loss.
But it's a thing, isn't it?
Without randomness, people get greedy and aren't encouraged to conserve. That's how the tag-as-counter effect creeps in.
And everyone clustering at particular combinations like 9999999 or 7000.
So many numbers, but people will still overlap because they will gravitate to the same subset or claim ranges.
There‘s one misconception here: the amount of available numbers grows exponentially with space, not the other way round. So kind-bitsize grows logarithmically with each number added. That’s quite nice.
I don't understand, I'm afraid.
He's in a big conglomerate and they let everyone choose their own JIRA tags and within 6 months, there were so many JIRA tags that you type the letter "A" and you can go get an coffee while the list loads.
A bit different though, a nostr client doesn't have to load or know all kinds, just the ones that it needs for the feats it wants to use. The event payload doesn't really matter for kinds. But related yes I think there can be a risk of having multiple things using specific kinds for their use cases that when they could all be using the same.
The problem is in the reservation of entire ranges and everyone including the top number. Lots of people will include 3000 or 55000, for instance.
And what if there are 2 apps using 3000, and you only want to read from one of them?
And I didn't even think of people using kinds/tags as counters. I'm like, Wow, that's really stupid.
But a lot of developers are stupid.
That was the thing. He made me realize that kinds are tags, not IDs.
They seem like IDs because they're numbers.
I think you can use tags do differ them. In this scenario i think it's "d" tag. Ephemeral events also use specific tags for each app, but as a client you don't even have a way to prevent others apps to misbehave, like Vitor P. Issue of people sending DMs with kind 1. A client app cannot do nothing about it.
Yes, people can simply use the wrong kind.
Probably really tempting because of the numbering. 1 is an easy, nice number. Otherwise, you have to go find the appropriate number and it won't be as nice. 981 or something.
Seems sort of silly, but there's a psychology to numbers. People will always start counting at the smallest number, so implementations will cluster most at the smallest numbers.
Same with the NIPs. They're in numerical order. Everyone reads NIP-01 and you've lost nearly everyone by NIP-25.
Only way to get people to pay attention to the kind and NIP content is to remove information from the numbers.