Why bother with JSON?

[icefoxen]

You say "The IPLD Data Model defines a simple JSON-based structure for all merkle-dags, and identifies a set of formats to encode the structure into."

But the canonical representation is CBOR, it appears. And you go through some work to try to get around JSON's gotchas. So why not define it in terms of CBOR's data types and structure rather than JSON's? That already handles some of your constraints since, for instance, CBOR is specified to always use UTF-8 strings, CBOR has real integer types, and so on.

Then you have the specification "IPLD MUST be able to import and export to JSON trivially" which can remain, you just need a single lossless CBOR-to-JSON mapping, which already exists.

[dignifiedquire]

Thanks for bringing this up. @Stebalien @nicola and I had a discussion about this very recently, which @Stebalien is writing up and should be a good basis for further discussion around this.

[Stebalien]

This is basically what we settled on in our last meeting, I'll mention you when I update the spec. We still have some outstanding questions on what numeric types we want to support and how so we'd appreciate any input.

you just need a single lossless CBOR-to-JSON mapping

Unfortunately, that existing mapping isn't lossless (when going from cbor -> json -> cbor, bytes turns into a string). However, we have a solution that works in most cases (using the same {"/": ...} mechanism as we currently use for links).

[rvagg]

Closing due to staleness as per team agreement to clean up the issue tracker a bit (ipld/team-mgmt#28). This doesn't mean this issue is off the table entirely, it's just not on the current active stack but may be revisited in the near future. If you feel there is something pertinent here, please speak up, reopen, or open a new issue. [/boilerplate]