Live data from Hacker News

HTTP is obsolete – it's time for the distributed, permanent web (2015)

ipfs.io

271–280 of 337 posts

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#271

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…

IPFS's design makes it so that it's all of those things, or none of them. Picking one of them doesn't fit the shape of the technology. IPFS is basically the answer to the question "what is the RIGHT way to decentralize the web?". If you think about that question hard enough, then anyone can see that their way of doing it is the "right" way. It's just obvious. The problem is that all of these mutually supporting compo…

The problem is their goal isn't to do these things well by the usual metrics, it's to do them using a decentralised implementation. It's the implementation model that is the product, not rapid replication, not fast access, not long term access to data, not large scale storage.

The problem is that their architecture by it's nature takes all the quality related qualifiers out of those goals. Replication, but not rapid, access but not fast, access to data but not long term or actually resilient, storage but not large scale. So it's only advantage is if you value decentralisation above all other characteristics.

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#272
post #269
post #268

Earlier quoted context omitted.

It might seem like it at first, but P2P always needs a peer finder, and that should be HTTP. I predict that in a relatively short timespan everyone will host a HTTP server on their port 80 atleast those that can get an external IPv4 address before the cost starts surging. The point is: port 80 is and should be open. When you do other ports and protocols you never know what the IPS/router/firewall/OS is going to block…

Expecting a server on an external port is already quite limited, plenty users that can't do that for various reasons. Bittorrent also doesn't use HTTP for the P2P parts.

Sure, and that is the real battle, who can get an external IP!

Yep, I'm ok with the P2P stuff to be over UDP, but if you ever made UDP hole-punching work you will realize it's not necessarily the most straight forward solution.

P2P does not scale for all problems, while distributed client/server does!

The bottleneck never was network bandwidth (binary vs. text), it's been atomic parallelism since multi-core processors peaked in concurrent RAM bandwidth 2014+ after DDR4 increased latency.

Copying files is not a problem because you can always make files smaller by reducing quality!

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#273
post #270

Earlier quoted context omitted.

IPFS's design makes it so that it's all of those things, or none of them. Picking one of them doesn't fit the shape of the technology. IPFS is basically the answer to the question "what is the RIGHT way to decentralize the web?". If you think about that question hard enough, then anyone can see that their way of doing it is the "right" way. It's just obvious. The problem is that all of these mutually supporting compo…

> IPFS is basically the answer to the question "what is the RIGHT way to decentralize the web?" There is no RIGHT way to decentralize the web. I don't think IPFS is the right way to do it either. Tim Berners-Lee's Solid ( https://solid.mit.edu/ ) offers a much more practical path to a decentralized web. The advantages with Solid's approach over IPFS is that: Solid doesn't throw out what we already have, and recommend…

What is that simpler protocol?

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#274

Earlier quoted context omitted.

> suddenly all of that traffic is hitting nodes with far fewer resources. One of the points of IPFS (and bittorrent before it) is that this is not a problem; each node that downloads the data also uploads it to other nodes, so having lots of traffic actually makes it easier to serve something (indeed, if it was already widely seeded by Google's mirror, there wouldn't be any sudden traffic).

I'm not particularly familiar with IPFS: does it have some solution for free-riding? BitTorrent as many have noted is great for popular things, even not-particularly-popular things, but absent incentives to continue seeding (i.e. private trackers' ratio requirements) even once-popular things easily become inaccessible as the majority of peers don't seed for long, or at all. I guess what I don't quite is what IPFS add…

> I guess what I don't quite is what IPFS adds vs. say, a trackerless BitTorrent magnet link that uses DHT?

Beats me! I think there might be support for finding new versions of things, but I'm not sure about the details or how it prevents authors from memory-holing stuff by saying "The new version is $(cat /dev/null), bye!".

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#275
post #85

Earlier quoted context omitted.

Command line client can be found over at: * https://docs.ipfs.io/install/command-line/#official-distribu... Single pre-compiled binary, no dependencies. Starting it is just a matter of: ipfs daemon WebUI will show up at: * http://127.0.0.1:5001/webui Another useful command on Linux: ipfs mount This make IPFS available as fuse filesystem in the directory /ipfs/, so you can directly access IPFS content without manually…

You are missing the point. Less than 5% of people are what most people would describe as coders and from my experience, I would say less than a third of those are not afraid of using a terminal. Why do you think people still pay for IDEs and fancy git clients with a UI? And of that, only a tiny fraction would have heard of decentralized social media / websites. If these kind of projects want any global attention then…

GUI options to use it exist. You can use IPFS via the IPFS Desktop client or just use the Brave browser which has support for it build in. That said, if you want to actually host anything on IPFS yourself, you need the CLI client so you can throw it on a Raspberry Pi or something.

