0

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?

cqcallaw
  • 103
  • 2

2 Answers2

0

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.

lidel
  • 116
  • 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? – cqcallaw Oct 22 '20 at 05:16
  • 1
    Yes, 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. – lidel Oct 23 '20 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. – cqcallaw Oct 24 '20 at 02: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 that https://dweb.link/ipfs/{cid} redirects to https://{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

     – lidel Oct 29 '20 at 23:24
0

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.

cqcallaw
  • 103
  • 2