Comments (10)
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 havetheme/
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.
Related Issues (20)
- graphsync spec - clarify relationships between libp2p connections, streams, messages and requests HOT 1
- Self describing objects in the data model layer HOT 2
- Defining Any and its behaviors HOT 13
- Endianness in IPLD Codecs HOT 2
- CBOR: Data model serialization in Rust HOT 22
- Add more examples to Selector specs HOT 3
- Invariants for IPLD Codecs HOT 3
- Define "component specifier" HOT 1
- Spec for inline CID’s
- Request: Magic AMT HOT 2
- Data model - Integer as map key HOT 5
- Representation of Infinity and NaN in DAG-JSON HOT 11
- Confusion about envelope (and inline) representation of unions HOT 5
- Best practices for IEEE-754 non-fintite numbers (NaN, Infinity) HOT 1
- Documentation about "context" HOT 1
- codec: pathed link HOT 9
- Data Model claims (erroneously?) that DAG-CBOR rejects integers outside of 64 bit range HOT 1
- Is the String kind conceptually a series of bytes or characters? HOT 15
- Why is the reified form of IPLD Schemas "generally presented as JSON" instead of IPLD itself? HOT 1
- Register MIME type application/car with IANA HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from specs.