Summary
The Unsplash API documentation makes no reference to local-first apps, IPFS, or peer-to-peer networks. Their core policies effectively conflict with those architectures.
The Core Problem: Hotlinking is Mandatory
Unsplash requires all API consumers to use image URLs returned by the API directly (photo.urls properties). Downloading and re-hosting images is not allowed. This is how they track photo views and attribute credit to photographers.
“All API uses must use the hotlinked image URLs returned by the API under the photo.urls properties. This applies to all uses of the image and not just search results.”
This means:
No downloading and storing locally for offline/local-first use
No uploading to IPFS or any other distributed storage
No self-hosting the images on your own infrastructure
Download Tracking Requirement
When an app performs something similar to a download (e.g. user chooses an image for a blog post, sets it as a header, etc.), a request must be sent to the download endpoint returned under photo.links.download_location.
Exception: Derivative/Remixed Images
If an image is remixed to create a derivative creative work, the result does not need to be hotlinked, since it’s no longer the original source image.
Enterprise Workaround
The docs mention that companies needing their own image infrastructure can contact Unsplash’s API team (api@unsplash.com) for a “photo views beacon alternative”— a tracking pixel embedded instead of hotlinking. This could potentially work for P2P/local-first architectures but requires direct arrangement with Unsplash.
Options for Local-First / P2P Apps
Contact Unsplash about the beacon alternative for enterprise use
Only use Unsplash images online and fall back to placeholders when offline
Use the Unsplash License directly (not the API) — the Unsplash License allows free use including commercial, with no hotlinking requirement. Users would need to download images from unsplash.com themselves rather than through the API