Replying to Avatar Vitor Pamplona

ok, now I understand it.

It's about escaping the content field to create the JSON string. Some implementations are escaping newline char into "\n" (2 chars) but not other characters like LSEP into \u2028 (6 chars) before hashing.

Everything is fine in interfaces because they automatically space and unescape things.

But the hash is sensitive to those differences.

The issue is that some implementations PARTIALLY escape some characters and not escape others.

I am not sure if there is a standard for these choices.
Avatar
Vitor Pamplona 2y ago

Turns out, we hit something as new as last week: https://github.com/google/gson/issues/2295

JSON lib devs are struggling to figure out a standard to escape or not escape \u2028 and \u2029

#[4] we need to clarify how to escape the String of content in NIP-01 before the string is converted to bytes using UTF-8 and then hashed. Which characters get escaped and which ones don't

Reply to this note

Please Login to reply.

Discussion