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!
Something went wrong. Try again.
STreaming ARchive format: simpler, stricter, smaller than CARs for a subset of use-cases.
Something went wrong. Try again.
DASLify? #1
Argh, sorry, I thought I had email notifications on but didn't 😦
I think it's worth having the conversation about it in the DASL community. The only thing we're absolutists about is making things work. We already have specs that assume AT. Would you be up for talking about it at a CID Congress? It's a very friendly and informal monthly. Worst-case scenario it'll be a good conversation, but I can see people being interested in landing this.
ok cool! if i'm finding the right CID Congress page (21 may?), i wouldn't be able to talk at this one but probably can for June.
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