10 |

11 | DASL components are designed to be small and to the extent possible self-contained. 12 | Because of that, despite having roots in IPFS, no DASL component depends on 13 | traditional IPFS implementations. In many cases, systems produced to work with 14 | DASL will interoperate with IPFS, but DASL's independence means that there can 15 | occasionally be impedance mismatch. This document is a non-normative list of 16 | things to consider when using DASL with IPFS systems, particularly with ones based 17 | on the DHT and Bitswap. 18 |

19 |

10 |

11 | BDASL extends DASL CIDs with a new hash type that works better for large files but isn't 12 | available by default in browsers, and therefore not an appropriate option in most 13 | situations. 14 |

15 |

IPFS Interoperability Considerations

date	2025-10-20
editors	Robin Berjon <robin@berjon.com> Juan Caballero <bumblefudge@learningproof.xyz>
issues	list, new
abstract	23 \| 24 \| DASL components are designed to be small and to the extent possible self-contained. 25 \| Because of that, despite having roots in IPFS, no DASL component depends on 26 \| traditional IPFS implementations. In many cases, systems produced to work with 27 \| DASL will interoperate with IPFS, but DASL's independence means that there can 28 \| occasionally be impedance mismatch. This document is a non-normative list of 29 \| things to consider when using DASL with IPFS systems, particularly with ones based 30 \| on the DHT and Bitswap. 31 \| 32 \|

33 | 34 |

35 |

Amino / Bitswap Compatibility

36 |

37 | If you're interoperating with Amino (or other DHTs with similar properties) or 38 | need to use Bitswap: 39 |

40 |

Block size: 43 | Nothing in DASL assumes a maximum block size, but Bitswap does. DASL does not have 44 | a built-in solution to break files into blocks (and we intend to keep it that way). 45 | In order to plan for interop with Bitswap, you will want to do your own splitting 46 | and probably to have a metadata wrapper to keep track of the split. 47 |

49 |

50 | 51 | 52 |

Big DASL (BDASL)

date	2025-10-20
editors	Robin Berjon <robin@berjon.com> Juan Caballero <bumblefudge@learningproof.xyz>
issues	list, new
abstract	23 \| 24 \| BDASL extends DASL CIDs with a new hash type that works better for large files but isn't 25 \| available by default in browsers, and therefore not an appropriate option in most 26 \| situations. 27 \| 28 \|

29 | 30 |

31 |

Introduction

32 |

