Oddbean

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.

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

The hash matching makes sense, but I don't think that's such an insurmountable problem. A NIP that introduces a new kind could define the unique JSON structure associated with that kind. Then developers would write code to identify the kind, parse the JSON into the appropriate format for hashing, then hash the structure to check the ID. Practically, though, is anyone checking the hash? I thought it was mainly used just to generate unique IDs.

we are more than a year in and i still am seeing incorrectly generated event hashes in recent events, and you are talking about adding a whole string of new structures when there is still inadequate coverage of just one if it was anything less than integrity protection and authentication, then you would just generate a random number, and you'd have endless problems with bad implementations creating shitty random numbers that collide and then where are we? there's nothing stopping you putting anything inside the content field or in any of the tags, and these allow you to have one single authenticity scheme it really is unnecessary to add any more complexity, and if it was added, i doubt that it would be well supported by clients, whereas both relays and clients can easily verify events as they are and even could broadcast them without actually having teh ability to process them but changing that data structure makes that impossible and adds exponential complexity to the protocol and that means poor compliance and interoperability ded

Can an npub be used to reverse the signature hash to get the original event? Or are npubs just unique user identifiers. Regarding JSON structure, I suppose we could put stringified complex data shapes into the content field and call it a day.

the npub is both part of the event and necessary to check it matches the signature which must match the canonical formated version of the event (it is an array in a strict order with no whitespace except inside strings) npub is the public key, which is derived from the nsec, which is the secret key, and it follows BIP-340, the signature scheme used in bitcoin's Taproot and Musig2 the combination of pubkey and signature is necessary in an untrusted environment otherwise instantly there would be impersonators of everyone, this is impossible with elliptic curve keys and signatures and yes, that's exactly how a lot of these things work... i had some bugs with complex strings in tags recently, as it seems that instead of putting such content in the content, zaps put complex - JSON text, inside tags themselves

It’s a one way hash. Verifying an event involves taking the entire event json (minus signature and id) as received and running it through the hashing algo with the npub. If the output hash is the same as event id, then these are run through another algo to match with the signature. https://github.com/nbd-wtf/nostr-tools/blob/master/pure.ts