It is interesting how ipfs did not face this choice, as they settled on canonical cbor at the very beginning of the design. This locks them into a single encoding, but being locked into cbor isn't that bad, the "c" in "cbor" is no joke. More interestingly though, it prevents any future extensions of their logical data model. Which again is probably fine, especially since they have arbitrary-value-keys for maps, not just strings, but who knows - at some point they might regret it. It certainly limits the possibility of "subclassing" the protocol for more specialized settings.