Post

I think this is legit to call out! STAR-lite is cool and solves a couple other paper cuts. but I think churning on low-level formats in the protocol spec itself probably isn't worth it? I do think the ecosystem can+should migrate away from older flexible IPLD libs to stricter DASL/atproto libs

yeah, if the reached-for libraries trend toward DASL (with actually-checked CID behaviour, which isn't technically required from the library itself in DASL) then hopefully the safety story gets better. i don't think the footgun will ever go away but maybe a kind of herd immunity works out

for public atproto this was really part 1 -- i think the streaming story is still bad, and that we need changes to DASL. (it doesn't actually say you're allowed to require a specific block order! it also vaguely hints that duplicate blocks could become disallowed! i worry about "happens to work")

(plus we still need to figure out how stream-ordered cars are even signalled, they still don't work by current draft. (i'm overdue for making the wg mailing list follow-up!)) for both spaces and public atproto it's a little disappointing to land at ~2x size/bandwidth overhead. but,

I think the IETF version will be a small v4 bump of the repo format, and folks could look for that in the CAR commit block (eg, by sniffing the first 10 KByte of the CAR). is that enough, or do you think we'd still need an HTTP header or something?

for a flag, http response header avoids doing gross car hacks (magic root, magic first block, additional field on commit thats not part of the signed rep, …), but a little unfortunate to tie it to transport imo maybe @dasl.ing would be open to somehow marking a car as “ordered”

No replies yet.