Spec refining: IPLD pointers must point to IPLD objects only

[nicola]

Can pointers be in the IPFS space? or these should not be linked with {/: '/ipfs/hash'} ?

The following is an argument on why we should only have IPLD pointers to IPLD objects (so never to IPFS). The idea is that we can still link to IPFS objects - but not using the IPLD link object ({'/': hash})

Pro:

• very clean: all IPLD link to IPLD object only

• links to other objects that are not traversable with the IPLD pointer/data model should not be supported (this creates very awkward pathing) instead they should be used in userland (so no IPLD pointers)

  // /ipld/hash1
  {
  pictures: { '/': '/ipfs/folder' }
  }
  
  // /ipld/hash1/pictures (this will be an ipfs object)
  // hence one could do the following: /ipld/hash1/pictures/picture1.jpg
  // is this ipld or ipfs -> namespace conflict!!!
  

• we could make /ipld implicit (but maybe not Spec refining: requiring namespace in IPLD pointers #7)

Cons:

• we need to move IPFS links to the application layer
• IPFS cannot be traversed using ipld pathing from an IPLD object (see example above)

However: if IPFS is just a transformation on top of IPLD, then IPFS objects (e.g. folders) are still IPLD objects, hence it might actually make sense to keep IPFS links

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

[daviddias]

Does this imply that all ipld objects will be behind /ipld/ and not /ipfs/?

[nicola]

@diasdavid We should really think about this.

The way I see it is that /ipfs/hash is serving the "transformed" and "data exported" version of its IPLD object. So an IPLD object can be served as raw IPLD /ipld/hash or as a unixfs /ipfs/hash. Mixing the two spaces one would not be able to read the IPLD object of an IPFS object

Let me know if there is a misunderstanding here

[nicola]

@diasdavid this also implies that /ipns will be a bit ambiguous

[dignifiedquire]

I think it would be very important to keep all ipld objects behind a name space like /ipld. This would allow for much better processing and even more human understanding of links. For example if I see a link to some hash that could be anything, but if I see it is prefixed with /ipld I know the thing behind it is an ipld object.

[nicola]

the really important aspect is that: if we don't accept 7 #7, so, we don't require the /ipld path (so we can make it implicit), then all the links are hashes - which I think is neat!

But this requires:

• find another way to distinguish an IPLD from a non IPLD (say ipfs streams)
• find another way to make sure that IPLD is not bound to CBOR forever

[daviddias]

A big post is coming soon (possibly today or tomorrow, //cc @jbenet) describing what is our proposal for migration to IPLD, which includes how to handle this different paths. It will clarify the /ipld/ and /ipfs/ situation

[jbenet]

Does this imply that all ipld objects will be behind /ipld/ and not /ipfs/?

Yes, i think we should do this for the raw merkledag. the objects may still be retrieved through /ipfs/ if the /ipfs namespaces wants to do that. (separate discussion)

The way I see it is that /ipfs/hash is serving the "transformed" and "data exported" version of its IPLD object. So an IPLD object can be served as raw IPLD /ipld/hash or as a unixfs /ipfs/hash

Yes, i see it that way too.

Mixing the two spaces one would not be able to read the IPLD object of an IPFS object

I'm not sure this is a problem. The retreiver would decide how to handle the last object:

/ipld/hash1/pictures/picture1.jpg # is likely an ipld object (unix-fs file obj)
/ipld/hash1/pictures/picture1.jpg # could be a picture (if i understand unix-fs)

I'm not sure we can be "namespace purists" because we'll have to do encapsulated resolution through namespaces elsewhere, and already do it. for example:

• /ipns/ipfs.io/theme/images/ipfs-illustration-network.svg points through a DNS name, through to an IPFS object.
• that could even be /dns/ipfs.io/theme/images/ipfs-illustration-network.svg some day.
• it could even resolve through other namespaces in between. /dns/ipfs.io could be a link to /ipns/<public-key-hash>/a/b/c which would then link to /ipfs/<object-root>/d/e/f which would have theme/ as a link out to the rest.
• This gets more interesting when you start mixing in other name systems and other distributed systems /bittorrent? /bitcoin? /http?
• We're going to have to allow users to resolve namespaces transparently, if the tool supports it. (IPFS programs definitely will have to, and already do).

---

So with /ipld, you can always point to a unix-fs or other data struct object, what should we do then?

• this could be a tool decision (they decide whether to load up unix-fs and use the object)
• this could be a MUST NOT do that, thing. we define that /ipld MUST ALWAYS return JUST the raw ipld object. (seems simpler). but this wont happen for other namespaces-- those (like ipns) will resolve through.

[nicola]

Thanks @jbenet, here are some new thoughts to the conversation:

If IPLD paths can point to byte arrays (like it seems it is now with CID), then IPLD can point to an IPFS object (which is just an IPLD transformed graph).

Also, if we make unix-fs folders to be IPLD objects served via /ipfs, then everything is IPLD and /ipfs is just a namespace that applies some transformations (so still IPLD)

If the above is correct, and we treat any other namespace like IPLD (maybe transformed) objects, then we can link across scheme, and it would be great to have the /ipld space be the default option

[jbenet]

i think that's right. im not 100% sure we agree on all the terms but it sounds right to me

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