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 through a centralized gateway. If I add content it takes ages to propagate, making it utterly unsuitable as a replacement for a web server. There is no system to keep content alive so links will still die. The name system is byzantine and I don't think anyone uses it.
Unfortunately, they are now unable to pivot because they did that asinine ICO. The right thing to do is to give up on the FileCoin nonsense and build a system that solves a problem better than anything else, but that is no longer allowed because they already sold something else to their "investors"
Point being, they didn't just bite these pieces off randomly: they see a picture of how the internet _could_ work, and they're trying to realize it. If they can get it working, then boom! You have decentralized internet, and you also have a ton of bonuses that just fall out from this being the right way to do things: resistance to censorship, better archiving, reduced influence of web megacorps, etc. But you have to have it -all- to actually be better. The sum is WAY greater than the parts.
The trouble is, this statement:
> Right now it does none of those things well.
is true.
So I get what you're saying. To build user-adoption, they need to find a way to deliver an improved experience, not just an improved model that would be better if more people used it. But I object to the idea that the solution is to choose one of those things at the exclusion of the others. The whole idea doesn't make sense if they choose one. If I were advising them, I wouldn't tell them to reduce their scope in terms of "doing all the things", but rather reduce their scope in terms of doing all the things for the entire internet. They should find some kind of sub-network or community that gets extra value out of the decentralization, and prove out the concept there. Maybe it's a big company's intranet, or a network of (paging ARPA) universities?
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.
To me this should be a separate codebase. And I see this in other features they have been including too.
I'm using IPFS quite heavily to store content generated on https://pollinations.ai but there is no way I could run it without a centralized node that I have control over at the moment because otherwise it would just be painfully slow and unusable.
I love the idea of content addressed decentralized data. I have no real use for IPNS at the moment and many of the other features of the core IPFS stack.
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.
Anyone can register a lot of fake “seeder” for a file chunk making it hard to download that chunk.
Same problem for the name server.
If you want to use the Filecoin network as a "provider of last resort" for IPFS data, there's https://estuary.tech which will mark your data as verified, sort out the deals with storage providers, and then mirror it to IPFS.
There's also third-party tools like https://fission.codes/ , https://docs.textile.io/powergate/ , https://web3.storage/ and https://www.pinata.cloud/ for making this easier.
(Disclosure: I work at the Filecoin Foundation.)
We were looking at this at work the other day.
We noticed the storage price vs S3 saying "0.03% the cost of Amazon S3" and then someone (who's been trying to get adequate performance out of IPFS for a while) said "0.03% of the price, and even lower performance".
The modern, more economic web, wouldn't come until Netscape added form fields and cookies, at the behest of some of the original owners. And there were a ton of people at Netscape making these decisions about their vision of the future of the web. In-browser music listening wouldn't come until Macromedia, Disney and Microsoft pushed their vision for a "multi-media web"; browsers wouldn't build native support until much, much later.
So yes, we absolutely decided what the web would be about, and built technology to match that vision.
- A simple system, designed from scratch, sometimes works.
- Some complex systems actually work.
- A complex system that works is invariably found to have evolved from a simple system that works.
- A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
Systemantics, John Gall, 1978
1. The web succeeded but many things whose backers made similar comparisons failed. Knowing that one technology had a big impact doesn’t say that a given unproven technology will be the next one to go big. It’s more likely that you’re looking at the next Groove Networks or something like that.
2. The web was immediately useful for many people and you could get started easily. IPFS has some interesting but far from unique properties and trying to be a network increases the amount of adoption and maturity needed for it to be worth using for most people. This is especially true for peer-to-peer sharing where the most useful participation requires up-front risk and costs which many people aren’t going to want to accept. Without that, it’s basically just harder to use web hosting which may or may not be cheaper.
I can't see the future. I can, however, look at the world and think about what I see.
The Web was a hit because it was really obviously useful for real work from the moment of its creation. IPFS is BitTorrent with magnet: links, and the seeding problems that implies, and the rest is janky nonsense.
The web was fast (for documents on 56k) and extremely useful almost immediately. It was obvious to everyone watching that the technology was going to change everything.
"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?"
websites at the beginning did not decide to be a caching layer - they decided to be websites. they did decide to permanently store content. they did decide to use web servers. they did not decide to replace dns. they did decide to be about censorship resistance.
now imagine you put up a website, put some time into it, and it may or may not be up at a random time in the future. not a product that's usable.
Torrent trackers solved this in a very interesting way. They created an economic system where bandwidth was the currency, incentivizing the permanent seeding of content. It was illegal to take more than you gave. I've even seen an academic paper studying their system!
Bandwidth as a currency eventually proved to be a failure. It enabled the rise of seedboxes, dedicated servers featuring terabytes of storage and connections to high capacity network links. Just like the IPFS centralized gateways you mentioned. They would eventually monopolize all seeding, removing any normal person's ability to gain currency. In some trackers, if you wanted to consume content, your only options were renting one of these seedboxes or uploading new content to the tracker. You always stood to gain at least as much bandwidth as the size of the content you uploaded. The seedboxes would monitor recent uploads and instantly download your new content from you so that they could undercut you. I suppose it was a form of market speculation.
They also failed to realize that there is no uploading without downloading. By penalizing leechers economically, they disincentivized downloading. This led to users being choosier: instead of downloading what they like, they'd download more popular stuff that's likely to provide higher bandwidth returns on their investment. Obscure content seeders would not see much business, so to speak, due to the low demand for the data. Users would stock up on popular and freeleech content so they could get any spare change they could. The more users did this, the less each individual user would get. Then seedboxes came and left them with nearly nothing.
This was eventually solved by incentivizing what was truly important: redundancy. Trackers created "bonus points" awarded to seeders of content every hour they spent seeding, regardless of how much data they actually uploaded to other users. These points can be traded for bandwidth. This incentivized users to keep data available at all times, increasing the number of redundant copies in the swarm. People will seed even the most obscure content for years and years. In some trackers, these rewards were inversely proportional to the amount of seeders: you made more when there were fewer seeders. This encouraged people to actively find these poorly seeded torrents and provide redundancy for them.
We can learn from this. People should be compensated somehow for providing data redundancy: keeping data stored on their disks, and allowing the software to copy it over the network to anyone who needs it. The data could even be encrypted, there's no reason people even need to know what it is. Perhaps a cryptocurrency could find decent application here. Isn't there a filecoin? Not sure how it works.
I'm not sure why everyone assumes that bittorrent was about currency. It wasn't, and that was its superpower. No matter how much you were able to contribute, you were able to strengthen its system, redundancy and availability.
The only problem bittorrent had in practice was a legal one that finally led to a problem of availability of discovery.
All that filecoin hype will lead to only one thing, and one thing only: the people that are popular will decide what files are worth to the system, and the masses will simply dump everything else and forget about it.
Add an inflation for every modification of any file in the whole system, and you have a perfect way to destroy real incentives.
I don't believe in most web3 projects because they always think it's about trading files with each other. It is not. Discovery and access to data should not be limited by your financial capability to buy things. The internet exploded because people got access to vast amounts of knowledge, for basically free compared to before.
Reminds me of maker incentives in markets. Providing liquidity is sometimes paid for.
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.
Decentralized tech doesn't work well until the network effects build up.
IPFS has the interesting quality that the more popular a piece of content is, the easier it is to get ahold of. If millions of people were using IPFS, the most popular content would be being served by many thousands of people, and finding it and downloading it would be extremely fast. Then subsequent viewings would be instantaneous because you can cache it for life.
This leaves interesting incentives for monetizing pinning and caching for less popular content.
It makes sense if you ask me. If I love a piece of music so much that I'm willing to give it to others for free then everyone benefits from being able to access it easier.
Content that people care about organically becomes more resilient and nearly impossible to remove.
Content that no one cares about is slow and inefficient because it has to be hauled out of cold storage the one time a year anyone cares.
If someone thinks that content is more important than people are giving it credit for they can host it or pay for someone else to do it.
If you have a website and you have "fans" that subscribe to you and help pin all your stuff, then your stuff becomes faster and easier to get. Your "fans" can even get paid for helping to serve your content.
So, to me, it's early days for IPFS, and the way to make it better is to try to build apps that increase its usage, so the power of the network effects is felt.
That sounds like the worst of the current internet, but even worse
I remember popcorntime was as responsive as Netflix at the time it came out and it scared the shit out of the MPAA so they killed it with prejudice.
IPFS doesn’t have an excuse for sucking beyond a basic lack of engineering effort.
...then IPFS would just get even slower and use even more resources to manage the index and find content as I am pretty sure the DHT they are using doesn't scale the way you seem to think it does.
This interesting given your description:
> IPFS has the interesting quality that the more popular a piece of content is, the easier it is to get ahold of. If millions of people were using IPFS, the most popular content would be being served by many thousands of people, and finding it and downloading it would be extremely fast.
This idea hasn’t been new since the turn of the century (BitTorrent offered exactly that in 2001) and nothing in that description explains why this is different than the many previous attempts. It’d be interesting to hear about how IPFS plans to maintain that without the problems with abuse and how it keeps competitive performance relative to non-P2P in a world where things like CDNs are much cheaper and easily available than they were around the turn of the century. Using P2P means giving up a lot of control for the content provider and that’s a challenge both from the perspective of the types of content offered and the ability to update or otherwise support it on your schedule.
Except that most people outside tech would probably be using phones/tablets/crappy pcs, with upload speed that is 10% of their download speed.
So niche content is difficult to get a hold of?
Sounds like a bad idea.
It launched in Feb 2015.
Things that have launched since then:
The idea of Donald Trump as President of the USA
TikTok
Covid-19
Tesla Model 3
OpenAI
It's entirely possible that everything could change any day now. It's equally plausible that it's just a bad implementation of a decent idea, and something similar could come along and deliver on its promise.
You criticize that people have unrealistic expectation, and then you are making an unrealistic claim...
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.
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 what is and isn't popular in a P2P network like IPFS. You never have a view of the entire network, after all.
There's also the problem of running such a system. Who pays for the system's upkeep and do we trust them? If we'd use Cloudflare's excellent features, who says Cloudflare won't intentionally uncache a post criticising their centralisation of the internet, forcing the views they disagree with to the slow net while the views they agree with get served blazingly fast.
I don't think such a system would work well if we intend to keep the decentralised nature of IPFS alive. Explicit caching leads to centralization, that's the exact reason caching works.
Instead, the entire network needs a performance boost. I don't know where the performance challenges in IPFS lie, but I'm sure there's ways to improve the system. Getting more people to run and use IPFS would obviously work, but then you'd still only be caching only popular content.
Edit: actually, I don't really want to see caching happen through popularity of the service either, because as it stands IPFS essentially shares your entire browsing history with the world by either requesting documents in plain text or even caching the documents you've just read. I wonder if that IPFS-through-Tor section on their website ever got filled in, because the last few times I've checked that was just a placeholder in their documentation.
I guess the approach would be to simply run IPFS on those servers, with the popular content in it, as a seed.
That's good enough for kicking off batch file transfers (assuming you mean P2P networks like BitTorrent), but there's no evidence that people will tolerate a slow web, and lots of evidence that they won't.
The main challenge for me with this comment is that you can't expect distributed/decentralized networks to win if you set an expectation that "things will just be slower than the normal web". Nobody is going to migrate to that.
ipfs cat /ipfs/QmQPeNsJPyVWPFDVHb77w8G42Fvo15z4bG2X8D2GhfbSXc/readmeDHTs just aren't a good choice for massive data systems if you need low latency.
I've just pinned a 12MiB file filled with random bytes on one of my servers (`dd if=/dev/urandom of=test.dat bs=1M count=12; ipfs add test.dat; ipfs pin <hash that came out>`). The server has a 50mbps uplink, so transferring the file to my laptop should take about two seconds.
Dumping this blog's contents over IPFS takes the server about 3 seconds (first time load) so the network seems to be in working order, at least when downloading data. `ipfs swarm peers` lists about 800 known peers. On the server itself, `ipfs cat /ipfs/redacted > /tmp/test.dat` runs in about a second, which is all perfectly acceptable overhead for a transfer that'll take two to three seconds anyway.
On my laptop, I've tried to get the file but I just cancelled it after waiting for 16 minutes. Halfway throughout the wait, I've tried opening the file through the ipfs.io proxy, which finally gave me the file after a few minutes, but no such luck yet if I retry the ipfs command.
I don't know if it's the random file, the size, or something different, but if I'm launching a blog or publishing documents on IPFS, visitors should not be expected to wait five to ten minutes for the data to load. "After the first twenty visitors it'll get faster" is not a solution to this problem, because there won't be twenty visitors to help the network cache my content.
Maybe I'm expecting too much here; maybe the files shouldn't be expected to be available within half an hour, or before Cloudflare caches it. Maybe there's something wrong with my laptop's setup (I haven't done any port forwarding and I'm behind a firewall). Either way, if I follow the manual but can still buy a domain, set up DNS and hosting on my VPS and send a link to a friend faster than I can get the file through P2P, I don't think IPFS will ever get off the ground. Fifteen minutes is an awful lot of time for a data transfer these days!
Edit: actually, now it seems ipfs.io and cloudflare have picked up the file in their caches. Data transfer is up to normal speed now. If you want to try to replicate my experiment, I've just uploaded a new test file to /ipfs/QmbBD872kjfoutAmTKFCxTCApw9LBB9qxxRyXpEGYzsqMH.
Edit 2: I realized that by saying I downloaded the file and that the file is random, I just announced my personal IP address to the world through the IPFS hash, so I removed it. That was pretty dumb of me, and also a pretty clear problem of IPFS in my book.
(...)
real 0m0.219s
Even torrents take 1-10 seconds to initiate downloads with an absolutely massive network.
Will the network be faster the more people join it?
Is centralized infra inevitable for fast things because of all assumptions and insight a centralized provider can use? BTC is also slow, I don't know of any cryptocurrency that can provide VISA transaction volumes, even if they use more power than some countries alone.
Do we need all that comes with IPFS? Not just technically, but the user training and pivot of technical doers?
So many of these projects feel like programmer vanity projects, there’s really little difference between them and a guy on the corner telling me why Protestants are wrong, join his flock.
That it’s a technical project not entirely ephemeral nonsense doesn’t matter; solutions exist already we just don’t implement that way.
Honestly, I like IPFS as a tech, and blockchain isn't useless, but the entire community just makes me want to puke because it's full of so many extremely ignorant people (at best), but mostly just fraudulent liars (at worse and most common).
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 address will die, or worse will start showing some unrelated content (probably domain-squatter spam). That cannot be prevented by making a copy on my hard drive (or even the Wayback Machine).
On the other hand, an IPFS version will continue to exist at the same address for as long as anyone is seeding it. All links will remain working; anyone can join in the hosting if they like; even if it eventually stops getting seeded, it may still re-appear if someone re-inserts it, e.g. if they insert the contents an old hard drive they found in an attic (as long as the same hash algorithm is used, then the address will stay the same).
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.
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 IPFS worked acceptably, even if it worked as very narrowly promised, plenty of stuff would fall off the web. At best, we'd see somewhat fewer temporary disruptions of very currently popular content.
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
A big problem in the NFT space of late is that OpenSea sells NFTs that link to an IPFS URL, then doesn't bother seeding the image after it's sold - so a pile of NFT images no longer exist anywhere on the IPFS.
https://www.vice.com/en/article/pkdj79/peoples-expensive-nft...
You also gotta look into the smart contract code and see if baseURI an IPFS link or someone's proprietary website.
If you can specify "I've got 1gb spare to replicate other people's assets, as long as each of them replicates mine in return" then your incentive to replicate other people's sites is more redundancy and bandwidth for your own.
If you also prioritise files that have the least replicas across the entire network, and allow servers to re-distribute the content they are replicating, it would surely become quite hard for a file to be lost forever.
This makes more sense to me than having each site pay for their own data to be replicated, because those who don't pay don't get their content replicated, which results in missing content when the server eventually disappears. That is just as bad as HTTP.
I have no idea how hard this would be to implement. I'm new to ipfs and crypto.
Example: I'd love to use one of these projects as an additional backup layer for my NAS, but the technical complexity necessary to set it all up makes it.. feel very fragile. Definitely not set and forget.
My hope is that in 10 years something cool comes out of one of these projects, but we're definitely not there yet.
Post office send black-box data point to to point. Amazon gets you thinggy matching SKU from arbitrary location.
It's most like I think we should nationalize the Amazon warehouse system and put under the post office.
Perhaps both are valid interpretations of the US constitution's postal clause, "To establish Post Offices and post Roads" even!
I do think there is a natural monopoly, but that is just and argument for nationalizing things. (And agreements like there being one IP protocol or whatever.)
Odysee is looking into adding crypto to your balance when you serve content that helps viewers.
The min hardware specs are absurdly large. Most of the services required are not prepackaged alum any way, the exercise is left to the implementer for almost everything.
If you don’t have 100k+ to drop in hardware, there’s no community help for you.
It’s a shame because ipfs is well structured from the other end, but it’s not really decentralized in any way other than naming.
As with all crypto tech, its insanely inefficient and you may as well use google drive or s3.
It's interesting how the same people promoting the "creator economy" also tend to promote the cryptocurrency space and IPFS without an ounce of self-awareness. IPFS sounds awful for creators of all kinds in the same way as BitTorrent was awful for artists. I can definitely see a use case for IPFS as a file storage for trustless systems such as smart contracts, which are designed as immutable, trustless systems.
But IPFS has the crypto problem of conflating the stuff that works now with the stuff that's hypothetical in its marketing, and not admitting that the latter is janky nonsense that doesn't bloody work.
You could use all the current web/http/DNS infrastructure, and add certified/cacheable GET results.
Anyone could run their own proxy and cache what they see fit. Seems like an easier transition as it could be fully compatible with the current web.
Well, that's the difference between an URL and an URI, right? HTTP seems URL-oriented while IPFS seems URI-oriented.
URL - Uniform Resource Locator
URN - Uniform Resource Name
URI - Uniform Resource Identifier
IPFS is a CAS (Content Addressable Storage), so an "Identifier" there is a semantic key (i.e. hash of the content).
Like, if I’m talking to someone over some chat setup which doesn’t have a built in “send this file directly to this person” feature, it would be nice to be able to say, give them a multihash of the file and my external ipv6 address (+ port? I’m not quite sure how routing works), and have them request the file from my computer.
Now, you might say “but how does that help with the situation where a bunch of people in a room want the same file from a distant location?”.
And, maybe it doesn’t as much? But I think if e.g. people on a local network had theirs try first if the local network already had it, and then check the given external address, that that could work?
I’m somewhat surprised that I hadn’t heard of the ni scheme before tonight.
Is there some nice software (can be cmd only, but ideally multi-platform) to do that where both parties are on separate residential connections, and where the receiving party side software automatically checks that the received data matches the hash?
Because if so, that seems to serve exactly the purpose I’m thinking of!
Thank you for the direction
> give them a multihash
magnet URIs
> place to request data from
trackers
> try local network first
Already baked in!
So, sounds like I ought to learn to use bit torrent.
p2p no huge IP infrastructure between nodes
interest packets at narrow waist (like human attention, scarce)
sign all packets, more secure, easier to trust|not
hash for pointers, no surprises in containers
crypto apply more cryptography, less web3 baloney
broadcast radio native, no emulation of copper wire
data, closer to where you want, find faster, keep
content you want w/out intermediation, need to find "where" within IP/udp/tcp addresses
https://youtu.be/P-GN-pYfRoo?t=1825 node to node
https://youtu.be/yLGzGK4c-ws?t=4817 more application, less security hassle
http://youtu.be/uvnP-_R-RYA?t=3018 hash name the data
https://youtu.be/gqGEMQveoqg&t=3006 data integrity w/out need to trust foreign server
I was tipped off to https://twitter.com/_John_Handel/status/1443925299394134016 which I honestly think might be the approach to think about how networks in a broader sense than regular telecommunications are bootstrapped.
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.
It's also brutal for battery life.
* https://docs.ipfs.io/install/command-line/#official-distribu...
Single pre-compiled binary, no dependencies. Starting it is just a matter of:
ipfs daemon
Another useful command on Linux:
ipfs mount
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 they should be as easy to install as most applications on Android or Apple. Bitcoin began becoming popular when easy to use wallet applications and currency exchange began being mainstream. Same for BitTorrent, Signal and IRC.
The distributed part is still going strong, but in my eyes distributed (or decentralization) should be a tool, not a goal.
The question is which kind of Internet we want to build with these distributed infrastructure? If it's just cloning the current Internet, then I don't see what it brings.
My personal answer is that we should build a democratic Internet. One where people are members of the Internet, instead of mere users, and decisions are made in a democratic process, like in a state. This kind of Internet can only be implemented using the distributed/decentralized tools.
I think it's so bad that so much of the Internet information is siloed in walled gardens and that pages have to be dynamically generated and routed across the globe every single time... Imagine how it's gonna be when we get to Mars, for instance. Storing this knowledge graph in IPFS files seems like a logical step to me (as an absolute layman, though)
It's a long road though, with lots of negotiations with lots of organizations. I do feel optimistic about it though.
If I want to “save” some data in FileCoin/IPFS/whatever, and I want it there forever, is it cheap? Expensive? Can I be reasonably sure it stays there?
I want some actual current results, not “one day in the future”, heard that too much from *Coin proponents
> The service is temporarily limited to users wanting to store meaningful public data. You can apply for an invite →
so… no?
> Enough space to store the current Lotus chain (preferably on an SSD storage medium). The chain grows at approximately 38 GiB per day. The chain can be synced from trusted state snapshots and compacted or pruned to a minimum size of around 33Gib. The full history was around 10TiB in June of 2021.
Ugh. OK I will pass then
HTTP is simple and works, what ever you do build on top of HTTP instead of TCP/UDP.
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
Like this IPFS, you'd connect to a hub (IPFS calls this a node) and get what people were sharing. This IPFS only takes that step a little further with hashing and distributing. Also, if this gets implemented widely, hash collision is going to be wild
It's reasonable to try again at the bigger goals now that there's more infrastructure / theoretical progress / audience.
https://ipfs.io/ipns/QmTodvhq9CUS9hH8rirt4YmihxJKZ5tYez8PtDm... https://ipfs.io/ipns/ipfs.git.sexy/
The title shows clearly that they were wrong.
Let's assume all goes well and in 2-5-20 years IPFS is the web. A random Joe has an IPFS server in his basement, because it's profitable or at least convenient for him. Most of the traffic never reaches AWS or CouldFlare. What do they do about it? They pretend to be random Joes and mirror the same setup.
Obviously Amazon will manage their servers more efficiently than an army of Joes, so the nothing really changes: we end up with a decentralized protocol where 90% of traffic just happens to end up on AWS servers anyway.
Tell that to all of the content creators, corporate or not.
A lot of website hacking could've been avoided with a better design like even having encryption as standard.
But that would be a very different web from today's, where most content comes from dynamic CMS/CMF, blog software, forum software, or other web apps. It addresses things like the old personal homepage of the mid-90s, but not much at all about the modern web.
It also doesn't address the major outages (like we've seen with cert revocations or DNS outages, etc.)
It's like the invention of personal computers. It's going to change everything like the shift from time share department computers did. Imagine what programmers could do if YouTube size infrastructure was free for every developer. IPFS is just the boring protocol the enables the next internet of stuff. The stuff that comes out in the next 20 years will be crazy.
So definitely not permanent, right?
Whether HTTP or IPFS, you want content:
(1) hosted/stored redundantly enough for availability but not over-hosted/stored because that raises costs.
(2) hosted “near” to requesters to make efficient use of the network, which limits costs and increases speed. (Near in terms of the network infrastructure.)
With HTTP I understand how this works (the content publisher figures out a hosting solution balancing what they are willing/able to pay and what kind of availability and speed they want/need).
Not sure with IPFS though. If people are choosing what to host, wouldn’t the hosting be uneven, with some content under-hosted (or not hosted at all) and some popular content greatly over-hosted? …leading to an inefficient system? Under—hosted content would be slow to retrieve or simply unavailable. Over-hosted content is wasting resources, making the system more costly than it needs to be (somebody is paying for the storage and servers to make that storage available).
I realize this a alpha/experimental, but without a strong answer to this, I don’t see how the system can work at scale.
I read the docs and tutorials but no luck. Felt like docs were missing some special incantation or setup step, or precondition. Or the CLI wasnt giving me feedback on some blocking error, and it was failing silently. Dunno. Gave up. Hope to revisit some day. Because in theory it would be useful tech to have in my toolbox.
Of interest: they provide a trustless way to store your data encrypted data on centralised boxes (S3, Backblaze) if you want.
search for content = it presumes that there's a google-like indexing of content, and then a DNS-like way to retrieve it.
It seems to me that IPFS, in this analogy, is simply a different way to address a web page / document.
note: I am very familiar with IPFS. I just think that this analogy is really poor.
The thing is that the web by its nature is already decentralised. The real issue with the web today isn't really some technical, architectural flaw.
Centralisation has emerged in this already reasonably well decentralised system because of network effect driven accumulation, the market and pre-existing wealth from investors tipping the scales.
Yes IPFS is a more thorough attempt to create a distributed web, yet I doubt it is fully immune to the forces that captured and centralised the existing web, except for the fact that it is currently unpopular. Or it will remain unpopular because there's no incentive for private enterprises to invest much in a system where they can't control their own corner of it and few users like using systems built on the cheap when flashy, well funded alternatives exist, if it is truly that resilient to centralisation. Whichever way you want to slice it.
The social forces that cause centralisation in the web are the same forces that cause e.g. monopoly and extreme wealth accrual in the rest of society. And the fix has to be social, not technical.
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".
The problem is that it isn’t unique enough from the existing experience and the problems it claims to solve aren’t something non technical people care about. Web distribution in its current form works. Even if it’s supremely shitty grandma can still post photos on Facebook.
If a new distribution format wants to win it needs to be different in a way an 8 year old and grandma can equally understand. IPFS is not that. What 8 year olds and grandma equally understand is that content is king, the layman term for client/server model.
More likely the future will purely be a focus on web technologies for application experiences and distribution. Kill the client/server model. If grandma wants to share photos with grandkids she doesn’t need Facebook at all. She only needs a network, a silent distribution/security model, and the right application interface. No server, no cloud, no third party required.
Start with a description of the solution. If you can't cover it in 1-2 paragraphs at the beginning, you are in trouble. Don't focus so much on what everyone else is doing wrong - focus on what you are doing and let others be the judge of whether this is better.
Well, we’re all dependent on the Internet which can be shut down at any time by any government, and normally almost completely dependent on FAANG companies.
I applaud the freedom activist spirit but the only exciting technologies in this regard must be P2P and not Internet carried.
Before iPhone, peer 2 peer tech were doing OK. Then mobile broadband came, and centralized services basically won.
Now we (at least in some places) have mobile broadband of symmetrical 50-100 mbit/sec, yet p2p still doesn't work on mobile. Despite the bandwidth is now good, electricity and thermals still aren't.
EDIT: It seems [1] they want you to encrypt content and do access control outside of ipfs. Imagine ext4 telling you to do acl's on your own. To me, it is a little more than bittorrent without acls and at-rest confidentiality built-in.
I think that’s what happening in the storage market, again, with IPFS.
(Sadly I don't keep the links anymore to prove it. It was somewhere in one of their GitHub repos however, inside an issue.)
I'd love to support them but they don't stand behind their "uncensorable" original slogan.
Neocities is implementing IPFS – distributed, permanent web - https://news.ycombinator.com/item?id=10187555 - Sept 2015 (235 comments)
See this is the part I always doubted. I haven’t done the math, but does it really scale up to the size of the internet?
That didn’t age well …
Arweave seems to be another approach to the problem.