MASL, atproto; blobs and AT URIs

[bnewbold]

The MASL pattern of wrapping a CID with metadata is pretty interesting! And i'm glad to see some atproto affordances in the doc.

In the atproto system, we usually refer to two kinds of to things by CID in two situations: referencing a public record, or referencing a media "blob".

For records, we usually also want the AT URI (eg, at://did:plc:abc123/com.example.type/3q4281), which gives additional content and helps locate the record in the network. For MASL, might help to have a field named something like atproto-ref (or at-uri? or something better, I don't love these names) as a norm for making such a reference.

For blobs, we have a $type: blob object which includes a CID link and basic metadata like size, mimetype, etc. In the atproto system, this is actually critical/required for the blob to actually stick around in the user's account; without a blob ref, the blob will be garbage collected after a short period. For MASL, a field like blob (or atproto-blob) could be a norm for storing such a reference.

Both of the above would work in the context of a "single" MASL reference (src) or a "bundle" (resources).

[bumblefudge]

i don't know if we should formally reserve these as metadata keys in the dasl.ing specs per se, but it would definitely make sense to use these in tutorials and examples, and/or to write a profile somewhere specifically for how DASL tooling should handle ATP .car exports/backups specifically, aligning with bsky.storage, etc.