Spec refining: requiring namespace in IPLD pointers

[nicola]

In #3 I specified that IPLD pointers are the following:

• hash/object pointer HASH
• plus and an attribute pointer (e.g. /friends/0/name)

can it be implicit, or does it have to be explicit by requirement?

The following are pro and cons of having explicit namespaces before hashes and never implicit names

Pro:

• no assumption about canonical representation: we can map a particular namespace to a particular canonical representation (see Spec refining: Do not bind the canonical representation to CBOR #6)
• upgradable: we can have ways to version (?) the protocol
• link types: we can have different type of links (IPFS (maybe?), IPLD)

Cons:

• Extra characters
• Only real reason is the canonical assumption, but the canonical representation may never change..

---

cc @dignifiedquire, @diasdavid, @jbenet, @Stebalien

[jbenet]

• Experimental Proposal: CIDv1 -- IPLD, Multicodec-packed, and more ipfs/specs#130 addresses this concern. it allows resolving to objects of "other formats" using multicodec-packed in the CIDv1. fmt-X can link to fmt-Y by including the multicodec-packed in the link. enables cbor->git, cbor->ipfspb, cbor2->cbor1, cbor1->cbor2
• Experimental Proposal: CIDv1 -- IPLD, Multicodec-packed, and more ipfs/specs#130 proposes that objects of fmt-X should be able to link to other objects of fmt-X without needing a multicodec or other prefix. this enables git->git, btc->btc, ipfspb->ipfspb, eth->eth, cbor->cbor links, which are compressed as much as they can be, and completely unambiguous.

[nicola]

Perfect, this should be documented soon (explicit and implicit multicodec) 🎉

[dignifiedquire]

From the call these two questions were arising

1. For the notion of linking between protobuf to protobuf there is an implicit CID of v0, protobuf, base58. To allow for the
   integration of other raw objects, like git objects we need this implicit thing as well. Given that then all links inside networks
   are using implicit CIDs, except for IPLD do we want to do the same thing for IPLD inside links?
2. Do we need to use /ipld/<cid> or <cid> for linking to IPLD objects inside IPLD objects?

[Stebalien]

IMO, this really is a question of encoding. Abstractly, canonical IPLD links would be defined to be /ipld/FULL_CID. However, individual codecs (ipld+cbor, ipld+protobuf, ipld+git, etc.) can specify custom link formats (as long as these links can be converted to-and-from canonical IPLD links).

[nicola]

👷 So, this clearly needs further discussion and needs to be split (as @dignifiedquire said):

• implicit/explicit full CID
• implicit/explicit /ipld

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