Properties of Existing (or proposed) Data Transfer Protocols

Some Notes:

This is all a very flawed WIP comparison, make comments/changes/etc.
There are no winners or losers here, these protocols each have advantages/disadvantages in different scenarios let’s try and talk about them and their approaches honestly.
- Let’s try and leave out minutiae unless someone really thinks its important (e.g. does it matter if nodes are using IPv4 or IPv6 … probably not)
- If you see something you think is irrelevant call it out in a comment
In that vein some areas people might contend with, but I tried to roughly get the point across (suggestions very much welcome):
- “Server can handle arbitrary data structures”: While technically any DAG protocol that can process multihash and raw blocks can be a block protocol by asking for 1 block at a time (or an identity CID pointing to a set of blocks) it doesn’t really get the point across of what the protocols are doing, so I’ve separated them out
- Any time the word “selector” appears it could certainly be swapped out for basically any other graph descriptor in a v2 or similar protocol. If you hate IPLD Selectors that’s fine most protocols don’t care too much.

	Unit of Transfer	Protocol Type	State	Server can handle arbitrary data structures	Incrementally Verifiable Transfers	Can ask about data without downloading it?	Server-Side Work	Tag/External Context Required	Basic Request Unit	Designed to parallelize content fetch across multiple peers?	Impl. Status	Repo Link	Deployment Intent
Bitswap	Blocks	Message (* some implementations treat as Req-Resp)	Yes/Optional	Yes	Yes	Yes	KV Lookups	No	Set of CIDs	Yes	In Production	https://github.com/ipfs/go-libipfs/tree/main/bitswap
GraphSync	DAG	Message	Yes	No (Yes with correct IPLD plugins registered)	Yes	No	Deterministic selector execution	No	(Set of) Selectors	No	In Production	https://github.com/ipfs/go-graphsync
CARMirror	Linked collection of blocks (specific DAG)
Bloom Filter	Req-Resp (streaming variant documented but not implemented)	Yes	Yes	No, but possible with small change	Yes	Graph traversal + early termination by matching Bloom	Yes	RootCID(s) + Bloom	No	Working Prototype	https://github.com/fission-codes/kubo-car-mirror	Make WNFS fetches reliable & efficient, which is a general problem
KrakenSync	DAG	Stream Session	No	No (Even with plugins cannot handle UnixFS HAMTs)	Yes	Kinda: Bitfield info	Deterministic graph traversal per server	No	RootCID	Yes	Working Prototype	https://github.com/n0-computer/krakensync	?
Stargate	DAG	Req-Resp / HTTP	No	Currently UnixFS only	Yes	Yes, configurable	Per “domain” pathing queries (each optimized to a domain)	No	RootCID + Path	Yes	Working Prototype	https://github.com/ipfs/stargate	Possible Boost Filecoin target, mostly aimed to be an IPFS Gateway replacement
Rapide	DAG	Meta-Protocol Composition	Yes	N/A: Uses other Data transfer Protocols	Yes, via choice of transfer protocol	N/A	N/A (depends on the underlying protocol)	No	N/A (depends on the underlying protocol)	Yes	Working Prototype	https://github.com/ipfs/go-libipfs/pull/148	Targeting deployment in kubo to improve download speeds
CAR-over-HTTP (selector, or full DAG)	DAG	Req-Resp	No	No (Yes with correct IPLD plugins registered)	Yes	No	selector execution or DAG traversal	No	RootCID or Selector	No	“In Production”
Manifetch	List of block identifiers	Req-Resp	No	No (Yes with correct IPLD plugins registered)	Yes	N/A	Selector execution	No	Selector-like		Working Prototype	https://github.com/ipfs/test-plans/blob/feat/lightning-storm/data-transfer/manifetch.go
BitTorrent	File byte ranges; v2 has some specific DAG pieces; optional manifest extension	Message	Yes	No	Yes *(manifest not incrementally verifiable if not present)	Yes	Reusable recomputed graph layout	Yes	RootCID	Yes	In Production
WebSeed	File byte range	Req-Resp	No	No	Yes	N/A	Byte range lookups	Yes or N/A	byte range		In Production
Git	Specific DAG	Req-Resp	No	No	No	Yes?	Compute specialized compressed diff. Cached for most common cases	Yes	For git pull : Tag	No	In Production