Contribute to Open Source. Search issue labels to find the right project for you!

pluggable ipns resolvers

ipfs/go-ipfs

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

@llopv implemented a namecoin resolver here: https://github.com/ipfs/notes/issues/41#issuecomment-304115810 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: json "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.

Updated 25/05/2017 22:24 1 Comments

/ipns/ should redirect to /ipfs/ and/or cache

ipfs/go-ipfs

<!– Output From ipfs version --all –>

Version information:

go-ipfs version: 0.4.3-
Repo version: 4
System version: amd64/linux
Golang version: go1.7

<!– Bug, Feature, Enhancement, Etc –>

Type: Feature

<!– One of following: Critical - System crash, application panic. High - The main functionality of the application does not work, API breakage, repo format breakage, etc. Medium - A non-essential functionality does not work, performance issues, etc. Low - An optional functionality does not work. Very Low - Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release. –>

Severity: Medium (performance issue)

Description:

Currently, /ipfs/ request have maximal caching implemented, which is great for performance as it allows offloading load to caches (reverse proxies, Cloudflare, browser, etc). The /ipns/ are mutable, so the same treatment would not work. Currently, they don’t provide any form of caching, making every request go all the way back to the (comparatively slow) origin node.

Addendum:

There is currently a very low severity bug in the handling of the If-None-Match header for /ipns/ requests. It is incorrectly handled like the /ipfs/ requests, and returns 304 Not Modified if set to the ipns base name, even though the content may have changed. This is very low severity since /ipns/ never sets an ETag header to begin with.

Proposal:

I propose to implement the following:

  • On /ipns/ requests always set the ETag to the current /ipfs/ base name.

  • If the request contains a If-None-Match header, check the ETag and reply with 304 Not Modified if appropriate.

  • Add a configuration option GateWayconfig.IpnsRedirect bool.

  • If the boolean is set, reply to /ipns/ requests with a 307 redirect to the current /ipfs/ path and include a header for 5 minute caching. (ipns updates, AFAIK, have no global consistency guarantees, so this should not hurt. Even a slight caching header can be the difference between 10k requests per second and 1 request per minute.)

  • If the boolean is not set, reply as before, but also include the ETag header described above.

Relevant prior discussions:

Redirection has been mentioned earlier in issue 132:

  • should use relative 302 (or 303/307) redirects for resolving /ipns -> /ipfs

Issue 132 is closed, but this particular feature is currently not implemented. In issue 1234 it was suggested again, but at least one user had a problem with it in the context of dns links (something I don’t understand).

Questions:
  • Does the config option make sense or is it too much and can I always enable redirects?
  • Should the redirect cache duration be configurable? What is a good default?
  • Is there a reason this is not implemented yet that I should know of?
  • How does this affect dns link?
Updated 18/04/2017 10:28 5 Comments

Ipns very slow

ipfs/go-ipfs

Hi, is it normal, that ipns loading very slow? I tried to make something like cms with dynamic content, but ipns to slow, when i load site via ipns, first loading is very slow, if after that i reload page it’s load quickly. But if i reload after few minutes, it’s again load slow.

Updated 21/06/2017 19:31 18 Comments

namesys: IPNS/DNS resolution is very slow

ipfs/go-ipfs

While checking performance I discovered that namesys introduces 400x to 5000x increased latency. See: IPFS path:

IPNS path:

I did hard refresh so e-tag and in browser caching shouldn’t matter.

Complete load requires almost 40x more time to complete under IPNS. I can repeat those results easily. You can also try for your self: fs:/ipns/ipfs.io and fs:/ipfs/QmTzQ1JRkWErjk39mryYw2WVaphAZNAREyMchXzYQ7c15n/

Updated 08/05/2017 03:20 6 Comments

Fork me on GitHub