DNSLink on Opera Android does not load

[benhylau]

Expectation

I expect DNSLink to resolve and load using ipns:// scheme on Opera Android.

Problem

For example, this link does not resolve:

ipns://api.staging.compost.digital/v0/monetization/balances.json

This resolves over:

• ipns:// scheme on Firefox Desktop + IPFS Desktop via local IPFS instance
• ipns:// scheme on Agregore Desktop browser
• https:// scheme via path-based gateway such as https://ipfs.io/ipns/api.staging.compost.digital/v0/monetization/balances.json (on Desktop browsers and Opera Android)

This may be related to #169 but also seems to fail even before hitting that bug on Opera Android. It appears to not match it as a IPFS URL at all.

Note that I have been able to resolve other IPFS CID via ipfs:// in this browser.

Things I have tried

Changing the Opera Android gateway to a path-based one like https://ipfs.io in the crypto wallet setting of the app, but that didn't change anything. After speaking with @lidel in chat it appears Opera Android only allow subdomain gateways.

[lidel]

Thank you for reporting this.
Opera for Android leverages subdomain gateway on https://dweb.link, which suggests that the source of the issue is related to #169.
We'll look into this, and if confirmed, ship a fix in go-ipfs in January, which will then get populated to public gateway at dweb.link

[benhylau]

@lidel @aschmahmann I don't think this is fixed in Opera for Android.

ipns://en.wikipedia-on-ipfs.org/wiki/ in Opera Android

• opens up https://en.wikipedia-on-ipfs.org/wiki/
• instead of https://en-wikipedia--on--ipfs-org.ipns.dweb.link/wiki/

If you try to load ipns://staging.compost.digital, Opera tries to load it via HTTP and fails since the domain has no HTTP site at the moment. Opera is not handling IPNS with DNSLink regardless of #169.

[lidel]

@benhylau you are right.

Opera Mobile is loading canonical origin for DNSLink names, afaik they did that to work around TLS error until #169 was addressed.

I'm reopening this + will reach out to Opera asking to update their browser to leverage TLS-compatible DNSLink support at dweb.link (and soon all the other gateways).

Best practice for loading IPFS URI via a public gateway

TLDR: one can now load https://dweb.link/ipns/{dnslink-domain} and that will get redirected to a subdomain compatible with single level wildcart TLS certs (*.ipns.dweb.link in this case):

• https://dweb.link/ipns/staging.compost.digital → https://staging-compost-digital.ipns.dweb.link

If user agent does not run own node and rely on a public gateway, it may be the best practice to simply delegate all CID conversion and subdomain creation to the router at dweb.link:

• ipfs://cid/path → https://dweb.link/ipfs/cid/path → correct subdomain
• ipns://example.com/path → https://dweb.link/ipns/example.com/path → correct subdomain

dweb.link also supports navigator.registerProtocolHandler (ipfs/kubo#7802), so one can simply encodeURIComponent('ipfs://cid/path') and pass it to go-ipfs directly:

• ipfs://cid/path → https://dweb.link/ipfs/?uri=ipfs%3A%2F%2Fcid%2Fpath → ... → correct subdomain
• ipns://example.com/path → https://dweb.link/ipns/?uri=ipns%3A%2F%2Fexample.com%2Fpath → ... → correct subdomain

[benhylau]

Opera fixed it right before we launched COMPOST :D
Try this in your Opera Android: ipns://one.compost.digital