search

nostr-protocol / nips

Nostr Implementation Possibilities
2.39k stars 582 forks source link

additional notes about escaping to ensure correct event IDs #1430

Open mleku opened 3 months ago

mleku commented 3 months ago

might be a bit long-winded but i think it makes it clearer how to avoid issues with incorrect re-encoding for implementers and ensuring that whatever clients will make and use won't get altered by a relay between decoding and encoding

it also makes a section header which will help in directing readers to this section in future

mikedilger commented 3 months ago

For taking a signature, you must (1) convert the original JSON strings into UTF-8 strings by changing all escape sequences into their UTF-8 codepoints (2) re-render these as canonical JSON strings using the escaping specified in NIP-01 (IMHO if there are codepoints below 20 not specified in NIP-01, then render them with \uXXXX), and take the signature.

The reason for this is that ANY character can be legally escaped, including all letters of the alphabet, meaning there are a large number of different representations mapping to the same UTF-8 string. And as you mention there are octal escapes, etc, which should not be used when taking the signature.

I think changing to a scheme where we retain original escape sequences would break nostr far more than doing what I just explained, which is IMHO how most nostr software currently operates.