33 | BDASL extends DASL CIDs by adding BLAKE3 support ([[blake3]). BLAKE3 is a powerful hashing 34 | framework that works well for progressive verification of large streams. Unfortunately, 35 | it isn't available in browser (and neither is streaming hashing in general) which makes it 36 | inappriopriate for inclusion as the primary hash function in DASL CIDs. 37 |

38 |

39 | It is recommended to avoid using BDASL CIDs in arbitrary open environments, and rather to 40 | focus on using such CIDs in specific cases in which participants are likely to know how 41 | to handle them. 42 |

43 |

44 |

45 |

Parsing BDASL CIDs

46 |

47 | All the parsing works the same as for DASL CIDs ([cid]) with one modification. 48 |

49 |

50 | In the steps to decode a CID, the hash type 51 | may also be equal to 0x1e (BLAKE3) ([blake3]). 52 |

53 |

54 | 55 | 56 |

References

[blake3]: J-P. Aumasson, S. Neves, J. O'Connor, Z. Wilcox. The BLAKE3 Hashing Framework. July 2024. URL: https://www.ietf.org/archive/id/draft-aumasson-blake3-00.html
[cid]: Robin Berjon & Juan Caballero. Content IDs (CIDs). 2025-10-20. URL: https://dasl.ing/cid.html

10 |

11 | DASL CIDs are a simple structured identifier format for content addressing. They encapsulate a hash 12 | with enough metadata to be extensible (to add new hash types in the future) and to indicate whether 13 | they are pointing to raw bytes or to structured data. 14 |

15 |

Content IDs (CIDs)

date	2025-10-20
editors	Robin Berjon <robin@berjon.com> Juan Caballero <bumblefudge@learningproof.xyz>
issues	list, new
abstract	23 \| 24 \| DASL CIDs are a simple structured identifier format for content addressing. They encapsulate a hash 25 \| with enough metadata to be extensible (to add new hash types in the future) and to indicate whether 26 \| they are pointing to raw bytes or to structured data. 27 \| 28 \|

29 | 30 |

31 |

Introduction

32 |

33 | DASL CIDs are a simple structured identifier format for content addressing. They encapsulate a hash 34 | with enough metadata to be extensible (to add new hash types in the future) and to indicate whether 35 | they are pointing to raw bytes or to structured data. If you're simply using DASL CIDs as identifiers, you 36 | can almost certainly just use the string as an opaque ID and worry no further. 37 |

38 |

39 | A DASL CID can be represented as a string or as an array of bytes. If you wish to understand the 40 | internals of a CID, it has the following structure: 41 |

42 |

44 | A b prefix (only in string form). This is an extensibility point for future 45 | CID encodings other than the current base32 to be supported. (Currently this is the only one.) 46 |
48 | A version number, which is currently always 1. 49 |
51 | A content codec, which is a flag indicating whether it is pointing to structured or raw 52 | data. 53 |
55 | A hash type, that is always SHA-256 ([sha256]). 56 |
58 | A hash size, that is always 32 (0x20). 59 |
61 | A digest, which is the hash of the content being identified. 62 |

64 |

65 |

66 |

Parsing CIDs

67 |

68 | Use the following steps to parse a string-encoded CID, i.e. translate it to a bytestring: 69 |

70 |

Accept a string CID.
Remove the first character from CID and store it in prefix.
If prefix is not equal to b, throw an error.
75 | Decode the rest of CID using 76 | the base32 algorithm from 77 | RFC4648 with a lowercase alphabet and store the result in CID bytes ([rfc4648]). 78 |
This results in CID bytes, which can be used to decode a CID.

81 |

82 | Use the following steps to decode a CID: 83 |

84 |

Accept an array of bytes CID bytes.
87 | Remove the first byte in CID bytes and store it in version. 88 |
If version is not equal to 1, throw an error.
91 | Remove the next byte in CID bytes and store it in codec. 92 |
94 | If codec is not equal to 0x55 (raw) or 0x71 (DRISL), 95 | throw an error ([drisl]). 96 |
98 | Remove the next byte in CID bytes and store it in hash type. 99 |
101 | If hash type is not equal to 0x12 (SHA-256), throw an error ([sha256]). 102 |
104 | Read one byte from CID bytes and store it in hash size. If hash size 105 | is any value other than 32 (0x20) , throw an error. 106 |
108 | Read 32 bytes from CID bytes and store them in digest. If there were 109 | fewer than 32 bytes left in CID bytes, throw an error. 110 |
112 | Return version, codec, hash type, hash size, 113 | and digest. 114 |

116 |

117 |

118 |

Relationship to IPFS

119 |

120 | You don't need to understand IPFS in order to use DASL. This section is for informational 121 | purposes only. 122 |

123 |

124 | DASL CIDs are a strict subset of IPFS CIDs 125 | with the following properties: 126 |

127 |

Only modern CIDv1 CIDs are used, not legacy CIDv0.
130 | Only the lowercase base32 multibase encoding (the b prefix) is used for human-readable 131 | (and subdomain-usable) string encoding. 132 |
134 | Only the raw binary multicodec (0x55) and dag-cbor multicodec (0x71), with the 135 | latter used only for [drisl]-conformant DAGs of CBOR objects. 136 |
Only SHA-256 (0x12) for the hash function .
139 | The CID isn't the boss of anyone, but the expectation is that, regardless of size, resources 140 | should not be "chunked" into a DAG or Merkle tree (as historically done with UnixFS canonicalization 141 | in IPFS systems) but rather hashed in their entirety and content-addressed directly. That being 142 | said, a DASL CID can point to a piece of [drisl] metadata that describes this kind of 143 | chunking, if needed. (A separate specification may be added for that.) 144 |
146 | This set of options has the added advantage that all the aforementioned single-byte prefixes require no 147 | additional varint processing or byte-fiddling. 148 |

150 |

151 | 152 | 153 |

References

[drisl]: Robin Berjon & Juan Caballero. DRISL — Deterministic Representation for Interoperable Structures & Links. 2025-10-20. URL: https://dasl.ing/drisl.html
[rfc4648]: S. Josefsson. The Base16, Base32, and Base64 Data Encodings. October 2006. URL: https://www.rfc-editor.org/rfc/rfc4648
[sha256]: National Institute of Standards and Technology, Secure Hash Algorithm. NIST FIPS 180-2. August 2002.

21 |

22 |

DASL — Data-Addressed Structures & Links

23 | 31 |

32 |

33 |

What is this?

34 |

35 | DASL ("dazzle") is a small set of simple, standard primitives for working with content-addressed, 36 | linked data. It builds on content addressing, a proven approach used in Git and 37 | IPFS to 38 | create reliable content identifiers (known as CIDs) through cryptographic hashing. Content addressing 39 | enables robust data integrity checks and efficient networking: systems can verify they received exactly 40 | what they asked for and avoid downloading the same content twice. The linked data part lets you link to 41 | stuff by its hash. You can build very big graphs with these primitives, such as the graph behind Bluesky. 42 |

43 |

44 | We call DASL "data-addressed" because it supports a data serialization component that makes 45 | content-addressing sweet and easy when 46 | working with data. The design is inspired by subcomponents of the 47 | IPFS universe, but simplified to improve 48 | interoperability, decrease costs, and work well with the web. More specifically, our priorities are: 49 |

50 |

52 | pave the cowpaths: we focus on supporting what people trying to solve real-world 53 | problems actually use. This takes over any consideration of engineering ideals or theoretical purity. 54 | We're retconning the spec to what people actually use implement — as it should be. 55 |
57 | extensibility vs optionality: extensibility is important for long-lived distributed 58 | systems, because the world will happen and you will need to change. But introducing optionality 59 | reduces interoperability and increases cost of both implementation and adoption. So rather than 60 | require support for many options now, we have extension points now but deliberately don't use their 61 | full range. 62 |
64 | don't make me think: you don't want to be thinking about content addressing. You 65 | want to grab this off the shelf and have something that works out of the box. Nothing weird, no 66 | impedance mismatch with the systems you know and love (or maybe know and hate, but whatever, it 67 | just works). 68 |
70 | lightweight loading: some people like JavaScript, others don't. We don't care, we 71 | just want things that work. What's certain is that you can't ignore it and be relevant. The ability 72 | to ship small code to the browser is critical. 73 |
75 | Unix philosophy: all of our specs are tiny and meant to compose together in simple 76 | ways that can be implemented independently from one another. 77 |

79 |

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

85 |

86 |

87 |

How

88 |

89 | This section describes how to use DASL patterns. It's work in progress! 90 |

91 |

92 |

93 |

Implementations

94 |

95 | DASL is a strict subset of IPFS CIDs and IPLD, so existing IPFS and IPLD implementations will just 96 | read DASL CIDs and the MASL documents they point to without so much as a hiccup. Some implementations also specifically target a DASL subset. 97 |

98 |

Here are some implementations that partially or fully support DASL:

99 |

101 | atcute (JS/TS): a collection of lightweight 102 | packages to make working with Bluesky and the ATmosphere easy. 103 |
105 | dag-cbrrr (Python): fast DAG-CBOR 106 | implementation. 107 |
109 | python-libipld (Python): a Python 110 | wrapper around Rust, focused on the ATmosphere. 111 |
113 | ipld-core (Rust): fast Rust implementation. 114 |
116 | @dasl/rasl (TS/JS): an implementation of RASL 117 | that's a drop-in handler for ExpressJS. 118 |
120 | rust_cid_npm (Rust): Fast and tiny rust 121 | library, CLI tool, and npm package to generate CIDs. 122 |
124 | go-cid (Go): implements the CID spec 125 |
127 | Kubo/Boxo (Go): 128 | the Swiss-Army chainsaw of all things IPFS. 129 |
131 | Helia (JS/TS): a browser- and CDN-friendly, modular, "import only what you need" JS implementation of IPFS. 132 |

134 |

As of June 2025, a DASL test suite is in development. View the compliance matrix or the source code.

135 |

136 |

137 |

Specifications

138 |

140 | Content Identifiers (CIDs) 141 |: 143 | CIDs (Content IDs) are identifiers used for addressing resources by their contents, essentially a hash 144 | with limited metadata. 145 |
147 | Deterministic Representation for Interoperable Structures and Links (DRISL) 148 |: 150 | DRISL is a profile of deterministic CBOR used to ensure that the same data will have the same CID; 151 | it features native support for using binary CIDs as compact links between documents. 152 |
154 | Content-Addressable aRchives (CAR) 155 |: 157 | The CAR format offers a serialized representation of set of content-addressed 158 | resources in one single concatenated stream, alongside a header that describes 159 | that content. 160 |
162 | MASL — Metadata for Arbitrary Structures & Links 163 |: 165 | MASL is a type of CBOR metadata document that is designed to work well with content-addressed 166 | and decentralised systems, to enable fully self-contained, self-certified content 167 | distribution. 168 |
170 | RASL — Retrieval of Arbitrary Structures & Links 171 |: 173 | RASL is a URL scheme used to identify content-addressed DASL resources 174 | along with a simple HTTP-based retrieval method. 175 |
177 | Big DASL (BDASL) 178 |: 180 | This extends DASL CIDs with a new hash type that works better for large files but isn't 181 | available by default in browsers, and therefore not an appropriate option in most 182 | situations. 183 |
185 | IPFS Interoperability Considerations 186 |: 188 | DASL components are designed to be small and to the extent possible self-contained. 189 | Because of that, despite having roots in IPFS, no DASL component depends on 190 | traditional IPFS implementations. In many cases, systems produced to work with 191 | DASL will interoperate with IPFS, but DASL's independence means that there can 192 | occasionally be impedance mismatch. This document is a non-normative list of 193 | things to consider when using DASL with IPFS systems, particularly with ones based 194 | on the DHT and Bitswap. 195 |

197 |

198 | 209 |

DRISL — Deterministic Representation for Interoperable Structures & Links

date	2025-10-20
editors	Robin Berjon <robin@berjon.com> Juan Caballero <bumblefudge@learningproof.xyz>
issues	list, new
abstract	23 \| 24 \| DRISL is a serialization format that is deterministic (so that the same 25 \| data will have the same CID) and that features native support for using 26 \| CIDs as links. 27 \| It is based on CBOR, using a narrow profile of CBOR's "Core" featureset called "[cborc-42]", specified formally in this IETF document. 28 \| 29 \|

30 | 31 |

32 |

Introduction

33 |

34 | Deterministic encodings that produce the same stream of bytes for any 35 | given data with the same semantics are particularly useful in a content-addressed 36 | context. DRISL provides that, compactly encoded as CBOR. Additionally, it supports CBOR's Tag 42 to compactly encode CIDs ([cid]) as bytestreams. This CID can be used for content-addressed linking 37 | between DRISL documents (such as MASL documents), or to resources (best wrapped in MASL documents where renderability as web documents or web apps is desired). 38 |

39 |

40 | DRISL does not fork CBOR, CDE, or dCBOR ([cbor], [cde], [dcbor]), but it is a subset of features defined in CBOR "Core" ([cborc]), first defined in the earliest CBOR RFC and largely unaffected by refinements made since. 41 | Any decoder for any version of CBOR since v1 will be able to read DRISL 42 | content as conformant CBOR, and with enough carefully configuration of a powerful CBOR library and in some case pre-processing of the data, DRISL can be encoded anywhere CBOR can. 43 |

44 |

45 |

46 |

Format

47 |

48 | DRISL is an application profile of CBOR ([cbor]) that mostly subsets the more established [cborc] profile, with the following additional 49 | constraints: 50 |

51 |

53 | Implementations MUST support Tag 42 in the CBOR 54 | Tag registry; this tag compactly encodes CIDs as bytestrings, as specified below. 55 |
57 | Implementations MUST reject all other tags, including any of the tags 58 | listed in the section 59 | 3.4 of RFC 8949. 60 |
62 | Implementations MUST reject map keys that are not strings. 63 |
65 | Floating-point numbers MUST always be encoded as a 64-bit IEEE 754 binary floating-point, never as a "half-precision" (16-byte, major 7-25) or "single-precision (32-byte, major 7-26)" CBOR key. 66 | NOTE: It is RECOMMENDED that users avoid encoding floating-point numbers as much as possible 67 | to minimize interoperability and tooling issues. 68 |
- 70 | Completely avoiding floating-point numbers is RECOMMENDED to minimize interoperability and tooling issues. 71 |
- 73 | Even where floating-point numbers are used, most of the IEEE 754 "special" floating points (infinity, negative infinity, minimal NaN, and NaN with payloads) MUST NOT be encoded. 74 | Negative zero is the only allowed special floating point. 75 |
77 |
79 | Indefinite-length arrays (and the "break" code making them usable, in major type 7) are not allowed. 80 |
82 | Similarly, indefinite, incomplete, or streaming CBOR cannot be hashed and thus cannot be referenced by CID; for this reason, DRISL can only encode finite, bounded documents and resources. 83 |
85 | Concatenation of DRISL objects is generally discouraged and incurs both performance and interoperability risks. 86 |
- 88 | Note that DRISL objects cannot be streamed as CBOR streams (defined in RFC 8742) except in MIME-type aware contexts, as per the CBOR streams specification. 89 |
- 91 | Applications are discouraged from handling concatenated DRISL objects or appending extra bytes of any kind to a DRISL object in memory or across interfaces, as doing so breaks the DRISL-wide assumption that each CID refers to one complete, discrete, and valid CBOR object, and that DRISL systems only ever will be expected to handle such objects. 92 |
94 |
96 | Encoders MUST NOT encode any simple values other than true, false, and null (20, 21, and 22 in section 3.3 of [rfc8949]). 97 |

99 |

100 | All other requirements are as CBOR/c ([cborc]). 101 |

102 |

103 |

104 |

CIDs in CBOR

105 |

106 | CIDs in CBOR are stored in binary format, as CBOR bytestrings under custom tag 42. For historical reasons the null 107 | byte 0x00 is prepended to the binary CID before storing in CBOR. 108 |

109 |

110 | For more information, see the [cbor-tag42] appendix to the [drisl] specification. 111 |

112 |

113 |

114 |

Conversion with JSON

115 |

116 | JSON lacks a native way to encode tag 42 for CIDs ([cbor-tag42], [cid]). Historically, there have 117 | been different conventions to represent CIDs in JSON. For example, DAG-JSON, part of IPLD, used 118 | an object with a single / key pointing to the stringified CID. 119 |

120 |

121 | The AT Protocol uses an object with a $link key pointing to the stringified DASL CID: 122 |

123 |

        {
124 |           "someSrc": {
125 |             "$link": "bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4"
126 |           }
127 |         }
128 |

129 |

130 | This specification recommends that implementations default to the AT Protocol $link 131 | convention, but may offer the option to support DAG-JSON or other conventions as well. 132 |

133 |

134 | 135 | 136 |

References

[cbor]: C. Bormann. & P. Hoffman. Concise Binary Object Representation (CBOR). October 2024. URL: https://www.rfc-editor.org/info/rfc8949
[cbor-tag42]: J. Caballero. Binary Content Identifiers. May 2025. URL: https://www.ietf.org/archive/id/draft-caballero-cbor-cborc42-00.html#name-binary-content-identifiers
[cborc]: A. Rundgren. Core CBOR Platform Profile. April 2025. URL: https://datatracker.ietf.org/doc/draft-rundgren-cbor-core/
[cborc-42]: J. Caballero, R. Berjon. The tag-42 profile of CBOR Core. May 2025. URL: https://datatracker.ietf.org/doc/draft-caballero-cbor-cborc42/
[cde]: C. Bormann. CBOR Common Deterministic Encoding (CDE). October 2024. URL: https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cde-06
[cid]: Robin Berjon & Juan Caballero. Content IDs (CIDs). 2025-10-20. URL: https://dasl.ing/cid.html
[dcbor]: W. McNally, C. Allen, C. Bormann, & L. Lundblade. dCBOR: A Deterministic CBOR Application Profile. October 2024. URL: https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/
[drisl]: Robin Berjon & Juan Caballero. DRISL — Deterministic Representation for Interoperable Structures & Links. 2025-10-20. URL: https://dasl.ing/drisl.html
[rfc8949]: C. Bormann, P. Hoffman. Concise Binary Object Representation (CBOR). December 2020. URL: https://www.rfc-editor.org/rfc/rfc8949

RASL — Retrieval of Arbitrary Structures & Links

date	2025-10-20
editors	Robin Berjon <robin@berjon.com> Juan Caballero <bumblefudge@learningproof.xyz>
issues	list, new
abstract	23 \| 24 \| RASL is a URL scheme used to identify content-addressed DASL resources 25 \| along with a simple HTTP-based retrieval method. 26 \| 27 \|

28 | 29 | 34 |

35 |

Introduction

36 |

37 | Content-addressed resources are "self-certifying," which is to say that 38 | you don't need any external authority to certify that the content you 39 | have when you resolve the identifier is correct: because the identifier 40 | contains a hash, you can (and should) verify that you obtained the right 41 | content yourself ([ipfs-principles]). The identifier is enough to 42 | certify the content. This has several implications, but two are 43 | particularly relevant for this specification: 44 |

45 |

47 | When resolving a content-addressed identifier, you can obtain the content 48 | from anyone. It doesn't have to be the content's author. You can even 49 | obtain it from entirely untrusted sources — given that you can always 50 | certify it, you don't need to trust whoever gives it to you. As a result, 51 | the authority part of a URL — the part that can certify the content you 52 | get, which is the domain part in an https URL — is the 53 | CID itself ([cid]). 54 |
56 | Because it doesn't matter where you get content from, content-addressed 57 | URLs are inherently transport-independent. There are benefits to agreeing 58 | on transport (if only so that people can find one another's content) 59 | but as a client, if you know of several potential ways of obtaining a 60 | CID you are free to use whichever you prefer or to try several in 61 | whatever order. 62 |

