Peter Todd's avatar
Peter Todd pete@petertodd.org 9 months ago
“therefore it has weird and unnecessary quirks like signing a JSON string which must strictly follow the rules of ECMA-262 6th Edition” It's hilarious how many things the original nostr readme was clearly wrong about. Round-tripping is such an obvious problem to anyone who has ever worked on crypto codebases, and it has caused lots of problems for nostr implementations.
Max's avatar Max
Now compare this to the original nostr description of @fiatjaf from November 9, 2020: https://github.com/nostr-protocol/nostr/commit/bdeb03aeaf2d44db954e0eb1356a3f585ee7c50d View quoted note →
View quoted note →
↑ Parent

Replies (4)

Peter Todd's avatar
Peter Todd pete@petertodd.org 9 months ago
Why should you have to rigorously store exactly the same string every single time? The fact that people keep running into this issue shows that not taking round tripping into account is nuts. Bitcoin does _not_ work this way. Serialization is tightly defined and you can easily and reliably re-serialize data structures reliably.
1 replies ↓
ABH3PO's avatar
ABH3PO abhay@formstr.app 9 months ago
Yess, I was just trying to get around the issues in the current scheme, but nip01 actually specifies the order of the keys in the event structure right? I think it is at least a little detailed on how to avoid ambiguity in the serialization infact the event id is a sha256 of a JSON array and not an object, it also details on how to escape special characters, whuch should resolve most of the ambiguities right?
1 replies ↓
↑