How We Made IPFS Content Publishing 10x Faster • Hacker News Board

Re: How We Made IPFS Content Publishing 10x Faster

#21

Post by boramalper » Wed, Jul 01, 2026, 6:29 PM UTC

MattCruikshank wrote: post #15

boramalper wrote: post #12

Is anyone still (or has anyone ever) used IPFS in production? I’m not talking about technology demos such as Wikipedia-on-IPFS (which indeed worked and was impressive) but where IPFS is actually being relied on for some functionality.

It doesn't seem like it's popular to put old game ROMs on IPFS...? And that surprises me...

And why would you do that? As opposed to, say, distributing via BitTorrent or serving them using a good-old HTTP server?

edit: Not opposed to the idea, just curious what makes you pick IPFS over the existing alternatives.

Re: How We Made IPFS Content Publishing 10x Faster

#22

Post by somat » Wed, Jul 01, 2026, 6:33 PM UTC

catapart wrote: post #13

deno wrote: post #11

Earlier quoted context omitted.

Imagine you created a torrent (and/or magnet link) with a file and then stopped seeding after some time. If it was popular it will probably live on, if not then eventually it disappears.

Thanks! Yeah, I kind of figured that was still the case. Not really any use cases I have that I would feel comfortable with that paradigm, but I'm glad it's available!

Is that not the same with anything published to the internet. For example I could keep your comment published and available for as long as I had interest in doing so despite any effort you may take to remove it from HN. I mean I guess tech like ipfs and bittorrent try to automate this process(keeping something on the internet as long as there is interest) but you let something out on the internet it could stay there a long while. Or it could go poof and disappear, it depends on how much interest there is in the subject.

Re: How We Made IPFS Content Publishing 10x Faster

#23

Post by hannesfur » Wed, Jul 01, 2026, 6:42 PM UTC

Having worked on libp2p‘s DHT (Double Hashing for rust-libp2p) for a bit two years ago, it’s really great to see that there are improvements. To get to CDN level speeds though on dense networks, I still see it as an architectural flaw to not somehow encode network topology into the PeerID / identity in the DHT. A start would be to use the five RIRs. If you want to be more sophisticated, and I spent a lot of time theorising about this, you could have a dezentrally governed anycast IP address of Geo DNS to bootstrap new peers into their neighbourhood and couple that into their DHT identity. But do you want to put BGP into the hands of a decentralised system? Could you even do it in the governance structure of the internet?

Btw when we were working on our project HyveOS, we used Batman-advs routing table to quickly (really really quick) bootstrap new peers into the system.

Ah… sometimes i really miss working on this.

Re: How We Made IPFS Content Publishing 10x Faster

#24

Post by davidwritesbugs » Wed, Jul 01, 2026, 6:47 PM UTC

Slightly tangential to the article, which seems interesting, but the main issue with IPFS was the horrendous performance of clients which I seem to recall related to having a refresh storms, sparse routing tables, unreachable peers as well as lookup speeds. Mostly the reputation was so bad that people didn't bother with it, I dismissed it for my own project. If your only users are crypto-grift projects you're in a bad place.

Re: How We Made IPFS Content Publishing 10x Faster

#25

Post by Borg3 » Wed, Jul 01, 2026, 7:03 PM UTC

boramalper wrote: post #12

Is anyone still (or has anyone ever) used IPFS in production? I’m not talking about technology demos such as Wikipedia-on-IPFS (which indeed worked and was impressive) but where IPFS is actually being relied on for some functionality.

Yeah.. IPFS is a bit disappointement. I was a bit exceited about it back in the day. Recently, I wanted to download sth large from archive.org, I used torrent (and my legacy torrent client) and it worked like a charm!

It seems pure HTTP tracker + Torrent is good enough.

Re: How We Made IPFS Content Publishing 10x Faster

#26

Post by ydj » Wed, Jul 01, 2026, 7:22 PM UTC

boramalper wrote: post #12

Is anyone still (or has anyone ever) used IPFS in production? I’m not talking about technology demos such as Wikipedia-on-IPFS (which indeed worked and was impressive) but where IPFS is actually being relied on for some functionality.

