Post

daniel holmgren 🫠
@dholms.at

nice this looks like basically exactly what i had in mind one last question: are `val` in the data section always dag-cbor (and can therefore be decoded while deserializing the STAR)? or is it arbitrary bytes (in each case a second pass is requierd per-value)?

fig (aka:[phil])
@bad-example.com

yeah was thinking unspecified bytes for star vals and the application restricts further if they want. i think this is still easy-ish to do zero-copy with a generic streaming archive reader. not opposed to drisl-only vals or other restrictions in v1 if it’s an easier path for spaces though!

bryan newbold
@bnewbold.net

yeah this looks nice. nit-picky, but I think of magic bytes as being 4x bytes, which is also a bit more word-aligned. could be just another 0x00 for now. explicitly possible to have zero key/value pairs, right? wonder if the key sort ordering should be more use-case specified...

bryan newbold
@bnewbold.net

eg the blobs example I gave they would end up with 'blob/...' at the end, which would be out of overall sort order. for multi-space-repo export, could be nested, with keys being space-ref, and the value being a STAR file. would expect readers to have configurable "max block size"

bryan newbold
@bnewbold.net

oh, I see the size limits are in the text. i'd probably make that more flexible? eg, a default or recommendation, but feels like it should be able to adapt if atproto norms change