• What this is
• Why this is a good idea
• What we need to do
• Related Items

What this is

This is largely the culmination of 🔬Self-service tooling for debugging IPFS request handling and 🎋ipfs.io gateway error pages with a trustless p2p alternative (e.g., Helia) and ensuring it’s exposed to ipfs.io users. Error pages guide a user into determining the problem with their request and what next steps they can take. These include things like:

1. Inspect the request trace with tooling.
2. Use a browser-node (Helia)
3. Use an alternative IPFS implementation (e.g., Kubo)
4. Use Saturn directly
5. Use an alternative gateway

Why this is a good idea

This has most of the same reasons listed in the dependency issues. We are using this an opportunity to emphasize user agency and that IPFS isn’t a black box. Users have choice and ways forward.

What we need to do

• Expose “IPFS Request Traces” in ipfs.io error pages so they can be analyzed by (or do the analysis inline)
• Update error pages emphasizing options.

Related Items

• bifrost-infra: custom HTML on load-balancer/nginx errors
• 🔬Self-service tooling for debugging IPFS request handling
• 🎋ipfs.io gateway error pages with a trustless p2p alternative (e.g., Helia)