IPIP-462: Ipfs-Path-Affinity on Gateways

[lidel]

TLDR

Extends Gateway specs with optional Ipfs-Path-Affinity request header. That is all.

If header is present in request, gateway can leverage this optional hint to improve content routing.

The idea is that trustless clients like https://www.npmjs.com/package/@helia/verified-fetch making request for a block or car have additional information which could be leveraged by gateway.

Background

Endpoints that implement https://specs.ipfs.tech/http-gateways/trustless-gateway/ may receive requests for a single block, or a CAR request sub-DAG of a bigger tree.

Not every CID is announced today, some providers limit announcements to top-level root CIDs. Over time, both clients and servers should get smarter about the concept of "affinity": when processing a request for a content path that is deeper than a root CID, leverage parent segments as additional hint for content routing lookup.

cc https://github.com/ipfs/kubo/issues/8676 https://github.com/ipfs/kubo/issues/10251 https://github.com/ipfs/kubo/issues/10365

[2color]

What would be the general expectation of a server when a client requests, for example, a binary leaf block that isn't announced, and the affinity header of an announced CID is passed?

A client requests bafk..ufqy and passes bafy...nkuq in the Ipfs-Path-Affinity header.

[lidel]

• @2color the idea is that the hint would be the content path of parent entity that triggered block request. So if we want to load one of internal blocks of astro.jpg, Ipfs-Path-Affinity would be pointing at /ipfs/bafy..jomu/astro.jpg
• Addressed some feedback, added description of field format in trustless-gateway.md
• Opened https://github.com/ipfs/boxo/pull/592 with poc implementation for boxo/gateway