The Internet needs the InterPlanetary File System
spectrum.ieee.org
spectrum.ieee.org
TLDR: people whose salary depends on selling IPFS think everyone needs IPFS
If you could actually pay once to have a file stored forever, that would be useful. "Perpetual care" for data would be valuable. There are Filecoin people who will take your money to do that, but don't have the credibility.
Now, if Berenberg Bank (private bankers since 1590 and still a substantial bank) managed the funding for this, it might be credible. One of the things they do is handle money on the scale of centuries.
Kind of important to point out this isn't in and of itself saying they are incorrect or lying. A carrot farmer may promote the health benefit of vegetables without nefarious intent.
It also has the problem of not enough people use it.
But the basic principle of a content-addressed, distributed file system is desperately needed, and there is a lot of work going on behind the scenes from both protocol labs and others to fix these problems...
Stay tuned :-)
With IPFS, you know "it's just a hash of the content". That idea of content addressing is pretty powerful, and I'm starting to see it a lot more, particularly in the NixOS ecosystem.
IPNS, on the other hand, seldom worked. The 24hr timeout made it unusable without an abstraction on top that kept it up to date. Dat had a similar problem, one of storing way too much historical data, and I could never be sure if the peers had the same version I las published.
I think these are "theoretical problems". Content addressing is a great idea and it's reliable. Distributed hash tables are on the weaker technology spectrum. I'm rooting for IPFS to replace bittorrent, not IPNS/Hypercore, which I think will have serious scalability/security /privacy problems.
e.g. I'm Joe Rogan and I release all my podcasts into a single torrent, add one each podcast. JoeRoganPodcastArchive.torrent . Each addition should propagate if the torrent client accepts it (i.e. Joe can't sneak in a episode of Oprah as the user would catch that).
Debian_amd64_ISO_Archive.torrent , each release Debian chuck it in there. Up to the user to accept the new addition (likewise download selectively, as can be done already).
By now you should get the drift of what I'm on about. The key is you don't have to get another torrent file to "follow" (what would be) the expanding torrent.
It also serves to propagate new content faster, the change comes to the user rather than the user having to seek it out.
That sort of thing in a totally unrelated sort of comment tends to be a huge dogwhistle.
But I clearly just want you to “discriminate” against the wealthy middle aged male white asshole. (Disclosure, I’m a middle class middle aged white male asshole)
As mentioned by another person, IPNS does solve this issue, though. My domains are pointed to an IPFS+IPNS-published version of my site, which is re-published on change from Github.
And not to beat a dead horse, but IPNS doesn't work very well. These days people tend to build their own naming systems using layers of IPLD hashes instead.
The fact that you have some extra names on top of that doesn't change the base system.
If your address is a function of a public key, then you're using "agent key addressing."
Naming things continues to be one of the hard problems in computer science.
I think that's a fine road to go down for addressing data, but it's not content addressing.
What is actually the difference in any way that matters? What property does content addressing have that this doesn't.
Also not like this was an ipfs innovation. Magnet links (bit torrent and predessor file sharing p2p), freenet, etc all significantly predate ipfs
Arweave is leagues better: I use it all the time to store articles I've written and very precious media. It couldn't be easier to use with its browser extension. It's also very cheap for true file permanence forever at least until all the storage nodes die out but given replication stands at some absurd multiplier there's little chance of it.
And as far as centralization, you've got a Pareto distribution, no network topology can change that.
Explain for the more obtuse among us?
For example, go to TPB and look at the distribution of seeders/leechers.
Protocol Labs people always sell “Filecoin” as solution to IPFS shortcomings… but it isn’t, really. Filecoin is an entirely separate network where you pay for both retrieval and storage. And you need big contraptions to use those two together in any way. It isn’t made to be used together at all.
(Full disclosure, I work for the Filecoin Foundation for the Decentralized Web, which is certainly part of the wider IPFS Cinematic Universe.)
So you would say I have 16TB, feel free to use it as you see fit swarm. I can "mine" crypto by helping the swarm.
The swarm benefits from a gigantic pool of storage and content.
ISPs and government agencies can't do anything because it's all anonymous and any individual person is sharing encrypted pieces of a file anyways.
It would need to be over Tor or similar, which is of course way slower. Otherwise there's nothing preventing "ISPs and government agencies" from going after people sharing copyrighted bits.
Perhaps both have some point; however, I don't see it really necessary at all for a very useful and thriving project to benefit from something like IPFS.
Case in point - DVC.
You don't need financial incentive for people to store ML models / weights on their computers - they need to use them there anyway. It makes great sense that the more popular the model, the faster it should load from more nodes serving you, rather than waiting for things to be downloaded from the one server the authors put it on (that will probably be deleted in a year or so anyway).
Note that there is no (happy to be corrected) publicly available IPFS implementation that can be run reasonably anonymous. Trying to tunnel kubo (go-ipfs) over Tor or other proxies will break stuff. There's also a bunch of fingerprinting that is not possible to disable without modifying source.
The answer to HA IPFS seems to be "just run more nodes". I am yet to speak with someone who has tried and reached success with load-balancing IPFS using available load balancers.
Same thing has been said about BitTorrent and Tor.
And yet governments have been able to de-anonymize file sharers.
https://blog.torproject.org/bittorrent-over-tor-isnt-good-id...
The problem is that cryptocurrency mining is about producing verifiable proofs. I don't know how you would go about producing a proof that you've helped the swarm in a decentralized, sybil-proof way.
(Disclosure: I am working on the project)
Dont get me wrong I like IPFS and would love to see increased usage but if a libgen mirror is the biggest example then we need to find more applications for it.
Unlike with torrents, most people will be using the “gateways” - most people are not “seeding” - partly because IPFS itself is resource hungry and hard to use, unlike Torrent which is easy to use.
In reality IPFS world is very centralized, you just have this resource hungry pretend-decentralisation on top.
I don’t know why is it like that when BitTorrent is much older and much more actually decentralised.
The way BitTorrent fixed this was the ratio - if you weren't seeding enough, you'd eventually get kicked out from the tracker. Does IPFS have a similar mechanism, or something else but with the same purpose?
At my previous company actyx.com we wrote our own ipfs implementation in rust called ipfs-embed ( https://github.com/ipfs-rust/ipfs-embed ) that serves as the storage for our distributed event sourcing system. It is used in production and is reliable.
The user of an Actyx deployment will not notice in any way that they are using ipfs in the background.
There are also some other interesting developments involving ipfs and rust. See a list of implementations here:
Here is my talk about actyx from IPFS camp 2019: https://www.youtube.com/watch?v=Qzu0xtCT-R0 . It does not go into much technical details, and it does not describe the current architecture but a previous iteration though.
Bitswap has a compat mode, but when two ipfs-embed versions talk to each other they use a different protocol.
Note that ipfs-embed is made for a different use case than the global ipfs. It is typically used by private swarms where there are a smaller number of nodes. So e.g. we don't use the DHT at all.
We also found that go-ipfs compat is not that useful for our use case, so the compat layer was mainly done as a service to the community and might not work with the latest go-ipfs / kubo.
Basically the nodes of the swarm (around 100 at most) gossip events to each other. That is also how they learn about the presence of the other nodes. They try to stay connected as well as the network topology allows.
Then when you want some bulk data via bitswap they just ask their current peers. Either the emitter of the data is a current peer, then it obviously has it. Or eventually one of your peers will replicate the data, and then you will get it with some delay.
The latter happens frequently if a part of the swarm is behind a NAT. You have some delay, but eventually everybody gets all events.
https://winworldpc.com/download/7f8040e5-d206-11e7-a73f-fa16...
https://blog.cloudflare.com/cloudflare-pages-on-ipfs/
Unfortunately, as far as I understand, they closed down the open ipfs gateway [b] [p] - it's now up to "users" to pay for bandwidth exposed via ipfs on the web:
https://blog.cloudflare.com/ea-web3-gateways/
It does an OK job. I put technical videos and rendering tests on Peertube.[1]
If you don't need "discovery" or "monetization", it's a good option.
I like the design concept of the main software (a drag and drop sharing application that happens to enable IPFS rather than some kind of specific server/client kit) but there needs to be better server software for this to ever be popular. You need IPNS at the very least to have a website equivalent and updating that automatically requires some custom tooling already.
Then there's the privacy problem. In the default settings, you can query what IP read what content. You can run IPFS over Tor but that requires command line knowledge at the very least. The docs briefly mention it but don't go into detail.
The NFT boom brought more attention to IPFS and I don't think that's necessarily a good thing; I don't think the association with cryptocurrency scams and IPFS will help the protocol forward.
One is paid pinning services - services that ensure the existence and availability of files in the network.
Then there i FileCoin - an augmentation with a specialised economy that tried to have files stored an available based on a market.
On the other hand, bittorrent would probably benefit from a FileCoin like economy build on top of it.
p2p makes most sense for ephemeral transactions.
There are services where I don't want them going down ever of course. But those are more critical infrastructure than something like Apple Music or YouTube.
Care to explain why? I only know the basic idea of IPFS and sounded great to me and something I was looking forward to get stable and widely adopted.
In which way is it a joke?
If you want something to be fast then your content needs to be hosted on servers with fast connectivity to other servers. And that's not possible when at the same time you're trying to avoid legal jurisdictions that will censor e.g. EU, US, CN etc.
Which is to say - the main technical problems that hampered BitTorrent probably aren’t there anymore.
It is also probably (I'm not quite sure yet) worse for the illegal uses because it is slower and more compute heavy than torrents, and there is way worse discoverability and moderation, which is important in the communities sharing illegal files.
Basically any true decentralisation is an attempt to eliminate trust from the system. And there are two problems with this - 1) maybe 0.1% of all attempts are actually decentralised (other 99.9% are either self delusional or lying), and 2) trust is actually a desirable thing, especially in the important things like money or file storage.
I mean it's their lives but I like their work, except the silly crypto stuff.
Also HN people: Stop wasting time trying to make legitimate use cases for crypto!
I don’t see the issue here.
You disprove "no use cases" by finding one where a blockchain is a natural fit. Not by taking a standalone idea and grafting a blockchain onto it.
Heck, IPFS is over seven years old!
Keep Reading ↓