An evaluation of the IPFS paper

2021-01-07 Dagger Team

Goal of this evaluation is to find things to adopt or avoid while designing Dagger. It is not meant to be a criticism of IPFS.

IPFS is designed by simplifying, evolving, and connecting proven techniques (§3)
Consists of a stack of separately described sub-protocols (§3)
Uses Coral DSHT to favor data that is nearby, reducing latency of lookup (§2.1.2)
Uses proof-of-work in S/Kademlia to discourage Sybil attacks (§2.1.3)
Favors self-describing values such as multihash (§3.1) and multiaddr (§3.2.1)
BitSwap protocol for exchanging blocks supports multiple strategies (§3.4.2), so it should be relatively easy to add a micropayment strategy.
Uses content addressing (§3.5)
The Merkle DAG is simple, yet allows constucting filesystems, key-value stores, databases, messaging system, etc.. (§3.5)

Kademlia prefers long-lived nodes (§2.1.1), which is not ideal for mobile enviroments (although it's unclear whether there are any better alternatives)
The default BitSwap strategy falls just short of introducing a currency with micro payments, necessitating additional work for nodes to find blocks to barter with (§3.4)
Object pinning (§3.5.3) inevitably leads to centralized gateways to IPFS, such as Infura and Pinata
IPFS uses variable size blocks instead of fixed-size chunks (§3.6), which might make it a bit harder to add incentives and pricing
Supporting version control directly in IPFS feels like an unnecessary complication (§3.6.5)