Simplified content discovery for CIDs

Have a content identifier (CID)? Find where to fetch the content with FISL. Publishers share content locations on the AT Protocol through ATFISL. FISL resolves a CID into a list of download URLs. It is part of DASL.

Open the console → Why FISL? For IPFS users

A CID says what, not where

Content addressing decouples two questions that usually travel together: what the data is, and where you get it. Given a CID, a client can verify the bytes it receives no matter who served them. That leaves one question open, and it is the awkward one — who has them?

Two specifications

They fit together, and either works without the other.

FISL — the lookup An HTTP API that maps a CID to the URLs it can be fetched from, and to who announced them. It specifies the query interface only, so any index can sit behind it. → ATFISL — the publication layer Publishers announce locations by writing dev.fisl.at records to their own AT Protocol repository. Every record is signed, and moves hosts with its publisher. →

FISL does not require ATFISL. It specifies the query interface and nothing else.

How it works

Publish data

Host the data

Store your data in one or more locations, on your own servers or with hosting providers. Serve it over HTTP or another protocol.

Publish the locations

Write an ATFISL record to your repository on an AT Protocol personal data server (PDS). The record uses the CID as its key and lists the URLs where clients can fetch the data. Update the record when locations change, or delete it to retract the announcement.

Fetch data

Resolve the CID to locations

Query a FISL endpoint that indexes ATFISL records to find URLs for a CID. If you know the publisher, you can read their ATFISL record directly from their PDS instead. This path needs no indexer.

Retrieve and verify the data

Fetch the data from a returned URL using a protocol your client supports. Hash the bytes and compare the result with the CID to verify the content. If a location fails or returns the wrong content, try another.

Indexing is optional. An index can aggregate ATFISL records from multiple PDS repositories. You can also serve a FISL endpoint from your own storage backend without using AT Protocol. Resolution finds locations; retrieval fetches the data from those locations.

Try it

Because an ATFISL record key is the CID, a publisher's PDS answers “do you serve this CID?” in one request — no indexer in the middle. The console does exactly that, live, against the real network.

Look up a CID Resolve a handle to its PDS and fetch a record, rendered in the FISL response shape → Publish a record Fill a form, then write the dev.fisl.at record to your own repository →