Problem: The browser flow needs the shared redirect relay only because the provider's pull validation requires the source URL path to end with /piece/{pieceCid} (pdp/pull_types.go ValidatePullSourceURL), while a trustless gateway serves the same bytes at /ipfs/{cid}?format=car…. The relay contributes nothing but a 302 — the provider already validates pulled bytes against the on-chain commitment — yet it sits in every browser migration's path and its allowlist becomes a trust knob to operate.
Next steps:
- Raise upstream with Curio: either accept an arbitrary HTTPS source URL and rely on the commitment check it already performs, or accept a structured source descriptor (gateway URL + CID) it can rebuild the CAR URL from.
- Track the upstream issue/PR here once filed.
- Keep the relay (and its single-host allowlist) until a released Curio supports this.
Done when: a released Curio accepts a gateway-direct pull source, and the app and docs drop the relay from the passthrough path.
Problem: The browser flow needs the shared redirect relay only because the provider's pull validation requires the source URL path to end with
/piece/{pieceCid}(pdp/pull_types.goValidatePullSourceURL), while a trustless gateway serves the same bytes at/ipfs/{cid}?format=car…. The relay contributes nothing but a 302 — the provider already validates pulled bytes against the on-chain commitment — yet it sits in every browser migration's path and its allowlist becomes a trust knob to operate.Next steps:
Done when: a released Curio accepts a gateway-direct pull source, and the app and docs drop the relay from the passthrough path.