Documentation

Welcome to Ekayana

Ekayana stores research data on IPFS and gives every dataset a did:bio identifier that anyone can resolve without asking permission. Files are addressed by their hash. Access is granted with short lived, revocable capability tokens rather than API keys. Every file is encrypted before it reaches the network.

Research data has a citation lifetime measured in decades, and most of the infrastructure holding it does not. A DOI resolves for as long as someone keeps paying for the resolver. A dataset behind an institutional login disappears when the lab does. Content addressing and self certifying identifiers remove both of those dependencies, and everything else here follows from that.

What the platform is made of

Storage is a private IPFS cluster, and every upload is sealed and pinned on every peer as part of the write. There is no separate pin step to forget. Identity is a W3C conformant DID method anchored on Solana. Your identity is your wallet, every dataset gets a DID that wallet owns, and the platform holds no signing key for anyone. Authorization is UCAN. Each grant names one resource, carries a signed expiry, is signed by your wallet, can be revoked, and can be redelegated without anyone handing over a credential.

Content keys are wrapped with ML-KEM-1024, and DID documents can carry ML-DSA-87 assertion keys. Both are the final FIPS standards rather than the round 3 drafts. Where that protection applies and where it stops is spelled out on the Post Quantum Security page.

The rest is specific to research work. BioAgents index registered papers and enrich them from a knowledge graph. A Dataverse bridge lets a dataset keep the DOI it already has. IPNS pointers let a dataset be revised without breaking the citation to the version a reviewer read.

Quick start

There are four steps. Register, sign in for a token, upload, and share.

No SDK is required. The platform is a plain HTTP and JSON API, so any language with an HTTP client works. A published client library is planned but not yet released, so the examples below use curl and fetch.

Authenticate

bash
curl -X POST https://api.ekayana.io/api/signin \
  -H "Content-Type: application/json" \
  -d '{ "email": "ada@lab.example", "password": "..." }'
# -> { "token": "...", "user": { "id": 42, "username": "ada", ... } }

Every subsequent request carries that token in the Authorization: Bearer <token> header. See Authentication.

Upload a file

bash
curl -X POST https://api.ekayana.io/api/upload \
  -H "Authorization: Bearer $TOKEN" \
  -F "file=@results.csv"
json
{ "cid": "bafkrei...", "name": "results.csv", "size": 20480,
  "content_type": "text/csv", "timestamp": "2026-07-24T10:00:00Z", "user_id": 42 }

The same call from JavaScript follows.

javascript
const body = new FormData();
body.append('file', file);

const res = await fetch('https://api.ekayana.io/api/upload', {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}` },
  body,
});

const { cid } = await res.json();

The CID is the hash of the sealed envelope the API stored rather than of your file. Every upload is encrypted under a fresh key first, so even identical bytes get a new CID, and only the API can open it. See File Storage.

Where to go next

The tutorials are ordered the way you would use them.

If you would rather start from the design instead of the API, read System Architecture first. It is the map, and most of the platform's decisions trace back to the two pages it points at, the registry program and UCAN Authorization.