At meta, there was a project for delivering binaries of internally built libraries / binaries to dev laptops using a private ipfs network. This was live for at least some period of time.

Re: How We Made IPFS Content Publishing 10x Faster

#27

Post by [deleted] » Wed, Jul 01, 2026, 7:29 PM UTC

boramalper wrote: post #19

frollogaston wrote: post #17

Earlier quoted context omitted.

NFT artwork, if you count that. Briefly checked, the ones that were traded for the most were using IPFS rather than HTTP. But I also don't trust that these aren't self-wash sales (easy given the "NF" part), also NFTs are dumb.

I don’t think NFTs (should) count: My first impressions of web3 by Moxie Marlinspike https://moxie.org/2022/01/07/web3-first-impressions.html

[deleted]

Re: How We Made IPFS Content Publishing 10x Faster

#28

Post by WorldMaker » Wed, Jul 01, 2026, 7:42 PM UTC

Groxx wrote: post #8

embedding-shape wrote: post #3

> Return control back to the user after most (not all) of the PUT RPCs have succeeded and continue with the remaining ones in the background. Making things faster by doing less (and not the same) been speeding up computing since forever! Can't help but feel like it's slightly misleading to call the providing ("publishing") faster when it's not actually doing the same, it's just that most parts turned async instead of…

The "Early Return" sections describe it more, I don't think it's as bad as it sounds in that first bullet. They're returning after 15 out of 20 complete,and it sounds like even if only those 15 end up succeeding it'll still generally be fine. (Exactly how fine / is that violating some common expectations and will cause problems: I dunno. Not familiar enough with IPFS's internals) That said: > In practice, at least on…

> (Exactly how fine / is that violating some common expectations and will cause problems: I dunno. Not familiar enough with IPFS's internals)

I felt the article addressed that a bit further down. 20 copies is a somewhat arbitrary knob in the Kademlia DHT design IPFS is based on and this lab's research suggested that 15 was probably closer to good enough for GET requests to succeed at about the same time cost. Rather than dropping the knob for the entire DHT, because redundancy is always useful in the long run they went with the Early Return and a secondary process called the Reprovide Sweep that still tries to push the network towards the 20 live copies minimum it desires.

I'm assuming the Reprovide Sweep was work previously done/documented because it seems like something that might have been more interesting to discuss at longer length in relevant parts of the article.

Re: How We Made IPFS Content Publishing 10x Faster

#29

Post by darkwater » Wed, Jul 01, 2026, 8:02 PM UTC

boramalper wrote: post #21

MattCruikshank wrote: post #15

Earlier quoted context omitted.

It doesn't seem like it's popular to put old game ROMs on IPFS...? And that surprises me...

And why would you do that? As opposed to, say, distributing via BitTorrent or serving them using a good-old HTTP server? edit: Not opposed to the idea, just curious what makes you pick IPFS over the existing alternatives.

Maybe fear of Nintendo coming to bite you?

Re: How We Made IPFS Content Publishing 10x Faster

#30

Post by topgrain2 » Wed, Jul 01, 2026, 8:09 PM UTC

boramalper wrote: post #21

MattCruikshank wrote: post #15

Earlier quoted context omitted.

It doesn't seem like it's popular to put old game ROMs on IPFS...? And that surprises me...

And why would you do that? As opposed to, say, distributing via BitTorrent or serving them using a good-old HTTP server? edit: Not opposed to the idea, just curious what makes you pick IPFS over the existing alternatives.

The idea of simply mounting a filesystem and selecting from a list of titles which roms to download and add to your local games, unloading them and transparently re-downloading when you need to free up space, all without relying on a centralized host even for the file index, is pretty appealing. You can do similar things with torrents but it's not quite as "natural".

Most of the emulator frontends I've seen are pretty against integrating this kind of ease-of-piracy stuff, though, accepting recognizing and filling in metadata for well-known roms, but not making it easy to integrate with remote libraries of roms... except tools that run on "hacked" consoles, which seem to love just giving you a list of games with a "tap A/X to pirate" UI.