feat: accept X-PIN-ORIGINS peer hint for content retrieval#310
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
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: