Your data on a provider

When this site says "your data lives on your provider, not in Sifa's database", it's a literal description of how the system works. This page makes it concrete.

Records: the unit of storage

Everything on the Atmosphere is a record. A post is a record. A follow is a record. A Sifa profile entry (your current job, your education, an endorsement) is a record. Each one is a small JSON object stored on your provider.

Records have three coordinates:

1. Your DID: whose account they belong to.
2. A collection: what type of record it is (app.bsky.feed.post, id.sifa.profile.position, etc.).
3. An rkey: a unique key within the collection (something like 3lc4apsq2nx2k).

Combined, they form an AT URI:

at://did:plc:abc123/id.sifa.profile.position/3lc4apsq2nx2k

That URI is the canonical address of one particular record on the network. Any Atmosphere app can fetch it directly from your provider. No Sifa involved.

Blobs: the other primitive

Records are the unit of structured data. Blobs are the unit of unstructured data: images, files, anything that doesn't fit in a JSON object. When you upload a profile photo, attach an image to a post, or set a Standard.site publication icon, the bytes go to your provider as a blob; the record that references them stores only a content-addressed pointer.

Two things follow from that:

• A blob is identified by the hash of its content. The same image uploaded twice produces the same identifier. You can reference an existing blob from a new record without re-uploading.
• Blobs live on your provider alongside your records. When you move providers, both move together. When you delete a record that referenced a blob, the blob is eventually garbage-collected (different providers do this on different schedules).

Most Sifa records don't have blobs. Profile photos are the obvious exception. The Standard.site cards page covers a working example of fetching and reusing a blob from your account.

Where Sifa's records live in your account

When you fill in your Sifa profile, you create records in the id.sifa.* collections:

One record per item. One job equals one record. Edit the job on Sifa and the record on your provider updates. Delete the job and the record is gone.

Inspecting your own records

You can look at your records directly, without going through Sifa. Two ways:

Browser: pdsls.dev is a public viewer for any Atmosphere account. Enter your handle, browse collections, see the raw JSON.

Command line: call your provider's HTTP API. To list all Sifa positions on your account:

curl -s "https://bsky.social/xrpc/com.atproto.repo.listRecords?repo=<your-handle>&collection=id.sifa.profile.position" | jq .

(Swap bsky.social for your provider's hostname if you're not on Bluesky.)

The JSON you see is exactly what Sifa reads. No secret fields, no parallel copy.

What happens if Sifa shuts down

Your records don't go anywhere. They live on your provider.

If Sifa shuts down tomorrow:

• Your id.sifa.profile.* records stay readable on your provider.
• The sifa.id AppView (the index + web app) goes dark, so docs.sifa.id and profile pages stop loading.
• Any other Atmosphere app that wants to read the same records can. The data is open.
• Your career history isn't held hostage by us.

What happens if you delete Sifa

If you decide to leave Sifa but stay on the Atmosphere, delete your id.sifa.* records from your provider. Two ways:

• From Sifa: account settings has a delete-everything button that walks all id.sifa.* collections on your account and removes each record.
• From outside Sifa: any tool that talks to AT Protocol's com.atproto.repo.deleteRecord endpoint can delete records directly. pdsls.dev does it in the browser. The goat CLI does it from the terminal.

Either way, Sifa's AppView sees the deletions on the firehose within seconds and removes them from its index. Your profile page becomes empty (or 404, if you also delete id.sifa.profile.self).

Records in other collections (your Bluesky posts, Tangled repos, anything else) are untouched. Sifa only owns the id.sifa.* namespace.

What happens if you move providers

Your records come with you. The migration process exports every record from your old provider, including every id.sifa.* record, and writes them to the new provider. Your DID stays the same. The AT URIs change only at the provider hostname; the AppView keeps reading them via your DID, and the profile keeps working.

See Move your account to another provider for the step-by-step.

Want to go deeper

• Lexicons and integrations: the schemas that define what each record type must contain.
• Apps, AppViews, and the firehose: how Sifa reads these records and renders them.
• DIDs, handles, and providers: the parts of your identity.