You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I will paste this in here since I started writing it before I found an existing issue for this.
The JSON format is defined in the ECMA-404 standard.
NIP-01 describes the algorithm for serializing events as an array of JSON Values (as described by section 5 "JSON Values" of ECMA-404). This algorithm results in creating a JSON array with various event fields. Creating this array is a prerequisite to calculating the event id and then validating the event signature.
Section 9 of ECMA-404 document titled "String" doesn't define a deterministic way of serializing sequences of Unicode code points as JSON strings. For example a sequence of Unicode codepoints consisting only of the solidus character (U+002F) can be encoded as either one of the following JSON strings (as shown in the document):
"\u002F"
"\u002f"
"\/"
"/"
This leads to the lack of determinism when creating event signatures of nostr events. Which one of the following JSON arrays should be hashed and signed in order to create the event signature of an event with the aforementioned content?
Mind that this property of the JSON format makes any action of deserializing a JSON object representing an event and then reserializing it as a JSON object a destructive operation which may corrupt the event. For example if an implementation chooses to deserialize the event received as ["EVENT", {...}] from a relay and then construct the aformentioned array used for ID calculation in order to verify the event signature it is likely that for some events this operation will lead to failures. This is already how existing implementations operate (e.g. github.com/nbd-wtf/go-nostr).
I wanted to write this down to get the discussion started on what the way out of this is:
specifying a deterministic way of encoding the serialized event array as a JSON-like format?
Is this because of other implementations garbling up the events or our implementation incorrectly handling JSON?
Example of such event:
61400832313a1d69dfee07bbf2990f5338d3c77cd5beaa047289bea65d1b5532
wss://kukks.org/nostr
Also when will people finally stop trying to sign JSON 😢 ?
The text was updated successfully, but these errors were encountered: