ipfs/public-gateway-checker

Test with dynamic CID

lidel opened this issue · 2 comments

lidel commented

@schomatis raised a good point in #156 (comment)

My only request would be that CID we're using to test subdomain redirection not be static so a malicious/lazy gateway couldn't just bypass it with a basic redirect that doesn't even understand the protocol.

Good idea, but implementation needs more analysis. The main challenge here is content routing speed – if we generate random text for each page load, it will take some time for gateways to find it and implies the page needs to run js-ipfs with some relay/preload setup.

You could set up a CI (GitHub Actions?) which generates random text for each pushed commit instead (or on a set interval), pins that text somewhere, and deploys a version of the website which checks for that hash. It wouldn't be randomized per page load, but often enough that you couldn't trivially bypass the check.

If you did this on the browser side not only would you need js-ipfs, but the measurement time would be measuring the time it takes for a gateway to fetch content from the js-ipfs client, rather than the response time of content they already have cached. I can see how that'd be useful to someone, but it's still probably less useful for most people looking for public gateways.

With this setup you could also do other neat things like automatically pin/publish the site on IPFS to tackle some #93 problems.

I think this would make a great second test. I don't think we should replace our existing static CID tests, but we should add an additional test using the methods proposed by @jonaharagon