64 |

65 | Taking these aspects into consideration, this specification defines a URL 66 | scheme in which the CID is the authority, along with optional hints of 67 | potential look-up locations, and defines a retrieval method but does not 68 | mandate that RASL retrieval rely on it. 69 |

70 |

71 |

The `rasl` URL Scheme

72 |

73 | RASL URLs look like this: 74 | rasl://bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4/?hint=berjon.com&hint=bsky.app. 75 | This breaks down into the following components: 76 |

77 |

79 | The rasl scheme. This is simply used as an entry point into RASL semantics. 80 |
82 | An authority, which is simply a DASL CID ([cid]), here bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4. 83 |
85 | A path (here just /) that is empty or / and that is expected 86 | to be ignored since RASL is only used for raw data retrieval. 87 |
89 | A query string part, that is parsed according to CGI rules and that contains 90 | zero or more hint entries, each of which is a host from which 91 | that CID can be obtained. 92 |

94 |

95 | Use the following steps to parse a RASL URL: 96 |

97 |

Accept a string url and parse it according to the URL Standard ([url]).
If that's a failure, return the failure.
Read the host part of the parsed URL and store that in cid.
If cid is not a valid CID ([cid]), return failure.
103 | Select all the tuples in the query object associated with the URL ([url]) whose name is 104 | exaclty hint. Each value MUST match the syntax of a valid host for the 105 | https scheme and values which do not match this syntax MUST be ignored 106 | and removed from this list. Store the remaining values in hints. If there were none 107 | then hints is an empty array. 108 |
Return the URL's parts as well as cid and hints.

