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
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z Had a post about this, i think.
Great minds think alike 😂
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
