Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Event Service] Some events can't be validated #40

Open
boreq opened this issue Nov 27, 2023 · 2 comments
Open

[Event Service] Some events can't be validated #40

boreq opened this issue Nov 27, 2023 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@boreq
Copy link
Contributor

boreq commented Nov 27, 2023

Is this because of other implementations garbling up the events or our implementation incorrectly handling JSON?

Example of such event:

  • id 61400832313a1d69dfee07bbf2990f5338d3c77cd5beaa047289bea65d1b5532
  • relay wss://kukks.org/nostr

Also when will people finally stop trying to sign JSON 😢 ?

@boreq boreq self-assigned this Nov 27, 2023
@setch-l setch-l changed the title Some events can't be validated [Event Service] Some events can't be validated Dec 11, 2023
@boreq boreq added the bug Something isn't working label Dec 11, 2023
@boreq
Copy link
Contributor Author

boreq commented Dec 19, 2023

@boreq
Copy link
Contributor Author

boreq commented Dec 19, 2023

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?

  • [0,"e731ca427c18059d66636ddfaeeeb15012bc2db3cdd27b9e4cade5057a6e82ed",123,1,[],"\u002F"]
  • [0,"e731ca427c18059d66636ddfaeeeb15012bc2db3cdd27b9e4cade5057a6e82ed",123,1,[],"\u002f"]
  • [0,"e731ca427c18059d66636ddfaeeeb15012bc2db3cdd27b9e4cade5057a6e82ed",123,1,[],"\/"]
  • [0,"e731ca427c18059d66636ddfaeeeb15012bc2db3cdd27b9e4cade5057a6e82ed",123,1,[],"/"]

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?
  • switching to a different binary-based format?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

No branches or pull requests

1 participant