place.stream.media.origin

An attestation that a MUXL blob is available for download from the publishing node, retrievable via XRPC (com.atproto.repo.getBlob and similar). Published by the Streamplace node that hosts the blob, not by the user who owns the underlying video. The rkey is conventionally the blob's BDASL CID — atproto lexicon doesn't yet have a literal-rkey syntax so we settle for `key: any` and rely on the convention.

Repository @stream.place did:plc:rbvrr34edl5ddpuwcubjiost not from the namespace authority
Details · record, key any
Kindrecord
Record keyany
Authoritymedia.stream.place
Indexed

Record

record · key any

Properties

blob

requiredstring

BLAKE-3 content hash (BDASL CID) of the blob.

mimeType

requiredstring

MIME type of the blob (e.g. video/mp4).

size

requiredinteger

Size of the blob in bytes.

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • place.stream.media.defs

    not from the namespace authority

    A track backed by a MUXL container

  • place.stream.playback.getVideoBlob

    query not from the namespace authority

    Fetch a content-addressed MUXL playback blob by CID. Serves either a primary fMP4 archive or a per-track init segment — both are CID-addressed and indistinguishable from the endpoint's point of view. HTTP `Range` headers are honored; HLS media playlists generated by getVideoPlaylist reference this endpoint with `EXT-X-BYTERANGE` to serve segments out of the primary blob. The `did` identifies the owning account for egress accounting: the blob itself is content-addressed and owner-agnostic, so the

  • A record for uploading and tracking binary blob files with metadata.

  • A video registered for inclusion in a consent-first dataset (version 2 of org.consentvid.video). The record commits to the bytes by content hash and says where they are stored; it does not hold them. Its consent, if any, is the org.consentvid.consentV2 record in the same repo with the same record key (a sidecar record). Records are public: never put personal data or filesystem paths in them.

  • A verifiable media record: signed provenance metadata plus BitTorrent distribution pointers.