Post

daniel holmgren 🫠
@dholms.at

nice i dig it, thanks for writing this up! I'm pretty much sold on doing something STAR-like for atproto spaces (CARs feel like a bad fit cuz space repos aren't DAGs) the one thing i'm not sure about is the extra magic byte

daniel holmgren 🫠
@dholms.at

i wonder if the magic byte should describe what's in the STAR file rather than the type of commitment. so instead of "L" for LtHash, it could be "s" for "space repo" also maybe not containing the commitment in the header

daniel holmgren 🫠
@dholms.at

reason being, I'm interested in a "full account export" with all space repos & public repo (for account migrations & backups) this wouldn't have a single "commit" to put in the header is the commit CID necessary? can't you just hash the commit? (similar to how STAR eliminates all the record CIDs)

daniel holmgren 🫠
@dholms.at

but then I kinda wonder if these details shouldn't be in the serialization format at all? like what if the header just goes: magic | len | cbor and the cbor could be something like: { $type: "atproto-space-repo", rev: ..., repo: ... }

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

yeah i was reaching this same place after i pushed this! original star-lite was very coupled to public repos, but it’s a short move to make a separation so header metadata is an app-level concern, which feels nicer and more useful.

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

the separated-out commitment from the original STAR-lite was because the rest of the the commit is technically optional, because i thought i’d need to be able to archive sub-trees for hubble in hindsight, those could have just been another $type (and also i didn’t go that route with hubble)

0 reposts5 likes

daniel holmgren 🫠
@dholms.at

nice hell yea that seems to strike a good level of specific/generic. it's pretty atproto-specific, but it works for many different repo/data types. it's really just "any mapping of path -> dag-cbor with some header metadata" you could even imagine like label exports using this