> convert your object to JSON. Important: Your json should be bit-by-bit equivalent of JSON output of Golang's json.Marshal. If you are building a third party client, be very careful in testing that, otherwise your proofs of work will be invalid.

this is not how you fuckin THIS IS NOT HOW YOU DO SPECS

@icedquinn I agree thats a shitty spec... IT does expose a very real problem with JSON though, that two equivelant pieces of JSON can hash to very different values.

It is the reason I have often in my projects (where hashed values representing unique JSON is needed) used canonical JSON, which is a standard that fixes that issue. Sadly it isnt well adopted so it generally needs to be used as an internal standard.

@freemo the most correct and simple way is to use an enclosure that signs the byte array.

@icedquinn How does that give you a hash that is directly comparable? You would still wind up with different byte arrays and thus different signatures that are not directly comparable.

@freemo well this is literally how sanely made crypto code works, like signify and pgp et all.

the payload is treated as a black box of bytes which is hashed and signed.

verification takes the same black box, hashes and checks the signature.

there is no need to parse the payload whatsoever.

@icedquinn Yes but your missing the point. you have no way of verifying the two blackboxes are equivelant with that process, it does nothing to address that problem. The same JSON, simply reordered randomly will produce completely different hashes and signatures with no way of knowing they are the same thing.

Thus it isnt solving the underlying problem that would be solved by requiring a specific bit representation, that is, the ability to check for equality.

@freemo
```
{ "payload": "[some escaped json string or base64 encoded or whathaveyou]",
"hash": "blake2b",
"sig": "spergy bits" }
```

you load payload as a string, hash it, check it, if its valid *then* you strip the envelope and decode/parse the payload.

canonization is way more complicated than this.

@icedquinn Yes except as I stated that does not solve the problem that canonical JSON solves.

If give the hash of some previously hashed payload, and the hash of some new payload, if the payloads arent canonical then you cant perform an equality check at all to verify if the payloads are equivelant. With canonical JSON you can.

@freemo this is not a thing that crypto code does so i don't see your point.

what valid reason does the payload have to change from the time it goes quinn -> middleman -> freemo.

@icedquinn Depends what you mean by "crypto code".. and what use the payload has in the overall system. But yea its something that needs be done all the time. I have had to implement canonical json in cryptocurrency code before, for example.