Post

PART TWO: All the other reasons i don't like CARs for atproto repo exports! In this one: ambiguities and inefficiencies. (the biggest problem is already hopefully getting fixed in the IETF draft though, yay!)

tangentially related, i have been contemplating a CNAR archive format (content-negotiated archive) for representational variants of the same logical objects

interesting. like a container with multiple possible encodings inside? (hubble supports http content negotiation for star-lite vs car format for `getRepo`, but leaves it at the transport layer)

yeah like apache has already had a type map format (which is basically just a list of headers and quality scores and variants) for god, probably close to 30 years now httpd.apache.org/docs/2.4/mod... whether it ends up using that or something else is still up in the air but determinism is the key

i am a huge fan of conneg (and have been since i first learned about it circa i dunno, 2000?) imo it's one of the essential advantages of web-based information resources over just plain files, but i can understand the positions of eg the ipfs people that it complicates things

yeah the idea would be to bake together all the variants of the same logical resource (assuming it was something that only made sense to GET) so you could cache or ship it around as a unitary file-like blob (on stuff like ipfs even), then plus do things like assert preferences for certain variants

(apache's mod_negotiation just has a mode where you can plop a <basename>.var file down in the document root and it will do the conneg based on that instead of eg the file extensions of everything in the directory)