TL;DR; We think libp2p puts too many abstractions between us & the socket.

Should your project switch away from libp2p? Probably not. Only do this if you’re ready for a very real slog through the guts of the intertubes. A little extra load time probably isn’t worth your project being delayed 8 months.

We have come to the conclusion that libp2p puts too many abstractions between application code & the raw networking stack. libp2p forces design choices, configuration costs and abstraction costs that we cannot afford to pay.

p2p systems are at an inherent disadvantage to purely location based systems that enjoy incumbency today, because p2p systems require managing membership in both physical and overlay networks. This cost can only be minimized, not eliminated, and is why any added per-peer overhead has massive implications for the overall efficiency of the network.

But let’s keep in mind the bias our team brings. It should not come as a surprise that a bunch of rust engineers trying to innovate in distributed systems want total control over the networking stack. Our whole job is to provide reliable fast connections. This is our bias, it may not be yours.

The libp2p promise is great. A number of incredibly talented engineers are providing a library that means you don’t have to contest directly with the idiosyncrasies of how peers are connected. Instead you get a high level, duplex stream abstraction to work with. That abstraction comes with a perf cost.

Our work to date leads us to a basic conclusion: if you want a fast p2p thing, you either need to get very good at writing networking code, or you need to build on a project that optimizes for your use case. The more exact, the better. I’d say for 80% of projects, that’s still libp2p. If IPFS is what you want, but remains out of reach because it doesn’t perform well enough, then you likely need something that is purpose-built to move content addressed data, which is what we’re doing.

The DHT is a great example. DHTs with 95% subsecond-lookup times have been built. They got there by working with raw UDP datagrams, a decision libp2p will prevent you from making.

Raw data transfer is a similar story. By choosing QUIC as our only networking protocol, we can hyper-optimize for that stack, which has already put our performance numbers much closer to what we had originally hoped when we started work on Iroh.