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
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.
The text was updated successfully, but these errors were encountered:
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.
When we open a link pointing to DNS name that has a
dnslink
in TXT record (withDNSLINK 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.
The text was updated successfully, but these errors were encountered: