Oddbean new post about | logout
 My beef with nostr is why notes have a dedicated "kind" json field, when it could easily just be a tag. They could also have human readable names instead of just numbers that no one knows what they mean without looking it up.

Let's start "nostr 2.0" and make it right 😂 /s 
 I like the kind ID. Since it is just json instead of e.g. uint16 its a bit counter intuitive.
But you need to look up a ID instead of just inventing your own tag (or worst of all: namespaced tags) for your protocol. This has a huge impact on how new kinds are discovered. 
 Devs invent their own kind IDs even if they are not on a NIP. One day, they are bound to clash when testing different custom events.

Like there is a kind ID directory in the NIPs repo, there could very well be a named kind directory for common kinds. 
 Enums > ints 
 But also, naming things is hard  
 @Vitor Pamplona Had a post about this, i think.  
 Great minds think alike 😂 
 No iceberg

Who’s got most to lose?

💌 
 Are you license to operate?
Can you po to verify the unit?

No iceberg
💌 
 Do you know?

No iceberg 
 It was saying something else. The idea was that DIDs do not use numbers, they use words, and it causes all kinds of serious problems. The author said that having kinds as numbers was a great strength of nostr. 

I went looking for the post and i could not find it. I'm not sure whether it was vitor or someone else. 
 THAT is your beef with nostr? Among all the problems, you notice that kind could just be another tag and for that you want to start over?  That is trivial.

But on that topic, I think instead of a kind field there should be bitflags.  One or two bits meaning ephemeral/replaceable, one bit meaning restricted to tagged people, one bit meaning only uploadable by the author, etc.  And tag "keys" should be binary, a number not a letter. Events should be binary and don't need to be "read" by humans outside of using a note reader library (which can express them in nice english words) or in code (where they are expressed again as nice english words).  E se preferir português pode usar nomes portugueses na sua biblioteca em vez de inglês. 
 I was only half joking in case that wasn't clear. Bikeshedding over trivialities is what we do.

I agree with your latter point. The only thing better than enums is bitfield enums, so much more flexibility. The only issue is that would limit us to 64 different composable kinds, but we could just make new fields for other things. 
 just seeing this now. I agree, there are way too many kinds