Quick takes on https://tangled.org/microcosm.blue/star/blob/main/v1-star/meta.md:
-
"rename this format to just STAR (STreaming ARchive)?" - I recommend calling the version that first gets in a collaborative standards group (including DASL) as "STAR". I do like "star-lite" verbally, but I think "just STAR" has a ton of benefits. maybe call the reference implementation "star-lite"?
-
security section: I mention allocation size checks; reference safe CBOR parsing best practices (maybe by reference to DASL-CBOR?); maybe mention the concept that a valid STAR file might also be valid as other file formats (is that true? PNG, PDF, that sort of thing?); that if parsing STAR data right off the network ("streaming") to watch out for slow-drip DOS attacks; reminder that STAR and contents are often untrusted inputs; maybe something about binary keys having weird UTF-8 junk (surrogate chars, zero-width joiners) if being parsed as strings; maybe something about the overall format being deterministic (or not, eg varints)
-
$typename selection: my current preference would be to do fixed strings for things like atproto space repo commits, but also say that atproto lexicon references (NSID and optional#frag) are allowed as well. That provides a more permission-less extension path. Discussion over on atproto space proposal PR: https://github.com/bluesky-social/proposals/pull/114 -
one-byte separator between blocks: not sure what I think
Two high-level things:
Something I hadn't really picked up on is that requiring ordering of keys makes it possible to detect duplicates without retaining a set of all "seen" keys while parsing. I like that.
4-byte magic: yay, I like that.
varint vs bijou: hmmmm I kind of like bijou and like like boosting friendly proposals like that. but I think that pragmatically varint being in stdlib in so many cases is a pretty strong consideration, so i'd slightly lean towards varint.
security section "Encountering EOF anywhere [...]": I think this is intended to mean that you get an EOF error/exception while reading from a stream of bytes, not refering to an "EOF character", which doesn't really exist (?) but sometimes folks call ASCII 0x04 /
Ctrl-D"EOF". could clarify this.