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