Comments (2)
This is probably going to get me in trouble, but CIDs with identity multihash are a bit of an escape hatch that could be treated something like a tag. In addition, we also recently added a "reserved range" (mainly for experimentation purposes) in the multicodec table that could be combined with identity multihash to do ... creative things.
Pointing to a data model form of a schema with a CID that's embedded in the block itself is something we've discussed a fair bit but we've never got to the point of pulling the trigger on that - I think partly because we just haven't got enough practical use of schemas yet to test the viability (and sensibility) of this.
Perhaps there's a way to combine ideas here, identity multihash, using CIDs as pointers to other things within (or outside) a doc. Certainly something you'd want to do a lot more experimenting with before we baked anything official into IPLD, you're dabbling in mad science here after all!
@vmx is also heads-down in WASM land too, chasing a vision that @mikeal has been primarily pushing to be able to embed WASM code into IPLD blocks. The first use-case is to get codecs into WASM so you don't need native codecs to interpret data. But beyond that there's a lot of scope for being able to do things like traverse complex data structures using an algorithm that itself is in IPLD and can be fetched by a CID. Perhaps this might be an interesting area for you to explore too?
from specs.
Thanks for the info!
In practice you can probably get away with just using {type = x, value = y}
dicts in most cases and not run into many problems, but it seems like in some situations you may end up with a lot of {type = <string>, value = "<y>"}
instead of just "<y>"
.
I will keep playing around with the IPLD programming language stuff and see what seems to come up in practice.
Pointing to a data model form of a schema with a CID that's embedded in the block itself is something we've discussed a fair bit but we've never got to the point of pulling the trigger on that
Personally I'm on the fence about such a thing. As it'd require hardcoding the choice of schema language, which means it'd necessarily be too coarse for certain data types.
If the tag is just an arbitrary IPLD structure then you avoid the above problem, allowing people to opt in to a schema language of their choice. They could of course still use the schema language provided in this repo.
You could get some of the benefits of a standardized schema language whilst avoiding the above problem by making sure the schema language is extensible. For sufficiently complex data types an overly coarse IPLD schema can be given, and a custom precise schema can be added within it.
This still ends with the IPLD data model spec being quite a bit more complicated, as you effectively have to embed the entire IPLD schema spec within it, rather than it just lying on top as an independent spec.
from specs.
Related Issues (20)
- graphsync spec - clarify relationships between libp2p connections, streams, messages and requests HOT 1
- 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.