111 |

112 |

113 |

Fetching RASL

114 |

115 | A user agent may retrieve a CID in whichever way it prefers. This section 116 | provides a simple standard for HTTP-based CID retrieval, to make it 117 | easy for authors to publish content to their own sites and have it 118 | retrieved, without having to worry about operating any infrastructure 119 | beyond the web server they already have. 120 |

121 |

122 | Use the following steps to fetch a RASL URL: 123 |

124 |

Accept a string url and parse it according to the steps to parse a RASL URL.
127 | Construct a request using cid from the url as well as hints that may 128 | be from the URL or from elsewhere (this is entirely up to you): 129 |
1. 131 | For each hint, construct a request URL that is the concatenation of https://, 132 | the hint as host, /.well-known/rasl/, and the cid. 133 |
2. 135 | Prepare the request such that it has a method of either GET or HEAD, 136 | that it is stateless (no cookies, no credentials of any kind), and that it uses no content 137 | negotiation. 138 |
140 |
142 | Fetch the requests. How these get prioritised is entirely up to the implementation. It 143 | is common to run them all in parallel and abort them with the first success response. 144 | Note that the .well-known path may redirect, so be ready to handle that. 145 | This makes it possible to create sites that are published the usual way and to have a RASL that 146 | is simply a redirect to the resource. So for instance, you may have an existing 147 | https://berjon.com/kitten.jpg the CID for which is 148 | bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4. 149 | This can be published as this RASL URL: 150 | rasl://bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4/?hint=berjon.com. 151 | A client can retrieve it by constructing the a request to this URL: 152 | https://berjon.com/.well-known/rasl/bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4. 153 | In turn, the latter may simply return a 307 redirect back to https://berjon.com/kitten.jpg. 154 | (Yes, this is HTTP with extra steps, but the extra steps get you self-certifying content.) 155 |
157 | If the response is a redirect but not a 307, the client SHOULD treat it as if it 158 | had been a 307 anyway. 159 |
161 | If none of the responses are successful, return failure. 162 |
164 | Set the response's media type to application/octet-stream. (The server should have 165 | done that already, but may not have done so, notably if it relied on a redirect.) The purpose 166 | of RASL is to retrieve data in ways that are independent of the server — any media type 167 | processing must therefore take place at another layer. Without this, we lose the self-certifying 168 | nature of the system. (Note that servers are encouraged to enforce that so as not to have their 169 | RASL endpoints used for general-purpose web serving, which can be a security vector depending on 170 | where the data being served came from.) 171 |
173 | Produce a CID for the retrieved data. If that CID does not match the requested cid, 174 | return failure. 175 |
177 | Return the data. 178 |

