the link is to https://brantly.eth.link it works but it is an ipfs hash
I have my own ipns link and it appears something changed this week and i get a 404 when I attempt my page. But the url ipns:// works fine in a browser, or a public gateway with for instance .ipns.dweb.link … As far as I can tell this is a Cloudflare issue and I am at a loss on how to resolve this. I have updated my ens.domain once already and am using an ipns:// link so I don’t have to pay the gas to modify the blockchain every time the page needs updating. This is recent as far as I can tell, and not something that appears to be discussed yet online. With the current high costs in gas, this is something that will become critical soon as who wants to pay gas to push an ipfs has when you can manage a ipns hash instead?
ipfs looks like it works fine through eth.link… I’m saying using an ipns hash gives a 404 through the cloudflare gateway, whereas the hash works fine on any other infra.
Here is the synthetic monitoring that shows, when switching to a ipfs hash of the content vs using the previous ipns resolution. Same infrastructure, pinned content to public service, as well as pinned to a publishing server. The results are so dramatic, it can only be a severe regression in how ipns lookups are handled, or forwarded inside the cloudflare gateway. I had to switch back to ipfs, even though it is more expensive to update…
I challenge anyone else to try ipfs vs ipns of the same content…
I believe IPNS resolution is slow because eth.link does IPNS record resolution over DHT, which is bit expensive. IPNS resolution over pubsub should be way closer to immutable /ipfs/ in real life applications.
