I recommend reading below for more information, but many of you are busy. Here’s the proposal, there are alternatives below I’d look at before proposing any other alternatives.
Below is a mapping of how a client (e.g. IPFS HTTP Gateway, Service Worker resolving ipfs://
,etc.) that receives a given HTTP request for unverified data can make an HTTP CAR file request that allows them to verifiably get the data to satisfy that HTTP request.
web
in case we need it.curl -X GET mygateway.tld/ipfs/<cid>/path/to/data?format=car&[other params...]
&depth=<integer|all>
changes how much data under the terminal path is fetched (see ~~?all
(better names welcome)~~ Replaced with depth=(<integer>|all)
)bytes=x:y
changes how much data inside a UnixFS file is retrieved (see ?bytes=x:y
)depth=all
mygateway.tld/ipfs/<cid>/path/to/data?format=car
so that the entire request is verifiable (see /ipfs/<cid>/path?format=car
now returns path blocks)curl -X GET ipfs.io/ipfs/<cid>/path/to/data
→ curl -X GET saturn.tld/ipfs/<cid>/path/to/data?format=car&depth=1
curl -X GET -r x-y ipfs.io/ipfs/<cid>/path/to/data
→ curl -X GET saturn.tld/ipfs/<cid>/path/to/data?format=car&bytes=x:y
curl -X GET -H "Accept: application/x-tar" ipfs.io/ipfs/<cid>/path/to/data
→ curl -X GET saturn.tld/ipfs/<cid>/path/to/data?format=car&depth=all
curl -X HEAD ipfs.io/ipfs/<cid>/path/to/data
→ curl -X GET saturn.tld/ipfs/<cid>/path/to/data?format=car&depth=0&bytes=0:1023