nftstorage.link
nftstorage.link copied to clipboard
🪐 The IPFS gateway for NFT.Storage is not "another gateway", but a caching layer for NFTs that sits on top of existing IPFS public gateways.
Roadmap ## Sprint 0: - [x] Technical Design document + Roadmap - [x] Setup Monorepo #3 - [x] Bootstrap website project #6 - [x] Setup CF Pages deployment for website...
Per https://github.com/nftstorage/nftstorage.link/pull/28#discussion_r861850250 as we already have this in multiple places
As we iterate the `edge-gateway`, it will make sense to have it as a separate package used within `nftstorage.link` and other projects. This issue should track that and an API...
Follow up on https://github.com/nftstorage/nftstorage.link/pull/25 by adding IPNS resolution to gateway race + cache, as well as collect its own metrics
A S3 Exporter that will receive requests for a given CID and will look for it into the S3 `/complete` namespace. The CAR from S3 will be unpacked and unixfs...
CF Worker Gateway needs to support a `/cache/:cid` route that Gateway warm cache aws lambda function will use to ask the CF Worker to cache a response in the context...
When complete CARs are written to S3, we can use them to warm the cache of the gateway and improve reads performance and availability of recently uploaded content as part...
We currently write to S3 all CARs we receive under a `/raw` namespace. Some of them are already complete, while others are partial CARs with a partial DAG of a...
# Gateway warming cache proposal Anecdotal evidence suggests that recent uploads have a high probability to be requested from a gateway in a near future. The solution proposed here aims...
@alanshaw added a few suggestions :bar_chart: :bulb: Additional metrics to collect from the NFT gateway - [x] Histogram of file sizes (tracked in https://github.com/nftstorage/nft.storage/issues/1181) (MB)