I'm not sure anyone would be surprised that IPFS's performance would be worse than FTP or any other protocol when it comes to transfers between two (or three) hosts.
The benefits of distributes systems becomes bigger the larger the network. Replicate the same results with 100 nodes and we'll see.
I still think torrents would be even more efficient though, than both FTP and IPFS.
Since IPFS's performance is worser than FTP's, a client-server architecture is, apparently, betterer!
I wonder how representative of a real-world scenario a three-node IPFS network is. I thought that file fragments are strewn across more nodes typically, with some redundancy. FTP offers nothing like this.
So far this looks a bit too apples-to-oranges to me. Has anyone actually read the paper?
> I thought that file fragments are strewn across more nodes typically, with some redundancy.
In real world use, this is rarely the case on IPFS. Almost everyone who is trying to make files available via IPFS reliably is pinning the files themselves using a server they operate.
I have heard of IPFS's bad performance quite often and as you point out it is weird because I know that isn't specific to distributed storage in general. How much of this is implementation specific though? Would it be possible for there to be a IPFS implementation that solves most of these performance problems? Since the protocol itself is so similar to bittorrent it would surprise me if it is protocol inherent, but I am not sure.
I don't have a big-picture answer for you, but I'll point out that there are a lot of performance-relevant details that are different between the two protocols.
A torrent is basically a filesystem, dumped into a single large bytestring, broken into constant size chunks. Then there is a fairly small swarm of nodes trading those chunks. Most of those nodes are trying to download everything, and want to saturate inbound/outbound pipes.
- IPFS is a single massive DHT for advertising who has what for every single blob in the entire network. Most nodes have a tiny subset of that data.
- IPFS does not use a constant block size.
- IPFS uses a "multihash" instead of hard-coding a specific hash function. This adds parsing time to hashes, and means that hashes are not a consistent size, and they have sizes that don't fit cleanly into words.
Those are just some details that I happen to know off the top of my head, but you start to see the picture. In every architectural trade-off, IPFS goes for the more general thing, instead of the performant thing.
For what it's worth I've spoken with the creator of this project. They're well aware many of the NFTs hosted on IPFS have an HTTPS URI pointing to a gateway. That's easy to parse and they included these results as IPFS.
There's also Arweave and various other decentralized approaches. Actually Arwave is interesting because if all of the Ethereum NFT assets were added to Arweave it would increase the size of bytes on Arweave by 50%...
Also, many of the IPFS pinning providers host their entire infra on AWS or some other centralized big cloud provider. Makes sense but further points to how hard truly decentralized really is (see Arweave stats).
I have no issue with svgs, that’s good and desired, a lot of them are really clever, MLOOT (More Loot) on the other hand is a strange game and I hope that style doesn’t catch on
> They're well aware many of the NFTs hosted on IPFS have an HTTPS URI pointing to a gateway. That's easy to parse and they included these results as IPFS.
Glad to see! Can that info be added to the blog? Yeah I think the paid pinning services should only be a stopgap solution. I think purchasers of NFTs should pin their own and someone should make it easy for them to do that. I bet you could include code for that within the NFT classes, just like how people ram dynamic svg code into them. For collections like PFPs I think projects can incentivize staking+pinning for extra rewards like slowly over time minting an additional nft for people that do it, or separate nft/token for a parallel collection. (Like if mutant ape serum was only claimable by ape holders that helped pin the collection on ipfs)
I need to look at Airweave closer!
But yes this will improve the nft concept very well, and glad to see the path for improvement is happening so fast, money chasers are following the same tutorials.
IPFS is already used to stream (porn and not porn), mostly Chinese apps with 50k+ users at least. Not the kind of projects that make noise on HN etc though.
Is it? What about mirrored FTP Servers which are distributed or using a cached filesystem sitting behind a DNS round robin record. That was a thing 3 decades ago.
I guess the question is, what value does IPFS bring that couldn't be done with 30 year old tech to a private network?
Adding an IPFS node does not require a new DNS round robin record, or any other synchronisation with the rest of the infra. It allows adding single files or even parts of them to the storage transparently. Also it eliminates the question of how do you keep the FTP nodes synchronised.
I'm considering using IPFS for storing metadata (in a similar way that DOI tracks publications) for accessioning genomics and wetlab microbiology data. The data will still be stored in the institution (b/c of data governance laws).
The reason I really like that IPFS exists is bc it's a really convenient, mostly cheap and mostly reliable place to put stuff for quick access, even more than running my own server (ew), or paying for hosting and/or using Supabase, Firebase, etc.
Basically using IPFS as a convenient k/v store. The data is still stored locally, but it's just much less convenient to access.
To be clear, and perhaps why you’re being downvoted, IPFS stores nothing. It only guarantees that a given file will result in a certain hash id and that perhaps if there are servers available with assets that match that hash they might serve it. Hence the existence of pinning services which are paid platforms that do the actual hosting.
> The reason I really like that IPFS exists is bc it's a really convenient, mostly cheap and mostly reliable place to put stuff for quick access, even more than running my own server (ew), or paying for hosting and/or using Supabase, Firebase, etc.
I think you're confusing pinning services or something else and it is actually quite a bit more expensive than Google Drive and other sync and storage solutions.
IPFS doesn't store anything. You could just as easily setup Syncthing and it would perform the same functionality it you just want to address your files elsewhere.
No mention of node performance? Running your own IPFS node with any non-personal amount of traffic is ROUGH. Poor storage quota support combined with a terrible garbage collector that consumes 1000% CPU on my Epyc cores every time it runs…
Yeah, I had to take go-ipfs off my home server because it would grind it to a crawl. Even with attempts to memory limit it is seems that somehow it would constantly thrashy disk cache even when basically idle.
The think the core IPFS technology is great. But they really need to settle down with changing the higher level protocols and the go-ipfs implementation is truly a piece of junk.
2nd this. I saw lots of packet loss on my gig connection when scraping a few TBs over IPFS. Turned off garbage collection which just deletes the whole cache when you go over a threshold?
48 comments
[ 3.1 ms ] story [ 89.3 ms ] threadThe benefits of distributes systems becomes bigger the larger the network. Replicate the same results with 100 nodes and we'll see.
I still think torrents would be even more efficient though, than both FTP and IPFS.
You may be interested in BTFS, which is elements of IPFS but using BitTorrent as the protocol.
The structures were cleaned up and given a shave, the trackers removed in favor of just putting everyone on the dht.
So another way to look at it, is that every modern p2p protocol is just eMule :)
That's true. I would be interested in an experiment to show how many IPFS host would be needed to reach parity to FTP and other protocols.
I'm also wondering if IPFS can't be integrated in CDNs.
https://hypercore-protocol.org/
I wonder how representative of a real-world scenario a three-node IPFS network is. I thought that file fragments are strewn across more nodes typically, with some redundancy. FTP offers nothing like this.
So far this looks a bit too apples-to-oranges to me. Has anyone actually read the paper?
In real world use, this is rarely the case on IPFS. Almost everyone who is trying to make files available via IPFS reliably is pinning the files themselves using a server they operate.
People should judge IPFS on this, not p2p file systems or DHTs generally. Bitorrtent for example would do a lot better on those large file tests.
A torrent is basically a filesystem, dumped into a single large bytestring, broken into constant size chunks. Then there is a fairly small swarm of nodes trading those chunks. Most of those nodes are trying to download everything, and want to saturate inbound/outbound pipes.
- IPFS is a single massive DHT for advertising who has what for every single blob in the entire network. Most nodes have a tiny subset of that data.
- IPFS does not use a constant block size.
- IPFS uses a "multihash" instead of hard-coding a specific hash function. This adds parsing time to hashes, and means that hashes are not a consistent size, and they have sizes that don't fit cleanly into words.
Those are just some details that I happen to know off the top of my head, but you start to see the picture. In every architectural trade-off, IPFS goes for the more general thing, instead of the performant thing.
I don't know for sure, but have tried the Go and Node IPFS versions and both are pretty bad. The node version did seem less reliable though.
I don't think this reflects on the language or runtimes - just how they are coded.
I wonder how perkeep would perform in that situation.
https://yournfts.org/#stats
OpenSea uses Google Images!
As others have noted no matter what these marketplaces all cache the tried and proven Web2 way with the usual large CDN providers, etc.
But I bet a large breakdown of that is spammier NFTs that use string concatenation and svg rendering such as MLOOT
Also of the HTTPS I bet much of that is Pinata or Cloudflare which are just pinning services for IPFS
In any case I’m actually impressed by these numbers and expect them to further improve away from HTTPS
For what it's worth I've spoken with the creator of this project. They're well aware many of the NFTs hosted on IPFS have an HTTPS URI pointing to a gateway. That's easy to parse and they included these results as IPFS.
There's also Arweave and various other decentralized approaches. Actually Arwave is interesting because if all of the Ethereum NFT assets were added to Arweave it would increase the size of bytes on Arweave by 50%...
Also, many of the IPFS pinning providers host their entire infra on AWS or some other centralized big cloud provider. Makes sense but further points to how hard truly decentralized really is (see Arweave stats).
> They're well aware many of the NFTs hosted on IPFS have an HTTPS URI pointing to a gateway. That's easy to parse and they included these results as IPFS.
Glad to see! Can that info be added to the blog? Yeah I think the paid pinning services should only be a stopgap solution. I think purchasers of NFTs should pin their own and someone should make it easy for them to do that. I bet you could include code for that within the NFT classes, just like how people ram dynamic svg code into them. For collections like PFPs I think projects can incentivize staking+pinning for extra rewards like slowly over time minting an additional nft for people that do it, or separate nft/token for a parallel collection. (Like if mutant ape serum was only claimable by ape holders that helped pin the collection on ipfs)
I need to look at Airweave closer!
But yes this will improve the nft concept very well, and glad to see the path for improvement is happening so fast, money chasers are following the same tutorials.
[1] https://sugarbounce.com/
[1] https://ipfs.io/
> the reading performance of IPFS degrades as the data become more popular in the network.
I'd have expected the opposite.
I guess the question is, what value does IPFS bring that couldn't be done with 30 year old tech to a private network?
Also a suite of utilities for concocting your own p2p applications though standardized APIs. But that's more libp2p.
The reason I really like that IPFS exists is bc it's a really convenient, mostly cheap and mostly reliable place to put stuff for quick access, even more than running my own server (ew), or paying for hosting and/or using Supabase, Firebase, etc.
Basically using IPFS as a convenient k/v store. The data is still stored locally, but it's just much less convenient to access.
Is anyone else doing this kind of setup?
I think you're confusing pinning services or something else and it is actually quite a bit more expensive than Google Drive and other sync and storage solutions.
IPFS doesn't store anything. You could just as easily setup Syncthing and it would perform the same functionality it you just want to address your files elsewhere.
The think the core IPFS technology is great. But they really need to settle down with changing the higher level protocols and the go-ipfs implementation is truly a piece of junk.
Also, please re-implement it properly!