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.
shafemtol /
npub1mh…anahj
2023-03-12 20:04:10
in reply to nevent1q…379n
Author Public Key
npub1mh94j7j7nwvzl7kwcg70fhxe67kdy50fccakmueq9jjf77zmc25svanahjPublished at
2023-03-12 20:04:10Event JSON
{
"id": "a69b8e93035593a6f6f45e08461ef6b813fd10e78415fb60c34455230eee53c9",
"pubkey": "ddcb597a5e9b982ffacec23cf4dcd9d7acd251e9c63b6df3202ca49f785bc2a9",
"created_at": 1678647850,
"kind": 1,
"tags": [
[
"e",
"c162f6e2ed954f110f633898849d5d9ff2abd78d0b0a5a3470e825996f279807",
"",
"root"
],
[
"p",
"ccaa58e37c99c85bc5e754028a718bd46485e5d3cb3345691ecab83c755d48cc"
]
],
"content": "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.\n\nUnfortunately 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.",
"sig": "ac7e1f0f84eb3e67c47383d004a393b90a9f748a5d6b6f38185d566cd021b4f4ec9ecf7dbff15f85018a2f3a8d8258fbd0f5503416cdee2fc375699dda04b821"
}