Not implying any obligation whatsoever or whatnot here, but the kind of approach you're taking with STAR is a pretty good match for how we're doing things in DASL. We have a very lightweight approach to specs, and if it's of interest to you we'd love to see if it makes sense to include STAR. It'd also be great to have you present it to at a CID Congress if you're up for it!
STreaming ARchives: stricter, verifiable, deterministic, highly compressible alternatives to CAR files for atproto repositories.
atproto
car
DASLify? #1
open
opened by
robin.berjon.com
yes very interested!!
STAR crosses layers to achieve its goals (all variants are atproto-merkle-search-tree-aware), largely to eliminate CIDs from the archive, so it at least feels likely tricky to reach the same ends with a composable set of DASL things. But if the same ends can be reached with DASL bits, that would be really awesome!
Either way, STAR holds cheap-conversion-to-stream-ordered-CAR as a core constraint. The encoded representation is app-specific, but it is still meant to interop via DASL / DASL-adjacent tech, which is worth keeping in conversation about, and maybe a pattern that can be extracted?
mostly unrelated but in case it's not on your radar and might be relevant for CARs generally: https://github.com/bluesky-social/ietf-drafts/issues/18