Gerade mal noch 'n bißchen gesucht bzgl. Vorteilen von IPFS gegenüber BitTorrent:
Mateon1 hat geschrieben:[...]
There are several advantages to using IPFS over torrents, but the main advantage is the fact that there is only a single massive swarm, where anybody can give a block to everybody.
For example, say you're visiting a small website that uses jQuery (or some other popular library). There might be only a couple people who visited that website, but you'll still get the library nearly instantly. Maybe from your neighbor, or maybe you already have jQuery in your IPFS repo.
The net result is, the website loads way quicker than would otherwise be possible.
Mateon1 hat geschrieben:[...] for torrents, there is essentially a separate swarm for every torrent. Two big torrents with only a few small files differing won't share peers as IPFS does, for example.
Also, the way Bittorrent chunks content into blocks doesn't work for all types of content (and isn't designed for deduplication between torrents).
mukka hat geschrieben:[...] ah, I see. So like, if there are 2 DVDs, same video but different language packs, I can download the video from both peers, whereas with torrent I have to download both of the DVDs separately (2 entire copies). This is a pretty cool reason to use IPFS. [...]
flyingzumwalt hat geschrieben:The main distinction I'm aware of is the fact that BitTorrent relies on torrent files, each of which contains a content-addressed manifest of the blocks that make up particular content. This has some ramifications:
- forces you to choose what is in each torrent file -- ie. do you create one huge torrent file for all of your datasets or do you make a torrent file per-dataset?
- forces you to track the torrent files themselves with some other tool/system
- requires you to create metadata about the torrent files
- does not natively provide a way to identify torrent files themselves using cryptographic hashes
- does not handle versioning of content
By contrast, IPFS lets you build a DAG of arbitrary size and structure.
Some advantages that occur to me:
- You can track both the content and the metadata in the IPFS DAG
- You can add multiple versions of a dataset to IPFS. Each version gets a unique hash and IPFS does its best to avoid storing duplicate blocks
- You have complete control over which blocks are stored on which IPFS node -- this has huge advantages for distributing storage/backup (see ipfs-cluster)
Also, wichtige Vorteile sind offenbar
Deduplikation (identische Daten müsen nur einmal gespeichert werden) und
Versionierung. Einfache Adressierbarkeit ist auch besser als bei BitTorrent (mit den Magnet-Links), aber wurde wohl nachträglich implementiert, was von einigen kritisiert wird. Zum Beispiel von jenen, die
LBRY entwickelt haben, ein Projekt, das einige ähnliche Ansätze und Anwendungsgebiete wie IPFS hat, allerdings mit Monetarisierung im Hinterkopf:
Der Autor der [url=https://lbry.io/faq/different-ipfs]LBRY FAQ[/url] hat geschrieben:How is LBRY different from IPFS / BitTorrent?
IPFS and BitTorrent are wonderful technologies from which LBRY has drawn a lot of inspiration. However, they both suffer from the same flaws:
- Lack of discovery. BitTorrent and IPFS provide decentralized ways to access a unique piece of data or information, but they do not provide an overall catalog that lists all of the available data or information to consume.
- Ugly URLs. BitTorrent only provides access via long, complex magnet URLs. IPFS supports human-friendly naming via IPNS, but this is an after-the-fact hack and does not provide a single, authoritative, user-friendly namespace the way the LBRY does.
- Lack of monetization. Neither BitTorrent nor IPFS support payments to publishers for the content or data they create and publish to the network*; LBRY does.
- Incentive problems. BitTorrent and IPFS rely on people being generous with their own resources for data to continue to be available. LBRY creates market incentives for data to be as widespread and available as possible.
*Yes, there are attempts to add this via a layer on top, but LBRY bakes it in.
Das Adressierungsproblem haben ja z.B. auch .onion-Seiten, weil sie nur über 'nen kryptischen Crypto-Hash identifiziert werden, aus dem man nur mit tonnenweise Rechenpower was halbwegs Sinnvolles basteln kann.