180 |

181 |

182 |

183 |

RASL Pathing

184 |

185 | Implementations SHOULD ignore paths in RASL URLs. They may be used in a future 186 | iteration of this specification. 187 |

188 |

189 | 190 | 191 |

References

[cid]: Robin Berjon & Juan Caballero. Content IDs (CIDs). 2025-10-20. URL: https://dasl.ing/cid.html
[ipfs-principles]: Robin Berjon. IPFS Principles. march 2023. URL: https://specs.ipfs.tech/architecture/principles/
[url]: WHATWG. URL. Living Standard. URL: https://url.spec.whatwg.org/

Content-Addressable aRchives (CAR)

date	2025-10-20
editors	Robin Berjon <robin@berjon.com> Juan Caballero <bumblefudge@learningproof.xyz>
issues	list, new
abstract	23 \| 24 \| The CAR format offers a serialized representation of set of content-addressed 25 \| resources in one single concatenated stream, alongside a header that describes 26 \| that content. 27 \| 28 \|

29 | 30 |

31 |

Introduction

32 |

33 | The CAR format (Content Addressable aRchives) is used to store series of 34 | content-addressable objects as a sequence of bytes. It packages that stream of 35 | objects with a header. 36 |

37 |

38 | Much of the content of this specification was initially developed as part 39 | of the IPLD project. This specification 40 | was developed based on demand from the community to have just the one simplified 41 | document. Note that a CARv2 specification was developed at some point to add 42 | support for an index trailer, but it met with limited adoption and so was not 43 | considered when bringing CAR into DASL. 44 |

45 |

46 |

47 |

Parsing CAR

48 |

49 | The CAR format is made of a Header followed by a Body. The Header is a length-prefixed 50 | chunk of DRISL ([drisl]) and the Body is a sequence of zero or more length-prefixed 51 | blocks that contain a tuple of a DASL CID ([cid]) which is always 36 bytes long and 52 | the data addressed by that CID. 53 | The length prefix in a CAR is encoded as an unsigned variable-length 54 | integer ([varint], a variant of LEB128). 55 | This integer specifies the number of remaining bytes, excluding 56 | the bytes used to encode the integer, but including the CID for Body blocks. 57 |

58 |

|------ Header -----| |------------------- Body -------------------|
 59 | [ int | DRISL block ] [ int | CID | data ] [ int | CID | data ] …
 60 |

61 |

62 | The steps to parse a CAR are: 63 |

64 |

66 | Accept a byte stream bytes that is consumed with every step 67 | that reads from it. 68 |
70 | Run the steps to parse a CAR header with bytes to obtain 71 | metadata. 72 |
74 | Set up array blocks and run these substeps: 75 |
1. If bytes is empty, terminate these substeps.
2. 78 | Run the steps to parse a CAR block header with bytes 79 | to obtain cid and data size. 80 |
3. 82 | Read data size bytes from bytes and store the 83 | result in data. 84 |
4. 86 | Push an entry onto blocks containing cid, 87 | data size, and data. 88 |
5. Return to the beginning of these substeps.
91 |
93 | Return metadata and blocks. 94 |

96 |

97 | Note that the CAR header contains a near-arbitrary DRISL object that is to be 98 | treated as metadata ([drisl]). For historical reasons, there are two 99 | constraints on the header: 100 |

101 |

103 | The object MUST contain a version map entry, the value of which 104 | is always integer-type 1. Version numbers in data formats are 105 | an anti-pattern, and as a result this number is guaranteed never to change. 106 |
108 | The object MUST contain a roots entry, which MUST be of type 109 | array. It MAY be empty, but if it isn't then it must be an array of CIDs 110 | encoded using tag 42 ([cid]). A CAR can be used 111 | to contain one or more DAGs of [drisl] content and the purpose of the 112 | roots is to list one or more roots for those DAGs. The array 113 | may be empty if you do not care about encoding DAGs. 114 |

116 |

117 | Some implementations will only return version and roots, 118 | but it is RECOMMENDED that they make the entire metadata object 119 | available. A best practice for authors is to use the metadata 120 | to capture MASL content, which is able to provide metadata and a pathing 121 | mapping for the entire content of the CAR stream if needed ([masl]). 122 |

123 |

124 | The steps to parse a CAR header are: 125 |

126 |

Accept a byte stream bytes.
Read an unsigned varint length from bytes ([varint]).
If length is 0, throw an error.
131 | Read length bytes from bytes and decode them as 132 | DRISL ([drisl]) into metadata. If metadata is 133 | not a map, throw an error. 134 |
136 | If metadata does not have a version key entry 137 | with integer value 1, throw an error. Otherwise, store 138 | version in version. 139 |
141 | If metadata does not have a roots key entry 142 | that is an array, or if that array contains anything other than DASL 143 | CIDs, throw an error. Otherwise, store roots in 144 | roots. 145 |
147 | Return metadata. (For implementations that only report 148 | version and roots, return those.) 149 |

151 |

152 | After its header, CAR contains a series of blocks each of which is 153 | length-prefixed and has a small header capturing a CID followed by 154 | the block's body data. 155 |

156 |

157 | The steps to parse a CAR block header are: 158 |

159 |

Accept a byte stream bytes.
Read an unsigned varint length from bytes ([varint]).
If length is 0, throw an error.
164 | Read a CID ([cid]) from bytes and store it in cid. 165 | Note: the length of the CID is always 36 bytes. 166 |
Set data size to length minus 36 (the CID length).
169 | Return data size and cid. 170 |

172 |

173 |

174 |

Additional Considerations

175 |

176 |

Conformance

177 |

178 | A CAR stream must only feature DASL CIDs. 179 |

180 |

181 | A CAR stream must have CIDs that match the data body that follows 182 | them. A CAR implementation should verify that CIDs match block body data, though 183 | it may delegate verification to other components. (Keep in mind that not 184 | verifying at all negates the value of content addressing.) 185 |

186 |

187 | A CAR stream's stated roots must match CIDs contained in the Body. 188 | However, implementations frequently operate in a streaming fashion such that 189 | they have no way of knowing whether a CAR stream conforms to this 190 | requirement before having processed the entire stream. Checking 191 | correctness with respect to this requirement may therefore be more 192 | readily performed via a warning (at end of processing) or a dedicated 193 | validator. 194 |

195 |

196 |

197 |

Determinism

198 |

