Spec refining: Do not bind the canonical representation to CBOR

[nicola]

The world might come up with new standards and a CBOR hashed object might point to a CBOR2 hashed object. In other words, there is no way to differentiate across "current" and "canonical" formats. In IPFS jargon, this needs a sort of multicodec for the hashes.

// implicit: bind canonical representation to the namespace
// ipld means CBOR is canonical, ipld2 means CBOR2 is canonical
{
  name: { '/': '/ipld/hash'}
}
{
  name: { '/': '/ipld2/hash'}
}

// explicit: use multicodec
{
  name: {'/': '/cbor/ipld/hash'} // or just /cbor/ipld
}

// hidden: use link properties
// only possible if this issue goes through: https://github.com/ipld/specs/issues/2
{
  name: {'/': 'hash', canonical: 'cbor'} // or any better property name
}

Pro:

• we don't make a choice that is forever

Cons:

• links will need to contain encoding (multicodec? multicanonical?) prefixing the linked object, or have a new hidden field (see Spec refining: Properties in links #2) specifying the encoding

[dignifiedquire]

Maybe we could do something like we do in multistream, i.e. give semver to the ipld namespace: /ipld/1.0.0, /ipld/2.0.0, ..

[jbenet]

fits very well with ipfs/specs#130

[nicola]

We have agreed that IPLD will not be bound to CBOR, instead, the CID proposal will make it so that there will be a byte to encode the format to which we are bound to. 🎉

[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]