Content Pinning

IPFS has a property that surprises everyone once: putting content on the network does not keep it there. Nodes cache what passes through them and garbage collect it later, so an unpinned CID is a link that works today and 404s next month. Pinning is the instruction to keep specific content, and it's the difference between "published" and "temporarily cached".

For research data this isn't a nice to have. A CID cited in a paper has to resolve for as long as the paper is read - which is longer than any grant cycle.

Pinning is automatic here

There is no separate "pin" call to remember, because forgetting it would be the single most expensive mistake a user could make. Anything you upload through POST /api/upload is pinned as part of the write, content is durable the moment the upload returns a CID.

# Uploading pins. Nothing else to do.
curl -X POST https://api.ekayana.com/api/upload \
  -H "Authorization: Bearer $TOKEN" \
  -F "file=@dataset.csv"

To see everything you currently hold:

curl https://api.ekayana.com/api/pins -H "Authorization: Bearer $TOKEN"

Unpinning is reference-counted

POST /api/delete with { "cid": "..." } drops your claim on the content. Here content addressing has a consequence worth pausing on: because a CID is a hash, two users who upload identical bytes share one stored object. So the platform counts owners, and content only leaves IPFS when the last one releases it. Your delete never destroys a colleague's copy, and their delete never destroys yours.

That's the entire model. Upload pins, delete releases your reference, and nothing needs babysitting in between. The pin list above is mostly useful for auditing what you're storing, not for maintenance.

Where this connects. Reference-counted deletion is also why the GDPR erasure story leans on encryption rather than unpinning alone - releasing the platform's copy can't recall bytes a third party already fetched. And if you need a mutable reference on top of immutable pinned content, that's IPNS.