dev.atfs.repo.getFile
{
"$type": "com.atproto.lexicon.schema",
"defs": {
"main": {
"description": "Fetch a file previously uploaded to this atfs instance. Compatible with com.atproto.sync.getBlob — also mounted, unmodified, under that name, for callers that have no reason to know atfs has its own name for it — with one deliberate difference: did is optional here. Requiring a did the way a PDS does is a repo-scoping artifact (a PDS's blobs live inside a specific account's repo); atfs content is content-addressed by cid alone, and the /ipfs/<cid> gateway path already serves it that way, so a did-less getFile exposes nothing a full IPFS client couldn't already reach. When did is supplied, the file is served only if that account holds a claim on it — pin-set membership (see dev.atfs.repo.deleteFile), which any claimant satisfies whether or not it was the one that originally uploaded the file — a mismatch is reported identically to a missing file — matching com.atproto.sync.getBlob's own scoping exactly; the com.atproto.sync.getBlob alias always requires it, to stay PDS-compatible. Does not require auth, on either name.",
"errors": [
{
"description": "No file is stored under this cid, or — when did is supplied — that account holds no claim on it; the two are reported identically, matching com.atproto.sync.getBlob's own behavior. Also reported, indistinguishably, when this instance once tried to fetch this cid and gave up: a failed fetch stays impossible to tell apart from a cid that was never asked for.",
"name": "BlobNotFound"
},
{
"description": "This instance doesn't have the file yet but is actively trying to fetch it (see dev.atfs.repo.pinFile). Served over HTTP 503 with a Retry-After header naming how long to wait before asking again; retrying is the status check.",
"name": "ContentPending"
}
],
"output": {
"encoding": "*/*"
},
"parameters": {
"properties": {
"cid": {
"description": "The blessed CID (see dev.atfs.file) of the file to fetch.",
"format": "cid",
"type": "string"
},
"did": {
"description": "Restrict the fetch to a file this account holds a claim on (pin-set membership — not necessarily the account that uploaded it). Optional here — unlike on the com.atproto.sync.getBlob alias, where it's required to stay PDS-compatible — since atfs content is addressed by cid alone, so omitting did simply serves any file with that cid.",
"format": "did",
"type": "string"
}
},
"required": [
"cid"
],
"type": "params"
},
"type": "query"
}
},
"id": "dev.atfs.repo.getFile",
"lexicon": 1
}
Metadata
- DID
-
did:web:atfs.dev - CID
-
bafyreiapvzr7lioow6ikg3icsgs2uxdrrg2y66lvdd7phlujo2bhrvwryy - Indexed At
- 2026-08-17 08:18 UTC
- AT-URI
-
at://did:web:atfs.dev/com.atproto.lexicon.schema/dev.atfs.repo.getFile
Version History (2 versions)
- 2026-08-17 08:18 UTC (current)
- 2026-08-09 02:33 UTC diff
Similar Lexicons
Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.
-
com.atproto.sync.getBlob query
Get a blob associated with a given account. Returns the full blob as originally uploaded. Does not require auth; implemented by PDS.
-
dev.atfs.repo.pinFile procedure
Pin a file that already exists on the IPFS network, as if the caller had uploaded it to this instance: the bytes are fetched, verified against the reference's blessed cid, stored, served, and announced, and the caller e…
-
dev.atfs.repo.deleteFile procedure
Release the caller's claim on a file previously uploaded to — or pinned by — this atfs instance. The semantics are pin removal, not unconditional deletion: several accounts can hold independent claims on the same ci…
-
Get a blob by its CID from temporary R2 storage. Returns the raw binary content. The authenticated user's temporary blob is retrieved using their DID and the provided CID.
-
dev.atfs.file object
An embeddable reference to a file hosted on an atfs instance and addressed by IPFS content-addressing. Deliberately not the native `blob` lexicon type: a PDS scans records for blob refs and rejects any whose blob isn't …