199 | Deterministic CAR creation is not covered by this specification. However, deterministic 200 | generation of a CAR from a given graph is possible and is relied upon by certain uses of 201 | the format, most notably, Filecoin. 202 | dCAR may be the topic of a future specification. 203 |

204 |

205 | Care regarding the ordering of the roots array in the Header and avoidance 206 | of duplicate blocks may also be required for strict determinism. 207 |

208 |

209 |

210 |

Security & Verifiability

211 |

212 | The roots specified by the Header of a CAR is expected to appear somewhere in its Body section, 213 | however there is no requirement that the roots define entire DAGs, nor that all blocks 214 | in a CAR must be part of DAGs described by the root CIDs in the Header. Therefore, the 215 | roots must not be used alone to determine or differentiate the contents of a CAR. 216 |

217 |

218 | The CAR format contains no internal means, beyond the blocks and their CIDs, to verify 219 | or differentiate contents. Where such a requirement exists, this must be performed 220 | externally, such as creating a digest of the entire CAR (and refer to it using a CID). 221 |

222 |

223 |

224 |

225 |

Appendix: Media Type

226 |

227 | The media type for CAR is 228 | application/vnd.ipld.car. 229 |

230 |

231 | The conventional file extension for CAR is .car. 232 |

233 |

234 | 235 | 236 |

References

[cid]: Robin Berjon & Juan Caballero. Content IDs (CIDs). 2025-10-20. URL: https://dasl.ing/cid.html
[drisl]: Robin Berjon & Juan Caballero. DRISL — Deterministic Representation for Interoperable Structures & Links. 2025-10-20. URL: https://dasl.ing/drisl.html
[masl]: Robin Berjon & Juan Caballero. MASL — Metadata for Arbitrary Structures & Links. 2025-10-20. URL: https://dasl.ing/masl.html
[varint]: unsigned varint. URL: https://github.com/multiformats/unsigned-varint

MASL — Metadata for Arbitrary Structures & Links

date	2025-10-20
editors	Robin Berjon <robin@berjon.com> Juan Caballero <bumblefudge@learningproof.xyz>
issues	list, new
abstract	23 \| 24 \| MASL is a CBOR-based metadata system that is designed to work well with content-addressed 25 \| and decentralised systems, to enable fully self-contained, self-certified content 26 \| distribution. 27 \| 28 \|

29 | 30 |

31 |

Introduction

32 |

33 | Anywhere you have resources that will be deployed in real-world systems, the potential 34 | metadata needs of those systems are effectively unbounded. This is particularly true of 35 | decentralised systems that need to exhibit "web-like" behaviour: in order to have 36 | reproducible and safe execution when content is sourced from arbitrary origins, it is 37 | necessary to have an equivalent to HTTP headers that is as verifiable as the content 38 | itself and not suffer the lossy behaviour that can occur when one treats the web as a file system (which it is not). 39 |

40 |

41 | Designing or constraining a syntax for all metadata needs would be hubris and madness. 42 | Instead, this document tries to minimally constrain applications while illustrating "where to stick" 43 | that metadata, as there are so few layers and hiding places in the DASL system. 44 |

45 |

46 |

47 |

How to use a MASL document

48 |

49 | The recommended structure for DASL metadata is to insert a [drisl] document "between" each 50 | CID and its resource(s), essentially using DRISL to encode headers for one or more CID-addressed resources. 51 | To do this, simply replace the CID of a resource with the CID of a DRISL object that contains a 52 | top-level (tag 42) property named src. 53 | To bundle a set of CIDs in a logical unit, drop the top-level src and replace it with a mapping of paths-from-domain-root to DRISL metadata objects including a src property containing the resource's CID. 54 |

55 |

56 | It is preferable to nest any metadata in a top-level object to namespace your own metadata 57 | vocabulary (inside an object named, for example, `my-cool-project-v1`) rather than using opaque UUIDs, version-bits inserted into values, or magic numbers. 58 | There are a few reserved words at the top-level, but even these can be avoided by nesting any conflicts as needed. 59 |

60 |

61 | There are many metadata standards that can be embedded in this way to facilitate the preservation of 62 | metadata at ingress as well as translatability. For example, the IPFS-based storage system Storacha 63 | has a robust CID-based metadata system called 64 | content credentials which includes UCAN-based 65 | permissioning, inclusion attestations, and CID "equivalences," e.g. mappings of multiple IPFS CIDs equivalent to each other and/or to a given DASL CID. 66 |

67 |

68 |

Using MASL with CAR

69 |

70 | CAR files ([car]) have a space reserved for metadata in their header. 71 | A MASL metadata document can occupy that metadata header-space, 72 | and the variant using a resources map is particularly well-suited to be used there. 73 | The resources field can be used to map paths to the CIDs of resources contained in subsequent CAR 74 | blocks after the metadata header. 75 |

76 |

77 | In order to be inserted directly as metadata object within CAR files, MASL documents need to contain a top-level version property whose value MUST 78 | be set to integer 1 and a top-level roots array that must contain 0 or more tag 42 CIDs and nothing else. 79 | Neither of these fields has any meaning in MASL, but they must be provided in the context of a CAR header for historical compatibility 80 | reasons. 81 | Note that there is no requirements that all the CIDs in a roots array also appear in the resources mapping or vice versa. 82 |

83 |

84 |

85 |

86 |

Fields

87 |

88 | MASL is designed to host arbitrary metadata but for interoperability purposes a number of root 89 | fields have predetermined values. Authors are invited to add their own metadata by creating 90 | namespaced objects at the top level. 91 |

92 |

93 | NOTE: In examples below, whenever we represent a CID as JSON for, say, field 94 | src, we use "src": { "$link": "CID value…" } as a readability convention. 95 |

96 |

97 |

Single or Multiple Resources

98 |

99 | MASL documents are primarily used to wrap around other resources for which they provide 100 | metadata. This can happen in one of two modes: 101 |

102 |

104 | Single Mode (using src): the metadata is only for one 105 | resource, which is the one that can be retrieved from the CID pointed to by src. 106 | HTTP metadata, if specified, goes at the root. App manifest metadata on a single resource 107 | can be used if that resource a fully standalone document (e.g. a PDF). 108 |
110 | Bundle Mode (using resources): the metadata is used to 111 | describe a whole set of resources. These resources SHOULD be related to one another in some 112 | way (e.g. components that go into building an app or document). The keys of the resources 113 | map are complete paths that MUST start with / and the values are metadata 114 | objects that MUST have an src field pointing to the resource's CID and SHOULD have a 115 | content-type field giving its MIME type, along with other HTTP headers. 116 | Any other properties present which do not map to HTTP headers MUST be ignored. 117 |

