Implementation suggestion

cloutier commented 8 years ago

I stumbled upon this and it made me think:

 <script src="ipfs.js"></script>
 <img src="//failover.com/tree.jpg" ipfs="QmbhfRQtxEdWN2HzwQveahspuMaRcMT6cUMk1t38omKDQT" />

With the multihash automatically translated to the integrity tag syntax. It would provide graceful degradation if no connection to ipfs can be found (from maybe a "fascist" firewall or if javascript is disabled) with the same content integrity check and it will be futurproofed for when ipfs will be integrated directly into every browser! :grin:

jbenet commented 8 years ago

yep! :smile: would be a great way to integrate now

harlantwood commented 8 years ago

Very cool. Could do almost exactly the same for links + CSS tags + anything referencing an external resource.

We could also generalize it so it could use other protocols... eg:

... hash="ipfs:QmbhfRQtxEdWN2HzwQveahspuMaRcMT6cUMk1t38omKDQT" ...

Not sure if there is much benefit, just throwing out out there.

cloutier commented 8 years ago

@harlantwood We could also make use of multihashes to make it protocol agnostic.

... multihash="QmbhfRQtxEdWN2HzwQveahspuMaRcMT6cUMk1t38omKDQT" ...

I think I like the ipfs tag slightly more though.

@jbenet Is there someone working on this? This is something I've been thinking of building for ipfs.pics. I think I have read that webRTC is not yet implemented in go-ipfs, but I could make it fetch content over http and store it in html5 local storage for now and work on the rest when it is ready.

jbenet commented 8 years ago

note: a hash in ipfs is the hash of the dag that represents the file, not just the file. so the hashes here will be different in non-ipfs things. this is ok if the js file included is ipfs-aware, but not if it's just multihash aware.

This may be ok if the path has the full: /ipfs/<hash>/... construction, as the /ipfs prefix denotes the protocol. So, strictly for subresource integrity using ipfs:

... integrity-ipfs="/ipfs/..." ...
... x-integrity="/ipfs/..." ...

or something.

Also, note that "failover" is the goal of the https://ipfs.io service. the goal was to allow:

<script src="ipfs.js"></script> <!--- or even without this line in browsers natively with ipfs -->
<img src="//ipfs.io/ipfs/QmbhfRQtxEdWN2HzwQveahspuMaRcMT6cUMk1t38omKDQT/tree-in-cosmos.jpg" />

to be used everywhere, and then:

if ipfs.js exists and works (or the browser natively implements ipfs), halt load, and load using ipfs, removing the //ipfs.io prefix
if not, just use the http link as is.
the ipfs.js impl could -- if fetched from http -- construct the objects and check all the hashes clientside too.
a page could also override the gateway: ipfs.globalGateway = 'https://ipfs.pics' and rewrite the https://ipfs.io links.

This enables all the subresource integrity stuff without needing a different attribute.

We're prepared to handle load on the https://ipfs.io service -- it hasn't been a problem yet. if it's slow we can see about improving it or directly connecting it to popular webapps.

@jbenet Is there someone working on this?

@cloutier not yet! go for it! but let's maybe craft a full plan before starting-- would be good to pull in same direction.

think I have read that webRTC is not yet implemented in go-ipfs,

we could start on that effort again, using something like https://github.com/xhs/librtcdc -- seems to have some use. we could also implement websockets as a transport today :)

but I could make it fetch content over http and store it in html5 local storage for now and work on the rest when it is ready.

sounds good to me. you can use the ipfs.io gateway for all this. we should be able to take the load.

davidar commented 8 years ago

note: a hash in ipfs is the hash of the dag that represents the file, not just the file. so the hashes here will be different in non-ipfs things.

It would nice if there was a system for converting between ipfs hashes and "normal" hashes, since this issue has come up a few times in other contexts.

jbenet commented 8 years ago

we could include the "final hash of the data" in the attributes of a unixfs file

On Sun, Dec 6, 2015 at 12:13 AM David A Roberts notifications@github.com wrote:

note: a hash in ipfs is the hash of the dag that represents the file, not just the file. so the hashes here will be different in non-ipfs things.

It would nice if there was a system for converting between ipfs hashes and "normal" hashes, since this issue has come up a few times in other contexts.

— Reply to this email directly or view it on GitHub https://github.com/ipfs/ipfs.js/issues/1#issuecomment-162285972.

kenCode-de commented 7 years ago

Has anyone published an IPFS Chrome Extension yet that will allow non-geeks to surf IPFS based websites? For example, in the address bar she just pastes: ipfs/hash...

daviddias commented 6 years ago

Check out http://github.com/ipfs-shipyard/ipfs-companion for the Web Extension and http://github.com/ipfs/js-ipfs for the JS implementation.

ipfs-inactive / ipfs.js

Implementation suggestion #1