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

Excessively recursive resolution when redirecting dnslink to local gateway in WebExtension version #298

Closed
lockedshadow opened this issue Oct 19, 2017 · 2 comments
Assignees
Labels
kind/discussion Topical discussion; usually not changes to codebase

Comments

@lockedshadow
Copy link

When we open a link pointing to DNS name that has a dnslink in TXT record (with DNSLINK Support enabled in Preferences), it causes redirection to value of this dnslink, although the preferred behaviour would be to keep the [readable] DNS name in the urlbar.

For example, http://dist.ipfs.io/go-ipfs/versions is redirected to [local_gateway]/ipfs/QmeqJJqSyNKt6d9SFRR1Rec6MNGJX6hdfnhUi2Bphec79Y/go-ipfs/versions, although one would expect redirecting to [local_gateway]/ipns/dist.ipfs.io/go-ipfs/versions instead. If we make a bookmark with such link, then we obviously will not be able to receive any updates!

On the other hand, always static IPFS links may be useful in (semi-)isolated network segments when we can not talk with whole IPFS network... but IPNS is especially designed for mutable content, right? And we expects that we will able to receive updates in the future using the same link.

@lidel
Copy link
Member

lidel commented Oct 19, 2017

This is a very good question! "Losing updates" is a big pain point.

DNSLINK experiment in v2.0.14 redirects to a value from TXT record (dnslink={value}). It can be either an immutable /ipfs/{cid} or a mutable /ipns/{peerid} (after ipfs/kubo#4293 is fixed 🙃 ).

I agree, from the UX perspective it makes sense to redirect to {local gateway}/ipns/{fqdn} instead and leave it up to the gateway to load the correct path from IPFS network "behind the scenes".

Pros

  • Clean URL that follows both IPNS and dnslink updates.

  • Greatly improved dnslink refresh time.
    Current implementation caches and re-uses dnslink value which introduces artificial delay in dnslink updates. This means browser extension will redirect to a cached path even if a new one is available in TXT record.
    Switching to /ipns/{fqdn} would remove this problem. Value cached by browser extension could be a simple boolean flag and actual up-to-date value would be looked up by go-ipfs.

Cons

  • ?

@lidel lidel added kind/discussion Topical discussion; usually not changes to codebase UX labels Oct 19, 2017
@lidel lidel added the help wanted Seeking public contribution on this issue label Oct 28, 2017
@lidel lidel self-assigned this Nov 6, 2017
@lidel lidel removed the help wanted Seeking public contribution on this issue label Nov 6, 2017
@lidel lidel closed this as completed in ba7cb53 Nov 6, 2017
@lidel
Copy link
Member

lidel commented Nov 8, 2017

@lockedshadow I've just released v2.0.15rc1 with this change, feel free to give it a try :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/discussion Topical discussion; usually not changes to codebase
Projects
None yet
Development

No branches or pull requests

2 participants