You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.