Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pluggable ipns resolvers #3942

whyrusleeping opened this issue May 25, 2017 · 4 comments

pluggable ipns resolvers #3942

whyrusleeping opened this issue May 25, 2017 · 4 comments


Copy link

@whyrusleeping whyrusleeping commented May 25, 2017

I've been thinking about how to make it easy to add in new ipns resolvers to ipfs.

@llopv implemented a namecoin resolver here: ipfs/notes#41 (comment) and i'm thinking we can make it easier than hacking the namesys code.

My proposal is to have a config section for the resolver that could look something like:

"Ipns": {
  "Plugins": [
      "name": "namecoin",
      "match": "^*.bit$",

This would register a new ipns resolve called 'namecoin', and upon trying to resolve a name that matches the regex in 'match', would look for a binary at $IPFS_PATH/resolvers/ipns-namecoin and execute it with the argument of the name being resolved. The binary could return either just the resolved value, or maybe the value along with some extra information like a ttl

This way, users could write a (for example) namecoin resolver as a simple binary, and ipfs would require no modifications to be able to use it.

A lot of things for this need to be thought through, primarily security, and the implications of having different resolvers all over, people might end up passing ipns paths that others cant actually resolve.

Copy link

@ghost ghost commented May 25, 2017

I applaud the general push for pluggability 💯 I think a separate namespace a la /nmc would be a better fit.

I'm not sure it's gonna do us good adding more (and user-defined!) semantics to the /ipns namespace. The meaning of a path must be unambiguous. (Having dnslinks in /ipns is already not ideal.)

Copy link

@pors pors commented Sep 7, 2017

Sounds good @whyrusleeping! Making it pluggable makes it possible to have just a number of nodes to run some specific resolver. Implementing all "distributed DNS's" in the core code (as in the proof of concept you refer to), requires local access to a node of that specific “DNS-blockchain”, which is of course not feasible.

Since the IPNS system is implemented on top of the DHT, a couple of stable IPFS nodes with such a plugin could make sure that all nodes can resolve regardless of having the plugin.

Security can be solved like this I think:

Creating a record:

  • the owner of x.bit signs PeerID || x.bit
  • then the owner adds the above string + the signature into the .bit record as the value

Requesting a lookup:

  • an IPFS client asks for /nmc/x.bit
  • one of the nodes with the namecoin plugin retrieves the record and returns it via the DHT
  • the client who made the request can check (with the public key of PeerID) if the signature is correct and can subsequently request the content at /ipns/<PeerID>

I'm not a security expert, but I think this could work.

Copy link

@TUSF TUSF commented Sep 21, 2018

I was about to make a feature request related to this, but instead I'll just revive this issue, and give my input.

I'm thinking that this sort of feature could be added as a Plugin type. A "Resolver" type that takes a path/protocol, and returns a link to be resolved to the content. This could be handled in the way libp2p likes to handle protocols, and forward paths of the format /ipns/dns/ to a plugin that knows how to handle the dns protocol (the current DNSLink spec).

This can also handle something like /ipns/bit/domain for domain.bit, and /ipns/eth/domain for domain.eth, and hopefully other schemes. These could be handled by two different plugins that register the /ipns/bit/ and /ipns/eth/ protocols, or one that registers both. Such a plugin would follow the existing spec (if there is one) to resolve these domains to an IPFS address, and return it. This address may be further resolved if it can be.

Copy link

@ShadowJonathan ShadowJonathan commented Aug 14, 2020

Could this be governed by multiformats? So that /ipns/X/ prefixes don't differ per gateway, and instead a reasonable degree of interoperability could be expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.