Anyway, I think the much bigger problem to IPFS adaption is that IPFS barely works. In terms of features IPFS should be capable of replacing every single mirror server out there, but in reality nobody is doing that. Having run IPFS permanently in the background also uses way more CPU than is acceptable for a software that is mostly just idling around. And the 'ipfs mount' option completely fails to scale with bigger directories. IPFS also has a serious lack of support for encryption and privacy, everything you do on IPFS is essentially public. Search is another thing missing on IPFS, https://ipfs-search.com/ exists, but if you try use it, 95% of the results are non-working links.

IPFS isn't really at a point where you want average users to use it, they'd just be disappointed and uninstall it immediately again. But if you want to play with it, it's really nothing more than a few clicks away. It is already pretty easy to use right now, no matter if GUI or CLI. Even with nothing installed or configured you can still use the proxy server that make IPFS available by HTTP.

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#276
post #270

Earlier quoted context omitted.

> IPFS is basically the answer to the question "what is the RIGHT way to decentralize the web?" There is no RIGHT way to decentralize the web. I don't think IPFS is the right way to do it either. Tim Berners-Lee's Solid ( https://solid.mit.edu/ ) offers a much more practical path to a decentralized web. The advantages with Solid's approach over IPFS is that: Solid doesn't throw out what we already have, and recommend…

What is that simpler protocol?

I'll do a Show HN in a month.

Although a reference implementation (https://github.com/webpods-org/podmaster) is kind of ready, there's no documentation yet (which will go up on webpods.org soon).

The only way to see the feature-set is to look at some of the tests. https://github.com/webpods-org/podmaster/blob/master/src/tes...

If you're interested, please email me. I'm looking for collaborators.

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#277

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.)

It's the fundamental lie of IPFS. IPFS people will jump in and say that it's not a lie, what they're actually saying is yadda yadda , but then they turn around and say exactly that five minutes later. It's the motte-and-bailey ( https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy ) of IPFS. In a world of finite storage, nobody's going to keep up a copy of everything. Nobody will have a copy of most things. Even if…

Yeah in the article there is an example of a video that was downloaded multiple times. That is so inefficient because "HTTP".

Solution for it becoming more efficient is that someone else should host it for you ideally for free.

It is just exercise in throwing big numbers and utter ignorance to impress people but downloaded megabytes are not magically going away.

Just like torrents - no one wants to seed or pay hosting costs everyone wants to download. There is no protocol that is going to fix that. Why is everyone mining BTC like crazy, because they get money for that

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#278

Earlier quoted context omitted.

> Yes, it could still exist on your private node that your running from your laptop, but this is the equivalent of saying that all published content is available forever because it's on your hard drive. No, the difference is that IPFS will use the same address to fetch content from anyone who's seeding it. If Hacker News shuts down, it will no longer be accessible at 'news.ycombinator.com'; all existing links to that…

> On the other hand, an IPFS version will continue to exist at the same address for as long as anyone is seeding it. I wonder how that would work, a naive direct translation seems impractical. An address identifies an exact piece of content, so a hacker news article gets a new adress every time a comment is added?

pulling things out the ether my guess is that during normal operation news.ycombinator.com constantly creates and propagates new content ids as new comments are added (the front page simply fetches the newest ids, and there is a system for querying for updated ids which simulate how browser refresh works now), if news.ycombinator.com dies it becomes impossible to create new ids or post comments, but all already propagated pieces of contents are still accessible (possibly refresh still works on outdated content).

This is just a guess, though.

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#279
post #108
post #47

I'll just point to the millions of torrent files today that will remain unseeded forever. Durability with P2P only works as a complement to centralization.

I think streaming is killing torrents and the fact that you need a VPN in many countries to avoid getting fined

torrents needs to be available over a browser interface to hide in the usual https traffic

Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)

#280
post #276

Earlier quoted context omitted.

What is that simpler protocol?

I'll do a Show HN in a month. Although a reference implementation ( https://github.com/webpods-org/podmaster ) is kind of ready, there's no documentation yet (which will go up on webpods.org soon). The only way to see the feature-set is to look at some of the tests. https://github.com/webpods-org/podmaster/blob/master/src/tes... If you're interested, please email me. I'm looking for collaborators.

I tried to use Solid, but having a protocol to store your data did not seem very useful without being able to swap the applications that use them at will. Each application needs to understand not only the Solid protocol, but the format you are using for your data too.

The specification naively says that the data is saved in interoperable formats. Sure, you can store your data in an interoperable data formats, suppose it is JSON, but it is of little use if the various applications do not know how to interpret and manage correctly the information contained therein.

It's been a while, have the applications improved?

Post reply on HN