IPLD: precisions about canonical format

[mildred]

Child of PR #37

Add precisions about the canonical format.

There was another solutions discussed: put a @codec key within the IPLD object when converting for instance a protocol buffer to JSON representation. There are problematic consequences:

• When receiving an object over the wire with the @codec key set to a format we know, we must decode and re-encode to this format to be sure that the hash is correct. Can be done.
• Makes it impossible to store JSON objects that have already a @codec key: we could document it as a limitation of the IPLD model
• We can't do anything with objects we receive that have a @codec key set to something we don't know.

It would be possible to escape the @codec key but:

• when getting the JSON representation of the IPLD object, the application must know that the key is escaped. We can no longer claim that applications authors can put arbitrary JSON on the system. They must know of this escaping scheme
• if the ipfs tools allows us to export a version of the JSON data with the @codec key containing the codec removed, and the \@codec escaped key in its unescaped form, it will be impossible to put the file back in the system because we loose the codec information.

It's best for application authors to deal with the multicodec header, or only deal with CBOR formatted objects and not with legacy protocol buffer objects.

[jbenet]

👍

[jbenet]

this LGTM. merged