119 |

120 | Note that if both src and resources are specified, then 121 | src MUST be ignored. 122 |

123 |

124 | The Bundle Mode has some specific processing rules: 125 |

126 |

128 | Default: The entry with path / is the default path that is loaded if the bundle 129 | itself gets rendered, e.g. in a browser or other user-agent. Implementations MUST only recognise this as the default 130 | and MUST NOT automatically decide to pick a given entry (e.g. /index.html). 131 |
133 | Relative: When loading a bundle into a web context, the root of the bundle is given an opaque origin, 134 | and all internal links are resolved relative to that. 135 |
137 | No directory: There is no notion of directory. If a resource is indicated as sitting at /cats/reds/kitsune.jpg 138 | this does not entail that /cats/ or /cats/reds/ somehow exist. As 139 | in web contexts, it is the full path that is matched, not /-separated subsets. URLs 140 | do not map to file systems. 141 |
143 | Query strings: When resolving a URL inside of a bundle, implementation MUST only make use of the URL's pathname and 144 | MUST ignore the query string. (Note that this departs from typical URL processing but makes it easier 145 | to pass parameters between resources internally.) 146 |

148 |

149 | There is no requirement in MASL that bundles have to be stored or dereferenced in any specific manner. The relevant CIDs 150 | may be loaded through whatever way the implementation knows about such as RASL ([rasl]) or may be 151 | provided in a CAR file ([car]). 152 | Note that one value of this approach when compared to bundling resources for instance into Zip archives (or CAR files!) is that the resource map can contain an arbitrarily high number or volume of resources; an implementation may load an arbitrary subset of the resources, may parallelize loading, in an arbitrary order informed by types and HTTP headers, or load some resources on-demand. 153 |

154 |

155 | Specify a scheme and fetch rules properly. 156 |

157 |

158 | Example with src: 159 |

160 |

{
161 |   "src": { "$link": "bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4" },
162 |   "content-type": "application/pdf",
163 | }
164 |

165 |

166 | Example with resources: 167 |

168 |

{
169 |   "name": "A Simple Page With Pic",
170 |   "resources": {
171 |     "/": {
172 |       "src": { "$link": "bafk…" },
173 |       "content-type": "text/html"
174 |     },
175 |     "/picture.jpg": {
176 |       "src": { "$link": "bafk…" },
177 |       "content-type": "image/jpeg"
178 |     }
179 |   }
180 | }
181 |

182 |

183 |

184 |

HTTP Headers

185 |

186 | MASL supports a subset of HTTP response headers that are meaningful in decentralised 187 | contexts. This doesn't preclude headers not listed here from being used, but implementations 188 | that support using HTTP headers SHOULD NOT reflect the value of arbitrary HTTP headers 189 | without considering the potential attack surface they create. 190 |

191 |

192 | When using HTTP headers as MASL metadata, there are two modes. If the MASL document 193 | contains a root resources field then it is a MASL document for multiple resources 194 | and the HTTP headers are only meaningful if they are set on values of the resources 195 | map (and MUST be ignored if set on the root object). Conversely, if this MASL document 196 | contains a src field (and no resources) then the HTTP headers MUST 197 | be set on the root and ignored otherwise. If neither src nor resources 198 | are specified, the meaning of HTTP fields is undefined. 199 |

200 |

201 | All HTTP headers, where specified, are lowercased. 202 |

203 |

204 | Supported headers: 205 |

206 |

content-disposition
content-encoding
content-language
211 | content-security-policy: keep in mind however that runtime contexts are likely 212 | to already have a strict CSP that will override or constrain this one. 213 |
content-type
link
permissions-policy
referrer-policy
service-worker-allowed
220 | sourcemap: this must point to another resource in the resources map. 221 | Implementations SHOULD verify that this is the case as source maps could otherwise be used to 222 | exfiltrate information. 223 |
225 | speculation-rules: this must point to another resource in the resources map. 226 |
supports-loading-mode
x-content-type-options

230 |

231 | Example with src: 232 |

233 |

{
234 |   "src": { "$link": "bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4" },
235 |   "content-type": "text/html",
236 |   "content-language": "en",
237 |   "service-worker-allowed": "/"
238 | }
239 |

240 |

241 | Example with resources: 242 |

243 |

{
244 |   "name": "My Doc",
245 |   "resources": {
246 |     "/": {
247 |       "src": { "$link": "bafk…" },
248 |       "content-type": "text/html",
249 |       "content-encoding": "gzip",
250 |       "content-language": "fr"
251 |     },
252 |     "/interactive.js": {
253 |       "src": { "$link": "bafk…" },
254 |       "content-type": "application/javascript",
255 |       "sourcemap": "/interactive.js.map"
256 |     },
257 |     "/interactive.js.map": {
258 |       "src": { "$link": "bafk…" },
259 |       "content-type": "application/json"
260 |     },
261 |     "/picture.jpg": {
262 |       "src": { "$link": "bafk…" },
263 |       "content-type": "image/jpeg"
264 |     }
265 |   }
266 | }
267 |

268 |

269 |

270 |

App Manifest

271 |

272 | One useful pattern with MASL is to describe an entire app or document, with all of its 273 | resources available for content addressing, possibly within a common CAR ([car]). Such 274 | docs or apps should use Web App Manifest metadata ([manifest]) as it is widely understood. 275 |

276 |

290 |

291 | For both icons and screenshots, the src field MUST 292 | be a path that matches an entry in the resources map, and the type 293 | field that is normally accepted in manifests there MUST NOT be used and MUST be ignored 294 | if specified. Media type information for that resource is specific on the resource entry 295 | that src maps to. 296 |

297 |

298 | Example: 299 |

300 |

{
301 |   "name": "Unicorn Editor",
302 |   "short_name": "Unicorn",
303 |   "description": "This is simply the best app to edit unicorns with.",
304 |   "background_color": "#00ff75",
305 |   "icons": [{ "src": "/unicorn.svg" }],
306 |   "resources": {
307 |     "/": {
308 |       "src": { "$link": "bafk…" },
309 |       "content-type": "text/html"
310 |     },
311 |     "/unicorn.svg": {
312 |       "src": { "$link": "bafk…" },
313 |       "content-type": "image/svg"
314 |     }
315 |   }
316 | }
317 |

318 |

319 |

320 |

CAR Compatibility

321 |

322 | As indicated in the CAR specification ([car]), the metadata object in the CAR header 323 | must contain a version field set to integer 1 and a 324 | roots field set to an array (that may be empty) of tag 42 CIDs. These 325 | fields have no meaning for MASL, but are expected to be set when MASL is used for CAR 326 | metadata for historical compatibility. Note that using versions in this way is an 327 | antipattern, and we expect the value never to change. 328 |

