Replying to Avatar Vitor Pamplona

I can tell you that each language's stringify is matching quite well to what nip01 describes, which just follows the json spec. JavaScript, Kotin, go, swift, rust, C, and even php are matching.

What else would you like defined that isn't defined anywhere else?
8e
Valentino Giudice 6mo ago

nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24 is actually right on this.

There are multiple possible strings for the same JSON because each string in the JSON can be codified in multiple ways and that's because each character can be written in different ways in a string in JavaScript.

The issue is that stringification is used to compute hashes, so it's crucial that everyone gets the same result because everyone needs to get the same hash.

In practice, the different main native implementations of JSON do lead to the same result (every time? most of the time?), so this hasn't been a practical problem, but NIP-01 is underspecified.

A proper specification can be written to be back-compatible by mandating that which currently just happens to be true in different implementations, but required to none.

On everything else we can experiment, having different clients behaving differently and live with the mess that Nostr is and is supposed to be, but hashes have to be consistent.

Reply to this note

Please Login to reply.

Discussion

8e
Valentino Giudice 6mo ago

Note that even if Nostr had an official reference implementation this wouldn't actually solve the issue because not every detail of an implementation, not even the official reference one, is part of a protocol.

But at this stage we might still be fine with what we have, given that, although it's been around for a while now, Nostr is still somewhat experimental.