I’ve recently just stumbled across this new technology. I just wanted to get some views on whether this had the potential to completely replace HTTP ?
Whether this had the potential to completely replace HTTP?
Short answer, NO.
IPFS has the potential to replace HTTP in immutable content delivering areas, like file download, web resource loading. But can not replace HTTP in areas where the same HTTP request may return dynamic contents.
@chrisijoyah yes, the goal of IPFS is to eventually completely replace HTTP.
@kehao95 you’re completely wrong, please don’t give answers that sound authoritative and definitive if you should know better – there’s multiple good ways of achieving dynamic content. IPNS is one, PubSub is one, CRDTs are one, OrbitDB is one.
PeerPad is a recent example of an application that combines PubSub and CRDTs.
Chill man,
I knew all of the ways of serving dynamic contents you’ve mentioned, the PubSub, the CRDTs and the OribitDB.
I think when you say some tech A will completely replace some tech B, that A should not only cover almost all the functionalities of B’s but also does it better. And tech A will never replace tech B when there exist some aspects tech A cannot solve them better.[1]
For example, you can almost safely say that HTTPS will replace HTTP, for everything works on HTTP works on HTTPS. But you can’t say that with IPFS&HTTP.
HTTP and IPFS are totally two different things. They are designed for different purposes and will perform different roles in modern internet.
I apologize for not get it very clear about ‘the dynamic’ of the HTTP. What I really mean was HTTP is a very flexible protocol for it leave the processing logic to the backend servers. So the HTTP can almost return anything.
For an immutable HTTP request:
- it can return the static resources
- it can return arbitrary redirects
- it can return personalized user’s data with the help of the cookies
- it can return different versions of libraries while changing of time
- it can perform A/B test so different users get different contents
- it can get the stats and do traffic analysis.
- it can do load balancing
- …
Moreover, there are many techs builds on HTTP like RESTful, GraphQL, etc.
All these can happen due to the design principles of HTTP. So what about a totally new tech with totally different design principles?
Can IPFS replace HTTP in all the aspects above?
Maybe.
Not likely.
IPFS don’t have to.
I don’t think it will ever happen.
That’s why I gave the answer NO.
The good news is that I believe IPFS has the potential to replace HTTP in certain areas, especially in static content delivering. IPFS is much better in every aspect under this narrow topic. It will be a great success for ipfs just solving this issue.[2]
[1]. Most of the time, a little better is never enough, it must be much better before people are willing to make a change.
[2]. We should have learned from history, no matter how advance a new tech is, it will take it a great long time to replace the old ones. eg: Python2 vs Python3, HTTP vs HTTPS.
Telling one of the core devs of IPFS what IPFS was and wasn’t designed for is an interesting approach to take.
I don’t think anyone is saying that IPFS is a drop-in replacement for HTTP websites; it seems pretty clear there would need to be at least some work involved. The question was whether the IPFS protocol has the potential to replace HTTP.
None of the answers to your own question really lead to a “no”, so it’s still hard to see why that would be the “short answer”. Your answers sound a lot more like they lead to a “maybe” or “I don’t think so” – unless your position is that if you can’t think of a way to do something then it’s not possible.
I don’t want to have a fight here. I answered ‘NO’ and gave a short explanation. @lgierth pointed out that I sound authoritative. So I apologized and gave a detailed explanation of why I believe IPFS will not replace HTTP.
If you still don’t agree, I have nothing more to address, and I still hold my belief. I think we’d better invite a core dev to this thread to discuss if the ipfs project is aiming to replace HTTP completely or we are just focusing on replacing HTTP in content delivering area as described in the white paper.
@whyrusleeping @lidel
If the discussion is too of the thread, I’d suggest close it.
In his talks @jbenet mentioned several times that the IPFS can eventually be a replacement for HTTP, and since he’s the original developer, I currently see no reason to believe otherwise.