What’s the Proposal TLDR?

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.

Proposal v2

Ratified for M0.2, Still want a proposal for web in case we need it.

How to request verifiable data over HTTP

curl -X GET mygateway.tld/ipfs/<cid>/path/to/data?format=car&[other params...]

• Adding &depth=<integer|all> changes how much data under the terminal path is fetched (see ~~?all (better names welcome)~~ Replaced with depth=(<integer>|all))
• Adding bytes=x:y changes how much data inside a UnixFS file is retrieved (see ?bytes=x:y)
• No extra parameters implies depth=all
• Unlike the current IPFS HTTP Gateway behaviour we will be returning path blocks for 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)

How to represent unverifiable cURL requests to an IPFS HTTP Gateway using verifiable cURL HTTP requests

• GET with no special headers: curl -X GET ipfs.io/ipfs/<cid>/path/to/data → curl -X GET saturn.tld/ipfs/<cid>/path/to/data?format=car&depth=1
• Get with Range Request header: 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
• Get with Application/x-tar accept header: 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
• HEAD with no special headers 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