feat: accept X-PIN-ORIGINS peer hint for content retrieval #310
Conversation
There was a problem hiding this comment.
Thank you for opening this PoC.
Change like this changes content routing semantics and introduces work / potential security risks for gateway operators.
Next, this should be discussed in ipfs/specs via IPIP process to allow ecosystem to evaluate risks vs user benefit.
Good news is that there is already virtually the same feature proposed in IPIP-504: provider query parameter as hint for HTTP Gateways at ipfs/specs#504. Note my concerns about ad-hoc providers signaling described in ipfs/specs#504 (comment). I would love Filebase to comment their needs and views in that PR.
@acejam I'm marking this as blocked until a specs are agreen on. If you want to move this forward, next step is to either open a new IPIP or PR against IPIP-504 and extend it by proposing alternative signaling via header (whichever you prefer).
| go func(ai peer.AddrInfo) { | ||
| ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second) | ||
| defer cancel() | ||
| if err := nd.host.Connect(ctx, ai); err != nil { |
There was a problem hiding this comment.
💭 this feels like a hack – forcing connection here ignores routing system and retrieval system (bitswap sessions etc). passing provider hints should likely work in a way where we inject them into routing system, this way these hints are not used when not necessary
3 participants
This PR implements "origins" hinting for Rainbow’s HTTP gateway, aligned with the IPFS Pinning Service API.
Clients can now specify an optional
X-PIN-ORIGINSHTTP header along with their gateway request. The header value should be a comma-separated list of peer multiaddresses. Values are parsed, de-duplicated, and each is connected to in parallel with a short timeout to speed up Bitswap retrieval. This feature is helpful in scenarios where a pin origin is known, but the content has not been advertised via DHT/IPNI for various reasons.Example: