Some components of the IPFS stack, notably CIDs and IPLD, are either not being adopted because of their complexity or when they are adopted are being stringently subsetted. This points to there being value in aligning on a common subset so that disparate projects can reuse shared code, can interoperate where meaningful, and so that we can build a wider shared understanding around the foundational bricks of self-certifying protocols.
DASL is a lean, practical, interoperable subset of IPFS. It is strictly IPFS-compatible and any IPFS implementation should be able to process DASL content without modification.
The purpose of DASL is to address IPFS's curse of optionality. CIDs and IPLD support so many options that the cost of producing an implementation that can interoperate with arbitrary content is staggeringly high, and the test matrix that exercises all the features between any implementation pair is huge. This:
DASL can be seen as the Don't Make Me Think IPFS. It's extensible for the day when that is needed, but it has limited complexity so that you can use it but remain focused on what you're building.
We don't need a full-fledged standards process for this (thank Eris) but rather we can align on the same options and then simply describe this alignment. The proposal is therefore to have a short discussion (maybe even async, though a short sync workshop may help get people on the same page) and assuming it's successful we simply move on to doing the things that need doing.
Scope of the discussion:
Assuming we agree, the next steps will be:
Details:
For a variety of reasons, there is interest in lifting the Curse of Optionality that has befallen the IPFS stack.
This proposal does not look at the transport layer as that is more involved. A future workshop could tackle that, if there is sufficient need and community interest.
That said, we already know that we can call the transport equivalent
Retrieval of Arbitrary Structures and Links
or RASL
. And used
together, they make up RASL-DASL
.
You're welcome.