https://github.com/nostr-protocol/nips/issues/354
Picking JSON serialization rather than a well specified binary serialization was a terrible idea. Satoshi got this right; nostr did not.
Discussion
If nostr needs to be in binary, then binary it will become.
In fairness, JSON was much more well specified than Bitcoinās serialization format when Bitcoin started.
Bitcoin probably should have used protocol buffers or whatever already existed like it at the time.
More issues like this will start to come out as adoption increases, but the sooner the better to start documenting the flaws.
#[0]
Right, but if a binary setialization was used, details encoding of Unicode would still have to be sorted out.
On the bright side, this does not about validation or consensus, but display of some special characters. (I mean I think there is no use case where clients REconstruct y Json, and any diffrence would lead to different hash.)
No, this is about validation: a you noticed, this includes how signature hashes are calculated.
JCS, although more complicated than binary, is a well-specified JSON serialization form. Luckily, for hashing, nostr only relies on a few types (list, integer, string), which are not the most complicated parts of JCS, and it seems that most client implementations happen to be compatible with JCS for these types, at least for most notes. The most complicated part here is that there are 22 characters that require specific escape sequences when encoding strings.
Unfortunately it appears that some devs really really really REALLY want to use a generic JSON library to generate things that look like JSON even when they know that this results in critical bugs.
(that is 22 in hexadecimal, or 34 in base 10, of course)