Hacker News Reader

Comment by eric__cartman | Hacker News Reader

From my understanding if you accidentally upload a personal file, as long as no one downloaded it in the time you took to realize your mistake taking down the only node that has the file (your computer in this case) should effectively "erase it" in the sense that unless the node comes back up, even if someone has the id of that file they are SOL.

View on HN

Ok, I have to ask, what is an actual difference between torrents and ipfs? I don't care for technical details, I mean the business logic, so to speak.

- Both use DHTs to search for sources of fingerprinted content. - Both use nodes (seeds in BT terminology) that actuallu store the content. - Both don't have an "archive" system, and so if at least one node doesn't have the file, it may as well not exist at all. - Both can have content censored by going after the node operators.

Am I getting any of these wrong?

BitTorrent is easier to understand (IMO) and can sometimes be faster at lookups than IPFS. IPFS dedups content, whereas if you have an identical file in 2 torrents but only one is seeded, you can't download it from the other one. As far as I know those are the only differences.

Edit: Actually BitTorrent v2 dedups files so it seems like IPFS and BitTorrent are now functionally identical.

BitTorrent, in my view, is a messy format, while IPFS is more clear in design. BitTorrent, namely, has fixed chunks and data overlaps in them from adjacent files which make the format artificially merging different files and create difficulties to treat parts individually, e.g. pick a single random file and check its only hash from a torrent. It looks like they couldn't get the basics deeply comprehended at the design stage.

This is much neater in IPFS. Files and data blocks are individually handled, and there is no situation when a hash embraces several independent file fragments. Adaptive block sizes are also supported which is extremely useful for handling such collections as LG is (however I haven't checked if it's really used at present) instead of having an extra layer of hashes to rehash files individually after the torrent hashed their chopped "tape/tar" chucks. The forced BitTorrent serialization and subsequent fixed-size chunk chopping are basically absent in IPFS. This helps structuring the search and facilitates deduplication, too, through the strict Merkel tree correspondence to files, as opposed to the randomized data chunks having a fixed size for no real necessity and meaningless hashes for wider applications.

To me these are the key aspects, even torrent bug fixes, that IPFS possesses.

>BitTorrent, namely, has fixed chunks and data overlaps in them from adjacent files

BitTorrent 2 fixes that: https://blog.libtorrent.org/2020/09/bittorrent-v2/ (hash trees section)

Thanks, I actually did suspect they do. They still aren't Web friendly and require dedicated software unlike IPFS via gateways being more Web-ready.

Who knows, BitTorrent might have never fixed this without seeing how IPFS works.

Though it isn't an ideal solution (it's rather large and doesn't have DHT support), https://webtorrent.io supports torrents in browsers.

Evolution makes different systems adopt each other's features and eventually they may equate as operating systems did. IPFS has key necessary features more on the surface and is a lot more adaptive to modern operating systems compared to torrents, with much less internal games nearly absent in a nodal IPFS software design.

Multiple things make IPFS a more architecture-oriented solution than application-oriented BitTorrent.

There are various application features yet holding back BitTorrent and LG will utilize them in future.

The difference is the granularity. A torrent is like a tar file, it's a big blob of static data that can't be updated. IPFS in contrast works more like a file system, you have a top level directory that points to the content within it. If you want to change something, you just update the top level directory, while all the content within it can stay the same. Each file on IPFS has it's own checksum and can be addressed individually.

IPFS doesn't help much with censorship, as it has all the same issues as torrent in that area. It doesn't help much with privacy either, as it's all rather public. It's really for legitimate uses, not outside-the-law kind of stuff.

The benefit of IPFS is that its granularity makes it much more useful for smaller tasks. For example you can host Git repositories or source trees on there. And since IPFS on Linux can be mounted as a file system, you can just access them with a simple `cd` command, no manual download or extraction needed.

Reply on news.ycombinator.com