261–270 of 337 posts
The idea on how a decentralized web of hypertext documents should be done right isn't exactly new. AFAIK the fact that in the HTTP+HTML web stack, servers going down meant documents disappearing and links going stale was criticized even at the time. The HTTP+HTML stack winning out is probably one of the many examples of "good enough" winning over "perfect".
Earlier quoted context omitted.
And quite annoyingly, it's the opposite of how IPFS works. IPFS nodes only cache the content as long as it's actively requested. Depending on the cache policy of the node, this can be as short as 24 hours. 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 . Honestly, I…
> 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…
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?
Earlier quoted context omitted.
Why ? iirc the time I studied them, DHTs scale pretty well (like log(size of the network) complexity for everything).
log(size of the network) still means it gets slower as it gets larger without any aforementioned speed advantages for all but the IPFS Google popularity equivalent class content.
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…
If nobody pins a link it disappears but there is no strong incentive it just rides on abundant space and bandwidth and wealthy Gen Xers that want to be a part of something
The same group released filecoin which experiments with digital asset incentives.. and venture capital
Inconclusive results
HTTP is simple and works, what ever you do build on top of HTTP instead of TCP/UDP.
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…
I have a slight issue with the title, why not IPFS over HTTP? Why are all these entites (both corporate and not) trying to deprecate the main protocol used by humans? HTTP is simple and works, what ever you do build on top of HTTP instead of TCP/UDP.
I have a slight issue with the title, why not IPFS over HTTP? Why are all these entites (both corporate and not) trying to deprecate the main protocol used by humans? HTTP is simple and works, what ever you do build on top of HTTP instead of TCP/UDP.
HTTP would be an odd choice for a dynamic peer-to-peer protocol like IPFS.
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.
But if IPv6 ever reaches inertial mass you are right!
Edit: As far as IPFS is concerned we allready have bittorrent and that uses HTTP so their point is moot, I'm driving another tangent though:
Everything that can be HTTP, should be HTTP; and to proove it I made the most scalable multiplayer protocol: http://fuse.rupy.se/about.html
Earlier quoted context omitted.
HTTP would be an odd choice for a dynamic peer-to-peer protocol like IPFS.
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…
Bittorrent also doesn't use HTTP for the P2P parts.
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…
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 a new layer on top of the internet (example: ipns).
Solid handles access control which pretty much every application needs (encryption is btw, a poor substitute for access control).
Solid has the ability to revoke access, and delete data (very important).
It can work in browsers without extensions.
Solid is not muddied with talk of the Blockchain. It's disappointing that cryptocurrency has very nearly hijacked this space.
Solid is conceptually simple. You own a pod that has a unique address (using familiar schemes). You put your stuff on it and allow access to people; like DropBox but standards based. Companies can offer paid hosting services to run your pod - more space, bandwidth etc.
IPFS is not commercialization friendly. IPFS performance is unlikely to be great, ever.
Disclosure: I am invested in an open protocol similar to Solid, but simpler. So not entirely unbiased.