Open pzingg opened 1 year ago
The string encoding should be as defined in the RFC if you use the escape: :unicode_safe
option.
The 3rd point would likely be best handled by a pre-pass that encodes map into a Jason.OrderedObject
value - this will guarantee correct ordering of keys.
There's some complexity, though, with custom protocol implementations and @derive
-based values that can generally output arbitrary bytes (they shouldn't, but could in theory).
For pretty-printing we handle this by having pretty-printing as a completely separate pass - after encoding.
Either way, I'm not sure it would be possible to support this in a robust way given the way the encoding protocol works.
@pzingg Looks like you already did a PoC. https://github.com/pzingg/jcs
Why not try getting this in? It's quite a hurdle without JCS to do signature verification.
In order to implement Data Integrity Proofs for linked data, Elixir should have a fast JSON encoder that compiles with RFC 8785.
I think there are only few tricky points:
1 [ ]. Encoded string keys and values must be escaped by the RFC's section 3.2.2.2.. This may already be happening in Jason. 2 [x]. Floats must be encoded per the Ryu algorithm according to the RFC's section 3.2.2.3.. I think Jason now handles this for OTP > 25 with the
[:short]
option for in:erlang.float_to_binary/2
. 3 [ ]. Encoded objects (recursively and when found in arrays) must have their properties sorted in UTF-16 integer order per the RFC's section 3.2.3