3 ms·
> Reroute to your favorite ipfs provider. This sentence in a nutshell is why it does not exist. IPFS is a protocol, and as a way of bootstrapping it usage th
by georgyo 5y ago
> Reroute to your favorite ipfs provider.
This sentence in a nutshell is why it does not exist.
IPFS is a protocol, and as a way of bootstrapping it usage there are gateways (provider). When most people I interact with talk about IPFS they are using an HTTP gateway.
I am not on the chrome development team, but I imagine that if they were to implement IPFS, they would need to implement the entire protocol, not just call out to an unknown service. If it was just to a gateway, then sites should be providing their own gateways, mostly for billing purposes.
If everyone were to implement the full IPFS stack in their browsers (or even on their local computers) what is the lifespan of objects stored in cache? How does one prune it. A friend comes over and you go to a pirate video website to watch a movie, how long does that movie continue to get shared by your browser? How would you even know? -- Unlike bittorrent this is a pretty opaque process.
---
All that said, really the only real usage of IPFS in the browser is going to be js-ipfs. This handles many things like stop serving content from that site when the tab is closed. webtorrent handles many similar use cases as IPFS in the browser in the same ways.
js-ipfs also does not share content between tabs, which is a hurts the use case of IPFS; but people don't even want to use cdns for javascript because an attacker using timing can figure out if you already had some content cached to gain information about you.
While I like IPFS a lot, and even have a few demos of using it. I don't see how it can go mainstream.
---
It also seems like the IPFS team is not super interested in expanding true browser compatibility. The go-ipfs daemons cannot talk webrtc or wss(without a reverse proxy). And browsers can only talk webrtc or wss. Even with js-ipfs you can connect with relay nodes and other webrtc peers using the same signaling servers as you. So even using js-ipfs you are pretty much basically using a http gateway node in the browser.
I keep watching IPFS closely as it is extremely interesting and cool in concept, but it is not remotely ready for mainstream adoption yet.
- davidajackson 5y agoDo you feel that with IPFS using content hashes (CID v1, v2, etc) caching would be an easier problem to solve than fetching content that can change? I had thought IPFS would make this problem easier. And thanks for the detailed response, it has got me thinking about a lot.
- deleted 5y ago[deleted]
- DenseComet 5y agoWith IPFS, the client is not just a client, but an equal peer in the network. This is nice, but that means complexity. Compare that to something like HTTP 1.1, which is stupid simple to implement since complexity is pushed to the server. IPFS CIDs are easier than fetching decentralized content that can change, but harder than centralized content that can change.