I tried to spark discussion around a “simpler” and more “decentralized” solution a while back .. to solve the same problem of “kind bloat” by clients and relays.
nostr:note1e4xhar74ew32435v5whqgu7np5hx9rlx7yumtya6u9qynasjv4sqc49wdg
I'm proposing this. Just remove the event kind list from the NIP repo and put it in a wiki page and basta.
Discussion
One thing I don't completely understand is why every Nostr event kind uses the exact same data structure.
JSON is very flexible, we could simply define additional fields to our hearts' content. Instead, `content` always has to be a string, and the most flexibility we get is to define tags as arrays within arrays.
Array-based tags are stupid, IMO. It's needlessly difficult to parse. All you need is a few common top-level fields (pubkey, sig, kind), and the `kind` field tells the client what other *top-level fields to expect on this JSON blob.
For a JSON-lover's protocol, we're really underutilizing JSON.
I don't think anyone knows why this is.
JSON is trash, very unfriendly for human editing
the more complex you make the structure the less likely that it will be adequately handled by the majority of clients
you have to be able to form the data into the format that the hash that the signature is on, no matter how rearranged the fields are in the object, adding more fields leads to more chances of code failing to put it in the right order and not getting the matching hash
also did i mention that JSON sucks?
YAML would have been better
But yaml is for humans editing the content of a file manually, and we usually have clients do that.
humans can't practically do the ID or signature but all the rest we could... and an actual human friendly format is easy to make consistent, gofmt does that all day long for me, there is very little elbow room for how it's formatted, only really adding line breaks the rest is fixed, and the line breaks can easily be removed, and line breaks are perfect field separators, because they have no other purpose, unlike brackets and commas and semicolons and colons
having gone through the process of writing parser code for text formats the simple thing of comma separation and not the use of a terminal comma has huge implications not just for the fact you can't cut a line and move it without taking care of the comma positions, in the parsing logic it's an extra comparison and branch to check if it's the last field and omit the comma there
if i were to say what format the structure should take, it would be derived from Go's syntax, which is designed for consistency and easy human editing
Well, I guess there's no reason why a relay couldn't accept yml events. 🤷♀️
yes, also the actual ID is not necessary to send out, you just parse it into the fields, arrange in the canonical array format, and then you have the hash, it would be possible to actually remove it from the structure, as it's redundant
it's only sorta purpose might be in quickly getting the ID to reference it in another note
i'm not saying that there is any real need to change any of it, just that it's possible to make it more sleek
Ah, I didn't think about the hash not matching.