I want to preview a major revision of my Dwebsite before I update the IPFS CID to which the mainnet ENS name resolves; this requires locally resolvable names so hyperlinks and resource references work correctly. There are docs available for deploying ENS on a private chain, and also buying ENS names on public testnets, but I have't found any browser config info. I've searched and looked around the IPFS Companion source and settings without success; how do I configure a browser to resolve ENS names outside of the mainnet?
2 Answers
For quick&dirty smoke tests you could run your own version of https://eth.link (sources: coredns-ens for DNS interop+go-ipfs for HTTP gateway part) under some other domain name (eg. ethtest.tld
) and configure it to resolve ENS names using testnet.
Having that in place you can load website using testnet by replacing eth.link
with the suffix of your DNSLink gateway, for example: https://almonit.eth.link → https://almonit.ethtest.tld
For testing you can also choose to run coredns-ens without gateway, and leverage DNSLink resolution on public IPFS gateways instead (for example: http://dweb.link/ipns/almonit.eth/), but then you need to ignore TLS errors caused by domain name mismatch.
Ideally ENS community would provide eth-testnet.link
, but until that is a thing, you can run your own.
-
Cool, thanks! I'll take a look, though it'll take me a while as there's a lot to digest here. Possibly dumb question: could I use coredns-ens to skip the ENS lookup entirely and map a name directly to an IPFS CID?– cqcallawCommented Oct 22, 2020 at 5:16
-
1Yes, you could hardcode CID. But then you are not testing ENS contract, so not sure whats the point of that test? IF you just want to preview website, you can load it from
https://dweb.link/ipfs/{cid}
and it will redirect you to a subdomain where you can preview the website snapshot.– lidelCommented Oct 23, 2020 at 18:24 -
Absolute URIs for stylesheets and images don't resolve correctly in the given preview, though in composing this response I've discovered relative URIs work perfectly; my previous experiments with relative URIs must have been flawed.– cqcallawCommented Oct 24, 2020 at 2:44
-
I think you might've been testing on
https://ipfs.io/ipfs/{cid}
which does not provide Origin isolation and the website's content root (/ipfs/{cid}/
) is not the same as URL root at/
Note thathttps://dweb.link/ipfs/{cid}
redirects tohttps://{cid}.ipfs.dweb.link/
which has website root at/
, removing problem with asset URLs that start with/
So TLDR is:dweb.link
is perfect for testing websites, because paths behave just like they would on your own domain– lidelCommented Oct 29, 2020 at 23:24
While discussing the solution proposed by lidel, I found that I could avoid dealing with ENS entirely if I simply switched to using relative URIs everywhere. I think this is the shortest path to what I need (namely a fully functional site preview before I update ENS), but I've marked lidel's answer as correct so their work in answering the question is credited.