Support for /api/v0/dns/

[lidel]

(I was unable to find this in code nor seen any discussion in Issues)

There is an API that returns dnslink value defined in TXT DNS record of arbitrary hostname.
I am using this API in Firefox addon for detecting if requests to a host can be loaded from IPFS instead of HTTP.

Not sure if this is a bug or a feature, but /api/v0/dns/ provided by go-ipfs is not supported by js-ipfs-api right now.

Is this on the roadmap?

Examples:

• http://127.0.0.1:5001/api/v0/dns/ipfs.io (dnslink present):
  {"Path":"/ipfs/QmaYRrBpZQRjonxBpBBSLvYmy893ySPpXpHCakhomaQtkU"}
• http://127.0.0.1:5001/api/v0/dns/google.com (no dnslink):
  {"Message":"Could not resolve name.","Code":0}

[daviddias]

It is simply missing. Wanna take a stab at implementing it?

[lidel]

:) before we go there, I need some clarification:

The relation between interface-ipfs-core and projects that implement it, such as js-ipfs and go-ipfs is confusing to me.
AFAIK /api/v0/dns/ is so far only implemented by go-ipfs but not present in interface-ipfs-core nor js-ipfs.

Shouldn't it be added to interface-ipfs-core first?

[daviddias]

Excellent question, I've been struggling myself on a way to clarify that better. First a bit of context:

• js-ipfs-api was initially a "commands library", more than a "api library"
• then we created js-ipfs and since the apps shouldn't have to worry which implementation to use, we created a standard interface to be applied, interface-ipfs-core
• we coalesced all the calls and tests of modules and created what you see today at interface-ipfs-core

Now what happens is:

• There are things that get added to js-ipfs and to go-ipfs that don't make sense in the other ecosystem. For example, we can't resolve DNS queries in the browser simply because it doesn't support it. There are many ways to 'fake it', but do we want to 'fake it if that means involving put more pieces on the network to support that?'??
• We don't want to stale development, for example, js-ipfs already has the DAG API finished, but we are still working to get the DAG API fully in go-ipfs feat: support DAG API #534 and js-ipfs-api

In conclusion, interface-ipfs-core should specify what makes a 'core implementation' of IPFS, everything else should be considered extra until it gets 'standardized/merged into core'.

[lidel]

Thank you for the insight on this.

AFAIK /api/v0/dns/ was created as a workaround for doing dnslink lookups in browser and browser addons (ipfs/kubo#1054, ipfs/ipfs-companion#44).

Now that I think about it, it makes little sense to support this API it in js-ipfs-api without having a working implementation in "browserified" version of js-ipfs.

We want to run and use embedded js-ipfs in WebExtension at some point (ipfs/ipfs-companion#248), which means js-ipfs should provide feature-parity with go-ipfs, namely support /api/v0/dns/ endpoint.

I would not add it to js-ipfs-api until js-ipfs provides implementation.
I created ipfs/js-ipfs#904 to track that effort, would appreciate your feedback there.

[daviddias]

Well, if we have to resort to DNS to do lookups, better just put those records on IPFS...

I believe that the million dollar question here is how the bit is the dataset containing every single domain and its TXT records in the world? And, given that we added all of those to IPFS, wouldn't IPNS + files sharding be a more efficient way to distribute them anyways? We can probably make DNS faster and more secure (and work offline!) if we distribute all of those records through IPNS + IPFS.

PS: Created a issue on ipfs/notes ipfs/notes#250