does this mean that I (the website developer) can use any IPFS URI, and the user (browser) will retrieve the file from IPFS instead of from my HTTP server? How does this work on the client side, technically speaking? Does the user need to have a local running IPFS node, and the ipfs.js somehow magically connects to it?
js-ipfs is a complete implementation of the IPFS protocol in Javascript, made so it can work directly in the browser.
It achieves that by connecting to other js-ipfs peers with WebRTC, and to go-ipfs peers with spdy or websockets.
The user does not need a go-ipfs node running on their computer, but the js-ipfs node can peer with the go-ipfs node on the same host.
The downside is that it’s a 2.2MB file! Which is quite a lot. The size should be reduced, or it should all be embedded into some browser addon (webextension)…
FYI: I created a github issue related to martha1’s original questions in this thread. https://github.com/ipfs/js-ipfs/issues/710:Clarify purpose & status of js-ipfs in Readme & Roadmap
It is simple, the RFC spec says, if there is double slash after the schema definition (fs:), the next field is the authority that owns the resource under identification. It also defines that if there is just single slash after the schema definition then URI has no authority.
For example if we had URI fs://someauthority/ipfs/QmAAA the authority-less version of it would be fs:/ipfs/QmAAA. It has few consequences later on in applications.
