ipfs-download.js - a tool to make "IPFS Download" links try their best

[jbenet]

We've often discussed how to make it easy to download things with IPFS, particularly in the "almost all http" setting (eg a website served over http but that can serve js to a browser). Today I saw this archive: https://mcarchive.net/mods/ee which has "IPFS Download" buttons and figured that:

(1) it would be great if clicking that link would:

• try to use a local ipfs daemon to fetch things (local to the browser or the OS)
• fallback to try to use a js-ipfs node on the page to download p2p among the nodes on this site
• fallback to straight http from the ipfs gateway (in js)
• fallback to a regular https://ipfs.io/ipfs/... link in case the browser does not run js (and works with curl/wget archiving).

(2) we had a small library that did all of the above for users, so that users only had to include a js file and it would automagically try its best to download "ipfs links" with IPFS.

• where "ipfs link" is defined as: https?://ipfs.io/ip[fn]s/ or dweb://... or ipfs://... or fs:// ... etc. (we should make a short spec for this...)

<script src="https://ipfs.io/ipfs/<hash-of-lib>/ipfs-downloader.js"></script>

<!-- the ipfs-downloader.js above will:
 - intercept clicking these links 
   - if they're ipfs links
     - will try its best to use IPFS to download them
-->
<a href="https://ipfs.io/ipfs/<hash-of-dir-1>/file1">File 1</a>
<a href="https://ipfs.io/ipfs/<hash-of-dir-1>/file2">File 2</a>
<a href="https://ipfs.io/ipfs/<hash-of-dir-2>/file3">File 3</a>
<a href="https://ipfs.io/ipfs/<hash-of-file-4>">File 4</a>
<a href="https://ipfs.io/ipfs/<hash-of-dir-3/a/b/c/file5">File 5</a>

[jbenet]

cc @ipfs/javascript-team

[jonnycrunch]

The better way is using the URN notation approach rather than go thru a gateway. URN is a valid ( although i'm not sure how well supported in browsers) approach to linking. An example of a link would be:

\<a href="urn:ipfs:\<hash>">

rather than the gateway, i.e.:

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

This would require ipfs be submitted to iana a registered namespace, much like isbn is a registered urn namespace with iana, then submit the ipfs protocol to handle this namespace. see: https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml.

[victorb]

Another way would be to add a data-ipfs attribute to a and use that to "ipfsify" a download.

<a href="https://ipfs.io/ipfs/<hash-of-file-4>" data-ipfs>File 4</a>

Then the JS library would grab everything with data-ipfs attribute and intercept clicks.

try to use a local ipfs daemon to fetch things (local to the browser or the OS)

Don't think we can do this without folks running the daemon with a API that doesn't accept requests from that origin, which I'm not sure is a good idea.

Otherwise I think this is a amazing idea and would make it very easy for people to use js-ipfs to download things straight in the browser. One question that comes in mind is how to handle the download UI. If we're using js-ipfs, we need to either 1) hook that into the browsers download mechanism or 2) provide UI to show the download progress, since there won't be any loading indicator or such during the download.

[thisconnect]

There is examples of serviceworker catching requests to resources ending with .jpg, testing whether the browser accepts .webp and rewrites the request using .webp (that is when you know your backend servers webp).

I could imagine something similar ipfs links

[Kubuxu]

Can you link it?

[thisconnect]

That one I believe http://deanhume.com/home/blogpost/service-workers--dynamic-responsive-images-using-webp-images/10132 and the relevant gist https://gist.github.com/deanhume/c04478df744ce833925c#file-client-hints-service-worker-js

[thisconnect]

I have no experience but read occasionally about it. Afaik:

• service workers can intercept and manipulate fetch requests
• has access to cache storage
• a single service worker is used against a page, i.e. multiple windows/tabs of the same domain use the same service worker

http://caniuse.com/#search=service%20worker http://caniuse.com/#feat=sharedworkers https://jakearchibald.github.io/isserviceworkerready/ https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

[machawk1]

Robust Links (https://github.com/mementoweb/robustlinks) does something similar to what @VictorBjelkholm mentioned but annotates links with the data-versionurl and data-versiondate HTML attributes to direct a user to an archived source of the URI for the scenario where the href'd URI is long long available on the live Web.

As a caveat to @thisconnect's service worker idea, the initial scope dictates where the serviceWorker is applied. For example, if https://tripod.com/~someuser/mypage.html sets a service worker, the SW will not be run on anything outside of the scope of https://tripod.com/~someuser/. If a SW is set on https://tripod.com, it will also be run on https://tripod.com/~someuser/. SWs also run only on https* per https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API.

* localhost is also allowed for SWs but not useful here. We use a localhost SW in https://github.com/oduwsdl/ipwb to get around the https requirement.

[dokterbob]

Any updates on this?