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.
@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.
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.
```
{ "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.
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.
@icedquinn You have yet to suggest a way it can be accomplished otherwise... ill wait
This or solutions like it, are routinely used in every major cryptocurrency by the way.
that's like saying whats a better way to clean your head wound when the answer is not to shoot yourself in the head first.
@icedquinn Saying its the wrong way to do it, and then not actually providing a solution that has the same functional benefit is not solving the problem.
This is how virtually every bit encoded protocol has ever worked since the begining of time almost.. atleast ones that have any sort of checksumming... its a pretty solid approach. Even your TCP/IP connections are doing something like this (sans the JSON, but canonicalizing the data)
