It's cool for preventing things like censorship. Something like SciHub would really benefit from it.
However, for "real world" use cases, many people want to be able to remove or modify what they've uploaded. With IPFS, as far as I'm aware, doing either doesn't really change the underlying data but just creates a new object in IPFS instead which you'd point to via IPNS. Anyone who still wanted to view the old content still could, provided they had the right content id.
God forbid you accidentally upload a "personal" photo, your only hope is that someone never comes across the content id of that image. There is no way to undo it!
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.
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.
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.
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.
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.
Immutability is not real. There is always a hosting with files. For this reason a community should manage such uploads, and not a random community without rules or values, and not onto a nameless server, for things to be reasonably flexible at first.
Permanence comes from distributivity and from real hardware, not from IPFS. Its pinning is only a few days long, in reality. It's not really a hosting, rather a sporadic buffer.
It's cool for preventing things like censorship. Something like SciHub would really benefit from it.
However, for "real world" use cases, many people want to be able to remove or modify what they've uploaded. With IPFS, as far as I'm aware, doing either doesn't really change the underlying data but just creates a new object in IPFS instead which you'd point to via IPNS. Anyone who still wanted to view the old content still could, provided they had the right content id.
God forbid you accidentally upload a "personal" photo, your only hope is that someone never comes across the content id of that image. There is no way to undo it!