in-web-browsers

If we want it to be distributed across laymen, we need something easier than opening torrent files (or inputting magnet URI) over a thousand times. Perhaps https://github.com/ipfs/in-web-browsers?

As others have said, it's not as straightforward because the CID contains a hash of the data's encoding which is not the same as the data itself (files are chunked into pieces to facilitate incremental verifiability and better caching, the encoding supports directories, etc.). Here is IPFS's master issue for "verifiable gateway responses", which summarizes the technical challenges and progress: https://github.com/ipfs/in-web-browsers/issues/128.

There is an issue opened around supporting HTTP exchanges for IPFS in the browser as well. https://github.com/ipfs/in-web-browsers/issues/121

https://github.com/ipfs/in-web-browsers/issues/121#issuecomm... > Google Chome makes SXG indistinguishable from regular HTTPS, which breaks basic assumptions around how users understand the green padlock in location bar (aka "nobody but me and the Origin server can see the payload"). UX of regular HTTPS is reused as-is, pretending that end-to-end HTTPS transport was used with Origin from location bar, which is not true. https://blog.intelx.io/2019/04/15/a-new-type-of-http-client-... https://docs.google.com/document/d/1ha00dSGKmjoEh2mRiG8FIA5s... > Big changes need strong justification and support. This particular change is bigger than most and presents a number of challenges. The increased exposure to security problems and the unknown effects of this on power dynamics is significant enough that we have to regard this as harmful until more

One interesting use case for SXG is to allow decentralised and offline websites, since the site's data can be tied to a key/certificate/domain without having to be downloaded from a specific server. As an example, the IPFS project is already trialling the technology: https://github.com/ipfs/in-web-browsers/issues/121

Lidel has written a lot about this in issues (nice index here: https://github.com/ipfs/in-web-browsers/issues/147), but I think the live (recorded) demo will have to wait. =]

A known good entry point could be delivered over a content-addressed medium like IPFS, and if you layer on SXG the consumer might still be able to validate the origin of the entry point. https://docs.ipfs.io/guides/concepts/ https://github.com/ipfs/in-web-browsers/issues/121

Does it make sense to add support for Signed HTTP Exchanges (SXG) to this? https://github.com/ipfs/in-web-browsers/issues/121

You can do this if you have IPFS Companion installed. Eg: ipns://dist.ipfs.io => http://localhost:8080/ipns/dist.ipfs.io Firefox only as noted by devttyeu There is talk of adding signed HTTP exchanges (same thing AMP uses to achieve the same idea[0]), but with content hosted on IPFS[1]. Native support for this may land in Brave someday currently there is an effort around adding IPFS[2] [0] https://news.ycombinator.com/item?id=19678914 [1] https://github.com/ipfs/in-web-browsers/issues/121 [2] https://github.com/brave/brave-browser/issues/819#issuecomme...

So the discovery is currently via Bootstrap Peers and a Signaling server that can help connect peers together. A P2P network needs some way of bootstrapping and having a couple of stable peers for doing that is the simplest and works in most scenarios. But, it doesn't work in all scenarios. In the go-ipfs version of ipfs (or running js-ipfs) we can use mDNS for local discovery without any bootstraps, but unfortunately doesn't work in the browser (yet! FlyWeb would help https://github.com/ipfs/in-web-browsers/issues/45). Some sort of gossiping could work as well but we're always glad to hear other ideas of how we can make discovery work without having to hardcoded bootstrap nodes or signaling servers.

Actually there's been some movement regarding URLs :) You can check out the reasoning and plan here: [1] IPFS still has the long-term goal of path addressing (NURI), we just hadn't yet completely figured out what the upgrade path should look like. The discussion linked above is turning into a spec and into actions, i.e. IPFS will be trying to get as much as possible of Electron's protocol API [2] into WebExtensions, [3] and make us of that in the browser addons. [4] [1] https://github.com/ipfs/specs/pull/152#issuecomment-28462886... [2] https://electron.atom.io/docs/api/protocol/ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1271553 [4] https://github.com/ipfs/in-web-browsers