Spec refining: IPLD pointers must point to IPLD objects only about specs HOT 10 CLOSED

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

from specs.

@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

from specs.

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

from specs.

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.

from specs.

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

from specs.

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

from specs.

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.

from specs.

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

from specs.

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

from specs.

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]

from specs.