HTTP is obsolete – it's time for the distributed, permanent web (2015)
1–10 of 337 posts
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#2> “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.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#3I 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 for document storage, but IPFS is inefficient for almost everything else.
I like the concepts behind IPFS but it's simply not practical to use the system in its current form. I hope my issues will get resolved at some point but I can't shake the thought that it'll die a silent death like so many attempts to replace the internet before it.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#4> “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.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#5> All the static content stored with the site still loads, and my modern browser still renders the page (HTML, unlike HTTP, has excellent lasting power). But any links offsite or to dynamically served content are dead. For every weird example like this, there are countless examples of incredibly useful content that have also long since vanished.
Perhaps I missed it, but I don't see where they claim that IPFS can provide a solution for dynamic content; which makes up a huge portion of what is served over HTTP.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#6I 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…
I agree that the http caching layers are currently needed to achieve decent UX. But it’s also possible that won’t be necessary forever. The network could expand and get to the point where resolution time comes down to accessible levels. Only time will tell I suppose.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#7[deleted]
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#8Named-data networking is literally what this is describing, except NDN works as a replacement for TCP, not HTTP. In the long term I'd rather have it work at a lower level and not have to think about it much. https://www.youtube.com/watch?v=gqGEMQveoqg
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#9> All the static content stored with the site still loads, and my modern browser still renders the page (HTML, unlike HTTP, has excellent lasting power). But any links offsite or to dynamically served content are dead. For every weird example like this, there are countless examples of incredibly useful content that have also long since vanished. Perhaps I missed it, but I don't see where they claim that IPFS can prov…
It won't, but much of the web could work well on JAMStack, and there's no reason that couldn't be supported.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#10I 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…
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.