A rant I posted in the Jupiter Broadcasting Unplugged feedback room
Re 449: about IPFS, I do have some comments/feedback, and some warnings;
IPFS in general was supposed to be a multi-language Thing, however, as of yet, only a golang and a JS version exists. Begin 2020 I was looking to change that, wanting to see python added to the mix (because python is imo a much better language to experiment on), so I started poking at py-libp2p, and through a combination of discussion, talks, and just seeing who or where the maintainers were contributing things, I discovered that IPFS was ran on money, and not the good kind of money.
Py-libp2p (libp2p being a library that was supposed to unify all peer to peer communication in a collaborative way, but is now just a repo merge away from codebase isolation irrelevance) was maintained by ethereum developers, who saw it as a fancy new library to piggyback another client onto, but couldn’t care less for the IPFS usecase itself. That’s kinda fine… if they did not domineer the repo, and dropped it like a ton of bricks (including all outstanding promises and requests) once their boss frowned a little too hard at maintaining it. There exists a community manager who has to manage all this stuff, but they were AWOL for the majority of time I was requesting for a proper look, and the one time they did respond, they dismissed my claims as they had an “agreement” with these maintainers, not even willing to give a proper look at what they were actually doing.
This disillusioned me a ton from the whole thing, because this repo existed under the official libp2p org, which should’ve meant that they get held to the same standards, right?
This is not even going into go-ipfs (the main IPFS “distribution”) in general, as it had a ton of problems as well. It has a tendency to form star networks, as the whole thing needs to be essentially full-mesh over the internet (with NAT punching to limited effect), of which peer discovery will always “find” the public open nodes, which are then promptly spammed, as go-ipfs had absolutely zero configuration for rate-limiting, go-away messages, or other kinds of resource balancing. The “swarm” turns into a stampeding herd for any open node.
The DHT is slow, really slow, and with above problems it becomes even slower to the point of “will this request even finish”? go-ipfs has to re-cache the DHT keys for it’s objects/data blobs every 12h, it has to find (via the DHT) the respective peers that make that happen, and every key (literally every key) has about 3-10 peers that need to be found (via the DHT) and notified. Then when someone wants to find a file, it has to query (via the DHT) the closest key-neighbour nodes to that key, and then fetch (via the DHT) the other hundreds or so little data blob keys, and eventually arrive at peers which has cached them.
For every DHT query, go-ipfs will contact approximately 10-100 peers via direct internet IP TCP handshakes (or equivalents), and this is omitting the hundreds that it tries to contact (but can’t, because DHT often caches wrong, weird, or outdated IP+port combinations for the same peer, that was acquired by other nodes’ perspectives).
My cloud provider eventually froze all my servers because of the SYN flood this caused, and I couldn’t dial down (or ask other nodes to dial down) their connection requests and all, sometimes I’d have over 2k nodes be connected to mine, simply because I was connectable.
go-ipfs has a notion of “high water” and “low water”, trying to keep connections below high, but above low (by opening and keeping connections to key-neighbour peers). This algorithm just prunes and closes the redundant connections, but often peers will connect again immediately, because they haven’t been told “go away, slow down”, they just see a TCP RST and assume the connection just malfunctioned
This is not even to talk about the absolute abysmal (and incorrigible) file fetching.
You better damn hope that the file you’re looking for is cached on multiple peers all screaming those keys in the void. Then you hope that peer isn’t only DHT-submitting the top key in the hierarchy, as it often is.
Let me explain why that is a problem, if you submit only the key to a blob that defines that file, you now have that somewhat distributed in the network, at the cost of only having to re-cache one key instead of thousands, sounds great right?
…except the sub-keys do not exist anywhere on the DHT, so that means that if you have the head-key somewhere, you cannot (or the client isn’t smart enough to) try to “sniff” the network to find out who originally is publishing that key, to connect to to them and fetch the rest.
Except that is fragile, even if you’ve connected to that node, and even if you are now downloading the rest of the file, the connection can suddenly close (see; pruning), and now your client isn’t smart enough to reconnect, so you just hope someone else gets the rest, and screams it onto the DHT.
So to publish files, you’ll have to publish all keys to be at least somewhat consistent, and to do that, you have to scream those thousands of keys onto the DHT, every. Twelve. Hours.
With the client connecting to thousands of peers in the process, concurrently, calling everyone they know, handshakes, exchanges, multiplexing, everything, only to then go to the next one.
Now be surprised as I tell you that the IPFS daemon had 75% of all my CPU in my server at one point, before I decided it can suffer in docker’s resource management jail with only a tenth of that.
Oh yeah, there’s also no bandwidth restrictions, at all :)
That issue has been open for six years
IPFS’ idea is pretty neat, pretty sound, but it suffers from so many long-standing, stupid, dumb, and brain dead problems that don’t look to be fixed. I want to believe IPFS can be something, I really do, but all life has been sucked out of it, and what’s left is (imo) the rotting corpse of crypto hype that they spend and make all their money into/from, while effectively decaying IPFS as an idea.
There’s some promising things happening, but honestly… until they fix these things, until they have limiting, until they have a richer “distribution” ecosystem, until they do not treat IPFS as “good as-is” anymore, I really don’t want to recommend it, it sucks, and the hype is too good at convincing it’s not.