DASL — Data-Addressed Structures & Links

What is this?

DASL (“dazzle”) is a small set of simple, standard primitives for working with content-addressed, linked data. It builds on content addressing, a proven approach used in Git and IPFS to create reliable content identifiers (known as CIDs) through cryptographic hashing. The design is heavily inspired by the IPFS universe, but simplified to improve interoperability, decrease costs, and work well with the web.

Systems can verify they received exactly what they asked for and avoid downloading the same content twice. The linked data part lets you link to stuff by its hash. You can build very big graphs with these primitives, such as the graph behind Bluesky.

Our priorities

Pave the cowpaths We support what people solving real-world problems actually use, over engineering ideals or theoretical purity.
Extensibility vs optionality Extension points now, but we deliberately don’t use their full range. Options cost everyone.
Don’t make me think Grab it off the shelf and it works. Nothing weird, no impedance mismatch.
Lightweight loading Some people like JavaScript, others don’t. Shipping small code to the browser is critical.
Unix philosophy Tiny specs that compose in simple ways and can be implemented independently.

This is intended to work for the community, to grow support for what we need. If you have thoughts, don’t be shy and submit an issue! No stupid questions, don’t assume everyone else has context that you don’t. If this page isn’t enough to understand DASL, then we’re the ones who screwed up.

How

DASL uses content identifiers to create a shared namespace for content (raw data) and metadata (structured documents), so documents can easily reference data and other documents.

Because identifiers are content-addressed with SHA-256, anything in the namespace can be hosted anywhere and retrieved (RASL) from anywhere. Data is self-certifying, so you can build open systems without trusting where it came from.

Other specs help you build larger systems, like MASL for document schemas and CAR for bundling for transfer or storage. Together, they let you build coherent linked data graphs that scale and travel easily.

Example document (pseudo-JSON, for legibility)

{
  // Some metadata
  "author": "Samuel Johnson",
  "ts": "2024-05-03T03:22:04.000Z",
  "type": "create",
  "path": "/foo/bar/baz",

  // Now we reference a blob of data, by hash.
  // CIDs can be stored natively as bytes in documents, for efficiency.
  "data": bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4,

  // We can reference other documents as well.
  // The first few bytes of this CID tell us (1) that it points to a
  // structured CBOR document, not a blob of raw data, and (2) the hash
  // of that document, so we know whether we already have it stored.
  "author_profile": bafyreibgiedphoxy4pmqv2jmdm5atqq4dbe5ujtm3ebs6ue7gbwlec5do4
}

Implementations

Here are some libraries to get started today. See a missing library? File an issue or PR.

JS / TS

@dasl/rasl: RASL handler for ExpressJS.
@dasl/tiles: Web Tiles loader, CLI, and server.
atcute: lightweight packages for the ATmosphere.
Helia: modular, browser-friendly IPFS.

Python

carbox: CAR v1 reader and writer.
dag-cbrrr: fast DAG-CBOR.
python-libipld: Python wrapper around Rust.

Go

go-cid: the CID spec.
go-dasl: DRISL, CID, and more.
Kubo / Boxo: the Swiss-Army chainsaw of IPFS.

Rust

dasl: CIDs and DRISL.
ipld-core: fast Rust implementation.
rust_cid_npm: tiny library, CLI, and npm package.

Other languages

elixir-dasl (Elixir): CID, DRISL, and CAR.

DASL is a strict subset of IPFS CIDs and IPLD, so any library that supports CIDv1 and DAG-CBOR can read DASL data, too. Check each library’s results in the compliance matrix, or run the test suite yourself.

Specifications

Maturity levels: Hot New Stuff Stabilising Stable

Foundations

Identifiers, encoding, bundling, and metadata.

CID — Content Identifiers: Identifiers for addressing resources by their contents: essentially a hash with limited metadata.
DRISL — Deterministic Representation for Interoperable Structures & Links: Deterministic CBOR, so the same data always gets the same CID, with CIDs as compact links.
CAR — Content-Addressable aRchives: A set of content-addressed resources in one stream, with a header that describes it.
MASL — Metadata for Arbitrary Structures & Links: CBOR metadata documents for self-contained, self-certified content distribution.
BDASL — Big DASL: A hash type for large files with streaming verification. Not in browsers by default.

Retrieval & Discovery

Getting content, and finding out where it lives.

RASL — Retrieval of Arbitrary Structures & Links: A URL scheme for DASL resources, plus a simple HTTP-based way to fetch them.
FISL — Finding Internet Structures & Links: An HTTP lookup API that maps CIDs to where you can get them, and who announced them.
ATFISL — Content Discovery with the AT Protocol: Publishers announce download locations in their AT repos; indexers gather them for FISL.

Media

Video and audio, provenance, and more.

MUXL — Media Uniform eXact Layout: Stable identifiers for video and audio. It’s like DRISL for MP4 files!
S2PA — Simple Standard for Provenance and Authenticity: C2PA media signing, extended for decentralized identity systems.
PFP — Perceptual Fingerprint: Perceptual hashes that point at similar content rather than one exact file.

Web Tiles

Small, safe, composable web apps.

Web Tiles: Composable web docs and apps that run safely anywhere: social media, chat, agents, and malleable software.
Tiles Protocols: How tiles get capabilities and talk to whatever environment they’re embedded in.
Tiles Protocol: Data Passing: Passing data to and from tiles, so they fit into any environment.

Informative

Guidance and project documents.

IPFS Interoperability Considerations: What to consider when using DASL with IPFS systems, especially DHT and Bitswap ones.
Governance of the DASL Project: How the DASL Project works: stewards, editors, maturity levels, and new specs.