| date | editors | issues | abstract |
|---|---|---|---|
| 2026-01-23 | |||
| Robin Berjon <robin@berjon.com> Brendan O’Brien <b5@n0.computer> Juan Caballero <bumblefudge@learningproof.xyz> | |||
| list, new | |||
| BDASL extends DASL CIDs with a new hash type that works better for large files but isn’t available by default in browsers, and therefore not an appropriate option in most situations. BDASL also supports streaming verification. |
Introduction
BDASL extends DASL CIDs by adding BLAKE3 support ([blake3]). BLAKE3 is a powerful hashing framework that works well for progressive verification of large streams. Unfortunately, it isn’t available in browser (and neither is streaming hashing in general) which makes it inappriopriate for inclusion as the primary hash function in DASL CIDs.
It is recommended to avoid using BDASL CIDs in arbitrary open environments, and rather to focus on using such CIDs in specific cases in which participants are likely to know how to handle them.
Parsing BDASL CIDs
All the parsing works the same as for DASL CIDs ([cid]) with one modification.
In the steps to decode a CID, the hash type may also be equal to 0x1e (BLAKE3) ([blake3]).
Streaming Verification
Some content is big. While this produces challenges in all contexts, it creates specific issues with content addressing. When retrieving content-addressed data, verifying the retrieval typically requires having all the bytes available. Not only may this be resource-intensive, it is also impractical: imagine watching a multi-hour video only to be told when you’re almost done watching the whole thing, which is to say when the last bytes are buffered, that you got the wrong, possibly fraudulent video.
Streaming verification is a process that makes it possible to verify data incrementally or partially. The high level use cases for this are two-fold:
- Check as you go: you stream data (presumably from the beginning) and the receiver is able to ensure that the data is correct in incremental chunks.
- Check within ranges: the receiver retrieves arbitrary (or near-arbitrary) subsets of the sender’s data, and is able to verify the retrieved chunks without seeing the whole thing or even the bytes that came before a given chunk.