Hacker News Reader

Comment by jude- | Hacker News Reader

Would be curious to know how using IPFS for internal container distribution compares to using BitTorrent. IIRC BitTorrent has found similar uses in the past.

Also, how well does BitSwap work when the underlying network is congested? Do IPFS nodes do any kind of congestion control?

View on HN

You can't update a torrent, if the content changes you have to create a new one. IPNS helps with that. And you can't share pieces across different torrents, if some still have the old torrent, they share it separately from the new one even if the differences are minimal.

The article doesn't mention IPNS at all, nor does it talk about the need for mutating an image while it is being shared, so I'm not sure why you think IPNS is even desirable in this use-case?

"Inter-Planetary Name System (IPNS) is a system for creating and updating mutable links to IPFS content. Since objects in IPFS are content-addressed, their address changes every time their content does. That's useful for a variety of things, but it makes it hard to get the latest version of something."

https://docs.ipfs.io/guides/concepts/ipns/

TLDR IPNS are pointers to IPFS content (ie "latest"). If you're tracking your containers and pinning to their versions elsewhere, might not need IPNS.

Thanks, but I already know what IPNS is. My points were that (a) it's not needed for this use-case, and (b) it's a distinct system from IPFS. I think you agreed in your TLDR.

I would think because IPNS is IPFS.. and you asked how IPNS compares to BitTorrent. Maybe I misunderstand your question, but the reply seems totally on topic and a valid answer to your question.

IPNS is a system that runs on top of IPFS. You do not need IPNS to use IPFS.

That's technically correct, but in practice the term "IPFS" is commonly used to refer to both ipfs and its optional feature ipns.

Not in my circles. IPFS is used a lot for storing and archiving files but IPNS is rarely used or mentioned. The only situations I've seen where IPNS would be useful, ENS was used instead as it's more reliable.

> And you can't share pieces across different torrents

So make each layer an own torrent?

That's still not great. Imagine the only difference between two versions of the layer is that you updated a single jar in a 200MB app bundle. The effective difference could be a few tens of blocks, but you still need to redownload the whole thing.

If we can manage the assignment/padding to match ipfs fragments, that could result in a massive saving.

That is a limitation of the Torrent clients.

On top of that, most of them should already be able to understand that certain files already exist; but it seems like it’s more of a file-level feature at this point rather than block-level.

Is there something I am misunderstanding?

Does anyone use IPNS for anything real? It performs terribly whenever I've tried it. It almost turned me off entirely from using IPFS until I realized that it's just an optional extra and the rest of IPFS is still useful without it. I really wonder how many people try out IPFS, run into issues with IPNS, and then write off the whole project because they thought IPNS was a central piece to it. I think the project would do really well to strike all references to IPNS from their getting-started guides, bring up reliable alternatives like DNSlink records (or even ENS), and then maybe bring up IPNS as an optional extra.

that should be irrelevant for container distribution as container images are immutable.

although there was an IP to bittorrent for that :(

Reply on news.ycombinator.com