dnslink:// URIs

[achingbrain]

Since #544 we have specs for ipfs:// and ipns:// URIs.

ipfs:// is quite straightforward but ipns:// has always had a weird wrinkle in that the authority could be something you can resolve using a routing query for the IPNS namespace, or a DNS query for a TXT record as defined by https://dnslink.dev/

These are not the same thing, you cannot resolve an IPNS Record using DNSLink, nor can you resolve a TXT record via a routing query for the IPNS namespace.

We can't even parse the authority in the same way leading to janky looking constructs like:

let authority

try {
  authority = parseAsPublicKeyHash(url.hostname)
  // hooray, it's probably an IPNS name
} catch {
  // what is it? lol I don't know, maybe it's a domain name?
  authority = parseAsDomainName(url.hostname)
}

Internally @helia/verified-fetch introduces a dnslink:// URL protocol which simplifies handling and Helia has long separated resolution into the comparatively heavyweight (in terms of dependencies) @helia/ipns and lightweight @helia/dnslink modules.

Perhaps DNSLink should be promoted to a first class citizen in the ecosystem and we should allow dnslink:// URIs alongside ipns:// and ipfs://?

[lidel]

FWIW some history on why this kept not happening:

1. DNSLink is glued to the /ipns/ namespace.
   URIs mirror content paths, and DNSLink has always lived under /ipns/ (very early go-ipfs had /dns/). We agreed to split the namespace back in 2018 (Feature request: add link type /dns/<domain name> notes#348: "/dnslink is the correct way forward"), and Add DNSLink specs for resolving /ipns/{fqdn} content paths #389 tracks the spec work. It never shipped: yearly Protocol Labs reorgs kept dissolving the teams that would have done it, and /ipns/{fqdn} already works everywhere. The rename touches every gateway, subdomain sandbox, and published link, so it is a lot of coordination across the stack. A dnslink:// scheme without a /dnslink/ path namespace under it adds new surface on top of the same ambiguity.

2. New schemes are hard to ship in browsers.
   ipfs and ipns got IANA provisional registrations in 2020 (Register URI with IANA in-web-browsers#29), specifically to unblock the registerProtocolHandler() safelist PR Update safelisted decentralized schemes for registerProtocolHandler() whatwg/html#5482. That PR is still open six years later, and some vendors moved from allowlist to denylist in the meantime, so it is unclear how much it matters now. The one mainstream native implementation deprecated ipfs:// in 2024 (Deprecate local node support and ipfs:// scheme brave/brave-browser#37735). dnslink:// is not IANA-registered, so it starts that race from zero, but the above is a blueprint if someone wants to pick this up.

3. Weak demand.
   A DNSLink name is already a valid https:// origin with real TLS. So the shipped UX has been: load https://{domain}, upgrade to IPFS in the background. Explicit addressing uses mutable ipns://{dnslink} (ADDRESSING.md, IPFS Addressing in Web Browsers, ipns://, and DNSLink in-web-browsers#118). The IPNS URI spec now defines the ordered parse you quoted, so the wrinkle is at least specified rather than folklore.

4. DNSLink never grew beyond IPFS.
   dnslink.dev aimed at an IPFS-agnostic standard, but the dnslink-std repos are archived and no outside community formed. In practice DNSLink means /ipns/{fqdn} plus the DNSLink gateway spec. Nobody needed/asked for a scheme independent of ipns:// and I've been around since 2018.

None of this says it can't happen. Point 1 is the real prerequisite, point 2 is the cost to weigh before adding a third scheme. To be honest, I don't expect DNSLink to be decoupled from /ipns/ with the people and funding the stack has today. But hopefully this context will save someone's time if that changes in the future.