329 |

330 | Example: 331 |

332 |

{
333 |   "name": "Get in the CAR if you want to live",
334 |   "version": 1,
335 |   "roots": []
336 | }
337 |

338 |

339 |

340 |

AT Compatibility

341 |

342 | When used with the AT Protocol ([at]), it is common that objects will need to feature 343 | a $type field. If present, it MUST be a string and SHOULD be set to the 344 | value ing.dasl.masl. 345 |

346 |

347 |

348 |

Versioning

349 |

350 | When manipulating DAGs, it can be useful to keep track of history by referencing 351 | earlier versions of the same data or metadata. This can be done using the prev 352 | field, which if present MUST be a tag 42 CID pointing to a previous MASL document. 353 |

354 |

355 | Example: 356 |

357 |

{
358 |   "name": "Unicorn Editor",
359 |   "prev": { "$link": "bafkreifn5yxi7nkftsn46b6x26grda57ict7md2xuvfbsgkiahe2e7vnq4" }
360 | }
361 |

362 |

363 |

364 |

365 |

Lexicon

366 |

367 | Making a precise lexicon ([lexicon]) for MASL is impossible because lexicons lack a way of 368 | constraining objects with arbitrary keys. However, the following may still prove useful when 369 | MASL is integrated with the AT Protocol ([at]). 370 |

371 |

{
372 |   "lexicon": 1,
373 |   "id": "ing.dasl.masl",
374 |   "defs": {
375 |     "main": {
376 |       "type": "object",
377 |       "properties": {
378 |         "src": { "type": "cid-link" },
379 |         "resources": {
380 |           "type": "unknown"
381 |         },
382 |         // HTTP
383 |         "content-type": { "type": "string" },
384 |         "content-disposition": { "type": "string" },
385 |         "content-encoding": { "type": "string" },
386 |         "content-language": { "type": "string" },
387 |         "content-security-policy": { "type": "string" },
388 |         "link": { "type": "string" },
389 |         "permissions-policy": { "type": "string" },
390 |         "referrer-policy": { "type": "string" },
391 |         "service-worker-allowed": { "type": "string" },
392 |         "sourcemap": { "type": "string" },
393 |         "speculation-rules": { "type": "string" },
394 |         "supports-loading-mode": { "type": "string" },
395 |         "x-content-type-options": { "type": "string" },
396 |         // Manifest
397 |         "background_color": {
398 |           "type": "string"
399 |         },
400 |         "categories": {
401 |           "type": "array",
402 |           "items": {
403 |             "type": "string"
404 |           }
405 |         },
406 |         "description": {
407 |           "type": "string"
408 |         },
409 |         "icons": {
410 |           "type": "array",
411 |           "items": {
412 |             "type": "object",
413 |             "required": ["src"],
414 |             "properties":{
415 |               "src": { "type": "string" },
416 |               "sizes": { "type": "string" },
417 |               "purpose": { "type": "string" }
418 |             }
419 |           }
420 |         },
421 |         "name": {
422 |           "type": "string"
423 |         },
424 |         "screenshots": {
425 |           "type": "array",
426 |           "items": {
427 |             "type": "object",
428 |             "required": ["src"],
429 |             "properties":{
430 |               "src": { "type": "string" },
431 |               "sizes": { "type": "string" },
432 |               "label": { "type": "string" },
433 |               "form_factor": {
434 |                 "type": "string",
435 |                 "knownValues": ["narrow", "wide"]
436 |               },
437 |               "platform": {
438 |                 "type": "string",
439 |                 "knownValues": ["android", "chromeos", "ios", "ipados", "kaios", "macos", "windows", "xbox", "chrome_web_store", "itunes", "microsoft", "microsoft", "play"]
440 |               }
441 |             }
442 |           }
443 |         },
444 |         "short_name": {
445 |           "type": "string"
446 |         },
447 |         "theme_color": {
448 |           "type": "string"
449 |         },
450 |         // CAR compatibility
451 |         "version": {
452 |           "type": "integer",
453 |           "const": 1
454 |         },
455 |         "roots": {
456 |           "type": "array",
457 |           "items": { "type": "cid-link" }
458 |         },
459 |         // versioning
460 |         "prev": { "type": "cid-link" }
461 |       }
462 |     }
463 |   }
464 | }
465 |

466 |

467 | 468 | 469 |

References

[at]: AT Protocol. URL: https://atproto.com/
[car]: Robin Berjon & Juan Caballero. Content-Addressable aRchives (CAR). 2025-10-20. URL: https://dasl.ing/car.html
[drisl]: Robin Berjon & Juan Caballero. DRISL — Deterministic Representation for Interoperable Structures & Links. 2025-10-20. URL: https://dasl.ing/drisl.html
[lexicon]: AT Protocol: Lexicon.
[manifest]: M. Cáceres, K. Rohde Christiansen, D. González, D. Murphy, C. Liebel. Web Application Manifest. March 2025. URL: https://www.w3.org/TR/appmanifest/
[rasl]: Robin Berjon & Juan Caballero. RASL — Retrieval of Arbitrary Structures & Links. 2025-10-20. URL: https://dasl.ing/rasl.html

Amino / Bitswap Compatibility

Introduction

Parsing BDASL CIDs

Amino / Bitswap Compatibility

Introduction

Parsing BDASL CIDs

References

Introduction

Parsing CIDs

Relationship to IPFS

Introduction

Format

CIDs in CBOR

Conversion with JSON

Introduction

The rasl URL Scheme

Fetching RASL

RASL Pathing

Introduction

Parsing CIDs

Relationship to IPFS

References

Introduction

Parsing CAR

Additional Considerations

Conformance

Determinism

Security & Verifiability

Appendix: Media Type

What is this?

How

Implementations

Specifications

Introduction

Format

CIDs in CBOR

Conversion with JSON

References

Introduction

The rasl URL Scheme

Fetching RASL

RASL Pathing

References

Introduction

Parsing CAR

Additional Considerations

Conformance

Determinism

Security & Verifiability

Appendix: Media Type

References

Introduction

How to use a MASL document

Using MASL with CAR

Fields

Single or Multiple Resources

HTTP Headers

App Manifest

CAR Compatibility

AT Compatibility

Versioning

Lexicon

Introduction

How to use a MASL document

Using MASL with CAR

Fields

Single or Multiple Resources

HTTP Headers

App Manifest

CAR Compatibility

AT Compatibility

Versioning

Lexicon

References

The `rasl` URL Scheme

The `rasl` URL Scheme