The point is that there is no need for a single implementation in order for current apps to interoperate. They are doing great even not sharing any codebase.

Reply to this note

Please Login to reply.

Discussion

We can agree to differ here. I'll put it to you that the protocol (NIP-01) is under specified, because it doesnt define things like stringify, so unless everyone goes with nostr-tools you'll have different implementations doing different things, especially in different languages. Little bits of technical debt add up ...

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?

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.

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.

I concur that it is not fully documented, but it's close enough and simple trial and error finds the correct order