> The “Public IPFS DHT” is henceforth going to be called “Amino”. This follows along with the trend from 2022 in the IPFS ecosystem to use more precise language to create space for alternative options<p>I'd argue that "Public IPFS DHT", if less catchy, is <i>far</i> more precise than "Amino".
Is IPFS working these days? I was very excited about it eight years ago, to the point where I made one of the first IPFS pinning services, but lost all my interest. IPFS is a great idea, but the implementation basically doesn't work, and it certainly doesn't work to the point where people can be running the node locally.<p>It used to have tons of problems discovering content from other nodes on the network unless it was directly connected to them, and it broke often. It also didn't seem like Protocol Labs worked on any of these problems at all, focusing on launching a cryptocurrency instead.<p>Has it changed now?
I've been looking into a private IPFS network as a way to share photos. It doesn't seem ready for that. Is there something out there that allows clients to update a mounted drive and keep in sync? Something that is transparent enough that ordinary users aren't intimidated to use it?
The concept of an "Interplanetry Filesystem" is a good one.<p>The actual IPFS implementation doesn't live up to expectations though.<p>Expectations:<p>* I want to be able to mount / as IPFS and know that I can boot linux from anywhere.<p>* I want to have my photo library on IPFS and add to it from anywhere.<p>* I want to be able to share anything on IPFS, and if someone else has already uploaded it for the upload to be instant.<p>* I want all the storage on my phone/laptop/whatever permanently full of other peoples stuff, earning me credits to store my own data.<p>* I want my stuff reed-solomon encoded with lots of other data, so that in case of a failure of a chunk of the network, my data is still recoverable.<p>* I want the network to be fast and reliable with excellent sharding of data and minimal hotspotting.
Works fine for us so far. Discovery of newly added files is immediate. Downloading speed is fast.
It’s quite easy to get this to work, you need to have a few or more instances with these objects pinned.
And make sure the bandwidth and other resources are sufficient and the servers are always online.
Or use a reliable pinning service that can do this for you.
I still think the biggest problem with IPFS is that they put every block of every file in the DHT. It's just insane compared to BitTorrent, which only puts the top level torrent info in the DHT.<p>Having the option to pin just one file is useful, but they could greatly reduce DHT traffic if they didn't need to allow access to arbitrary resources without starting at some parent block.<p>BitTorrent requires you access files via a collection, and only the collections are stored in the DHT, and the bandwidth use when idle is single digit kb.<p>I think BitTorrent itself could be extended to cover most IPFS use cases, possibly better than IPFS itself, although IPFSes database-like stuff is pretty unique.
It would be nice if there was an IPFS implementation with much lower memory requirements. I tried a while back on something equivalent to a “free tier VM” and it quickly ate all available RAM.
Am I especially dumb, or is IPFS messaging really flaky?<p>For example, I still don't understand how to access their resources. Do I need a special client?<p>And this is coming from a person who LOVES torrents...
> assuming a network size of ~25k DHT Server nodes<p>I guess they've given up on the idea of end users running full nodes.<p>There still might be some value in having a federated CDN service, but I think they will struggle to compete with centralized CDNs for all the same reasons other federated services have struggled.
IPFS is trash. The APIs and interfaces of which there are millions change signatures every 6 months. Your 4 month old code will not run anymore and fixing it is a real slog.<p>Sigh.