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?
Login to reply
Replies (1)
@Melvin Carvalho 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.