Hacker News new | ask | show | jobs
by jazzyjackson 1868 days ago
I never understood the difference between ipfs hash addresses and a magnet link hash address.

I guess the magnet link still has to ask a tracking server that knows some peer addresses already right? Whereas an ipfs node can dive into the DHT and start searching for a peer?

2 comments

Basically because there isn't much of a difference. IPFS is basically bittorrent that breaks compatibility to add some fancy new features in exchange for more resources usage, like RAM. bittorrent v2 also does this but more modestly as it intends for torrent clients to upgrade to support it.
There is a big difference in that you can reference a single file/directory from a tree using the IPFS hash, which I don't believe it's possible in BitTorrent (v1). (it's not the same as torrent's partial download) As a side effect this does deduplication so multiple IPFS trees can share the same file improving availability (and provide cheap tree updates)
Bittorrent also has a DHT, which you can use instead of (or as well as) tracking servers.

Perhaps the key difference is that torrents (targets for magnet links) can't link to other torrents, at least not in a way the protocol is aware of. Each torrent swarm is something of an island. IPFS is more like one big graph ("web") of documents/files.

bittorrent v2 is a bit different and more similar to IPFS: https://blog.libtorrent.org/2020/09/bittorrent-v2/
I'm not super familiar with v2 but from what I have read it's not clear how it achieves the same thing as IPFS. Yes, the file-hashing is deterministic, which can allow deduplication across torrents, but it doesn't seem to facilitate either discovery or addressing at the file level. Trackers/DHT and magnet links still only use the info hash (torrent level) as far as I can tell.

IPFS puts file/object hashes in the DHT so they are directly discoverable, meaning people coming to the same object from different from different places can find one another. It also allows one object to be explicitly addressed via an ancestor object's hash (<hash>/path/to/object), which has various benefits.

> which has various benefits.

But also the downside of being incompatible with the BitTorrent network and it's myriad of seeders and torrents.

I think quite a few P2P projects have thrown out compatibility for the sake of some functionality but also the entire baby. PeerTube did the same, disabled WebTorrent support by-default before any BitTorrent clients got WT support. The desire to "move fast" makes people forget what actually makes a system usable and how decades of inertia changes how changes can be made. Impatience.