Ipfs-companion: Feature Suggestion: normalize `href` and `src` with unhandled protocols

[bonds]

If you click on a normal HTML anchors that refer to an ipfs or ipns address, Firefox complains that it doesn't understand the protocol:

````
The address wasn’t understood

Firefox doesn’t know how to open this address, because one of the following protocols (ipns) isn’t associated with any program or is not allowed in this context.

You might need to install other software to open this address.

````
The world would be a better place if the ipfs-companion saw those (broken) links and turned them into links that work, i.e.

<a href="ipns://ggr.com/">my blog</a>

becomes

<a href="http:127.0.0.1:8080/ipns/ggr.com/">my blog</a>

That way people can start using ipns:// in their HTML anchors and their ipfs-companion equipped visitors will be able to follow those links and we can start living in the future right now.

[lidel]

Actually there is an experimental feature that enables basic support for ipns://ggr.com/ when user pastes it to location bar (it redirects to local/public gateway).
If you want to try it, you need to install beta version from developer channel and make sure it is enabled at the Preferences screen:

As for native protocol that is displayed in Location bar and can be used for loading site assets or clicking on links on pages :
we don't have API for that in WebExtension ecosystem, but feel free to subscribe to #164 where we track this effort.

PS. @bonds certificate for ggr.com expired today – you may want to renew it as soon as possible:

ggr.com uses an invalid security certificate.
The certificate expired on October 8, 2017, 3:53 PM. The current time is October 8, 2017, 8:55 PM.

[lidel]

Hm.. after giving it a thought I think I missed your point, sorry!

I agree, we should be able to detect use of dweb:, ipfs:// and ipns:// in HTML DOM and normalize href/src to point at resource within HTTP gateway.

Reopening.

[bonds]

Thanks for the note about ggr.com SSL cert, its now fixed. I've enable the experimental support for ipns:// and such, and it works fine when I type in an address into the address bar, but it does NOT work when clicking a link, at least, not for me. You can try it with the ipns link at the top of this page: https://ggr.com/ipfs.html

[lidel]

Hi @bonds, I've just released v2.0.12 with this feature.
Give it a try!

[bonds]

:) Tried it and it correctly converted the ipns URL at https://ggr.com/ipfs.html:

ipns://ggr.com -> https://ipfs.io/ipns/ggr.com

but when I clicked on the link, the Gateway Redirect sent me to:

http://127.0.0.1:8080/ipfs/QmPCawMTd7csXKf7QVr2B1QRDZxdPeWxtE4EpkDRYtJWty/ipns/ggr.com

which gave the error:

ipfs resolve -r /ipfs/QmPCawMTd7csXKf7QVr2B1QRDZxdPeWxtE4EpkDRYtJWty/ipns/ggr.com: no link named "ipns" under QmPCawMTd7csXKf7QVr2B1QRDZxdPeWxtE4EpkDRYtJWty
disabling Gateway Redirect avoids that problem and gets me to the public gateway with the correct path though, so...progress! :)

[lidel]

Ah, yes, it looks like a bug in 'dnslink' experiment. If you disable it, it should work fine.
Thanks for pointing it out! I'll add checks to avoid recursion when public gateway has dnslink itself.

[lidel]

@bonds how about v2.0.13 ?

(Note that ipns://ggr.com will still load from public gateway instead of custom one, because ipns lookup is broken due to https://github.com/ipfs/ipfs-companion/issues/288, but ipns://ipfs.git.sexy should work fine)

[bonds]

I don't notice a change in behaviour--an anchor for ipns://ggr.com still works if I disable dnslink support, and it is still is broken if I enable dnslink suppport, because I get redirected to http://127.0.0.1:8080/ipfs/QmPCawMTd7csXKf7QVr2B1QRDZxdPeWxtE4EpkDRYtJWty/ipns/ggr.com. ipns://ipfs.git.sexy works fine with dnslink both on and off.

Well, one change in behaviour actually...it no longer linkifies a plain-text

ipns://ggr.com

...perhaps THAT was the point...don't linkify if its going to be broken?

[lidel]

• plain-text will not be linkified if dnslink for a tested domain is broken (#228), we don't want false-positives, so this works as expected
• mentioned redirect should not happen anymore -- maybe its a stale cache in browser -- please close and open the browser&daemon and try again
• are you using Chrome? I've forgot to publish v2.0.13 to Chrome Store yesterday, it should be there in ~60mins.

Let me know if it helps.

[bonds]

* mentioned redirect should not happen anymore -- maybe its a stale
  cache in browser -- can close and open the browser&daemon and try
  again?

Confirmed--once I restarted Firefox it worked...no more broken redirect.
I noticed the modified date of ipfs-companion changed from 2017-10-10 to
2017-10-11, so perhaps I was just running the old version.

[lidel]

@bonds just a heads up: we are moving away from mutating DOM of every page for performance and stability reasons: https://github.com/ipfs-shipyard/ipfs-companion/pull/836

To make your blog future-proof it should be enough to rely on DNSLink and content-addressing alone.
If you want to use ipfs://, be aware most of the browsers won't be able to open it without additional software.

To maximize interop, I suggest use of public gateway links instead: those will get upgraded by ipfs-companion and future browsers with native support, while regular users will still be able to fetch content over HTTP.

If you need to use clickable ipfs://cid in a blog post, do it like this:

ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

<a href="https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi">
ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
</a>

It is the safest way right now.

[bonds]

Got it, thanks!

On Thu, Dec 12, 2019, at 8:35 AM, Marcin Rataj wrote:

@bonds https://github.com/bonds just a heads up: we are moving away from mutating DOM of every page for performance and stability reasons: #836 https://github.com/ipfs-shipyard/ipfs-companion/pull/836

To make your blog future-proof it should be enough to rely on DNSLink and content-addressing alone.
If you want to use ipfs://, be aware most of the browsers won't be able to open it without additional software.

To maximize interop, I suggest use of public gateway links instead: those will get upgraded by ipfs-companion and future browsers with native support, while regular users will still be able to fetch content over HTTP.

If you need to use clickable ipfs://cid in a blog post, do it like this:

ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/ipfs-shipyard/ipfs-companion/issues/286?email_source=notifications&email_token=AAANBORH4LQ4FF6N5CFO553QYJR5VA5CNFSM4D6DZCH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGXH3CQ#issuecomment-565083530, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAANBORWPAVB654FQRGOKRTQYJR5VANCNFSM4D6DZCHQ.