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

Open
whyrusleeping opened this Issue May 25, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@whyrusleeping
Member

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.

@lgierth

This comment has been minimized.

Show comment
Hide comment
@lgierth

lgierth May 25, 2017

Member

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

Member

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

@pors

This comment has been minimized.

Show comment
Hide comment
@pors

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

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.

@TUSF

This comment has been minimized.

Show comment
Hide comment
@TUSF

TUSF Sep 21, 2018

Contributor

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.

Contributor

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

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