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.
Do 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.
With 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.
Probably because they don't see an important business case for it. Like everyone else, Google has limited resources and an enormous laundry list of business priorities around Chrome that involve all sorts of functionality besides IPFS. These include device compatibility, media capabilities, updates to the various HTML/CSS specifications, JavaScript and other automation functionality, etc. Then there's the never-ending list of bugs to be fixed.
You can, of course, try your hand at adding it yourself, or persuade others to add it - the core (Chromium) is open-source, after all. You can also try to assemble a critical mass of customers to persuade Google to add it.
(I'm sure you didn't mean it that way, but this post comes off as somewhat entitled, as though Google is your personal engineering team.)
Got it, yeah I wonder if Google will lose customers to Brave :) It just seems like low hanging fruit. But I understand about other features. And writing from a genuine point of curiosity, not trying to sound entitled.
Google may or may not lose users to Brave but on the macro level it won't be because of a niche protocol that most non-technical people associate with child porn and darknet drug markets, if they have heard of it at all.
It's not really in entrenched interests to implement IPFS. They lose a control/injection point.
For example, YouTube without the ability to log who's watching what, when, and without the ability to inject ads. Same for TikTok/Facebook/etc..
Walled gardens, even those with gently sloped walls, have few reasons to cultivate the wild beyond their control. Except maybe to show users outside the way into their garden.
If Brave already does what you want, why not use it? Safari is my primary browser, but sometimes I have to fall back to Firefox or Chrome because reasons. :-)
Are there any real websites using IPFS at the moment? Anything I find is usually a tech demo that takes a minute to load.
IPFS could be what hypertext was for the web, meaning that anyone can self-host their own stuff, but so far it’s been used exclusively for storing NFTs.
i asked for a google analytics feature 10 years ago. it has been upvoted like 500 times now. nothing ever happened. then they put some lipstick on that thing and made it even less useful and i moved on to getclicky.
Maybe, but it wouldn't be as good for content creators who want their content to be sharable. Curious if you find an answer though. Right know you can reference IPFS with a 3rd party provider like ipfs.io/... but it's not ideal for long term permanence if that metadata is on a chain.
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.