61–70 of 337 posts
I like IPFS, I really do, but whenever I try to use it, it's either too slow to become usable or sometimes it plain doesn't work. I pinned a whole bunch of files on IPFS a while back to experiment with it and the system seems to work, but every time I try to fetch those resources from a location that hasn't cached the content yet, it takes several seconds to show me the HTML/JSON/PNG files. HTTP may be inefficient fo…
IPFS needs to decide what it wants to be. Is it about being a decentralized caching layer? Is it about permanently storing content? Is it about replacing my web server? Is it about replacing DNS? Is it about censorship resistance? Right now it does none of those things well. The client chews through CPU and memory when seemingly doing nothing. If I try to download content, it is far slower than BitTorrent unless I go…
Earlier quoted context omitted.
Wonder if it's practical to "buffer" popular content on IPFS by copying it to normal HTTP servers. Requesting an IPFS document would query a few popular repositories, then revert back to normal IPFS if it's not found. These buffer servers would also track what's popular and shuffle around what they store accordingly.
I think this is exactly what Cloudflare's and ipfs.io's web proxies do. They won't cache your stuff forever, but they'll cache it as long as someone requests the content again before the content gets removed from cache. The downside of this approach is that it only works with popular nodes and you'd be back to the old, centralised internet architecture for all real use cases. I don't think you can accurately gauge wh…
"It stays in the cache as long as it stays in the cache"
??? What on earth does this mean?
The author claims that IPFS enables a "permanent web" and eliminates 404-like experiences. How does IPFS guarantee that all published content will be available forever? (In my beginner-level knowledge of IPFS, this is the first I've heard that claim. It seems absurd.)
I don't know about IPFS but Arweave solved the "permanent" part by asking nodes to periodically prove that they're actually storing what they're supposed to be storing: https://www.arweave.org/
IPFS needs to decide what it wants to be. Is it about being a decentralized caching layer? Is it about permanently storing content? Is it about replacing my web server? Is it about replacing DNS? Is it about censorship resistance? Right now it does none of those things well. The client chews through CPU and memory when seemingly doing nothing. If I try to download content, it is far slower than BitTorrent unless I go…
I like to explain it by comparing Amazon warehouses to the post office. Post office send black-box data point to to point. Amazon gets you thinggy matching SKU from arbitrary location.
Earlier quoted context omitted.
I think this is exactly what Cloudflare's and ipfs.io's web proxies do. They won't cache your stuff forever, but they'll cache it as long as someone requests the content again before the content gets removed from cache. The downside of this approach is that it only works with popular nodes and you'd be back to the old, centralised internet architecture for all real use cases. I don't think you can accurately gauge wh…
How much were you paying for your IPFS pin? E.g., if you are getting something via HTTP, there's a server somewhere with that content just waiting for you to request it, typically stored on an SSD, etc. V.s. IPFS pins which are typically packed on to massive disks shared with lots of other people IDK a whole lot about IPFS though. Maybe it was the metadata resolving / DHT lookup or whatever that was super slow. BitTo…
Paying for pinning sounds like something that could work but it would introduce some of the same problems that the real web suffers from back into IPFS. The idea "a web for the people, by the people" becomes problematic when you start paying people to make your content more accessible.
The author claims that IPFS enables a "permanent web" and eliminates 404-like experiences. How does IPFS guarantee that all published content will be available forever? (In my beginner-level knowledge of IPFS, this is the first I've heard that claim. It seems absurd.)
That said, IPFS isn't quite perfect here, as IPFS hashes do not actually point to the content itself, they point to a package that contains the content and depending on how that package was build, the hash will change.
> “With HTTP, you search for locations. With IPFS, you search for content.” Well, that's the difference between an URL and an URI, right? HTTP seems URL-oriented while IPFS seems URI-oriented.
Not quite. A URI is any identifier, a URL is a identifier to a location while a URN is identifier only containing a name. IPFS hashes are URIs/URNs while both URLs and URNs are URIs.
The author claims that IPFS enables a "permanent web" and eliminates 404-like experiences. How does IPFS guarantee that all published content will be available forever? (In my beginner-level knowledge of IPFS, this is the first I've heard that claim. It seems absurd.)
Basically with ipfs you try to download some content by referring to it by a hash. This means that the content will be available forever - as long as there is someone willing to cache that content. Which is, obviously, something that won't always happen. But it _can_ theoretically happen, so people with a cache of some old web page may revive it, even after the original site is gone.