|
|
|
|
|
by dudehere
1733 days ago
|
|
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 2 fixes that: https://blog.libtorrent.org/2020/09/bittorrent-v2/ (hash trees section)