I noticed this when playing with go-ipld. The python cbor lib we're using has a sort_keys arg, which we're using, but it produces a different ordering from the go cbor module used by go-ipld. The go version compares the length of the keys, and orders shorter keys before longer ones, but the python lib just compares bytes lexicographically regardless of length.
So the go module will sort the keys @foobar and abc as {"abc": "xyz", "@foobar": "barfoo"}, but in python it would be {"@foobar": "barfoo", "abc": "xyz"}
The go version is correct according to the rules in the the canonical CBOR section of the cbor spec. The java cbor lib we're using in the transactor checks the length also, so python is the odd one out here.
This could lead to inconsistent hashes for objects depending on what client encoded them. Not a huge deal now, since writes only happen from python, but something to be aware of.
I noticed this when playing with go-ipld. The python cbor lib we're using has a
sort_keysarg, which we're using, but it produces a different ordering from the go cbor module used by go-ipld. The go version compares the length of the keys, and orders shorter keys before longer ones, but the python lib just compares bytes lexicographically regardless of length.So the go module will sort the keys
@foobarandabcas{"abc": "xyz", "@foobar": "barfoo"}, but in python it would be{"@foobar": "barfoo", "abc": "xyz"}The go version is correct according to the rules in the the canonical CBOR section of the cbor spec. The java cbor lib we're using in the transactor checks the length also, so python is the odd one out here.
This could lead to inconsistent hashes for objects depending on what client encoded them. Not a huge deal now, since writes only happen from python, but something to be aware of.