pluggable ipns resolvers

[whyrusleeping]

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.

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.)

[pors]

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.

[TUSF]

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/ipfs.io 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.

[ShadowJonathan]

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.