If you read the peer-to-peer entries in these diaries quickly, you could come away with a simple story. A team got excited about peer-to-peer, tried it, and went back to servers.
That story is wrong, and I want to close this run of experiments by saying why.
Circo runs its messaging over WebSockets on servers we operate. Its video runs on a conventional pipeline with multi-DRM protection, and provenance signing at upload is the next layer going into it. None of that is peer-to-peer. And I believe in peer-to-peer as much as I did in 2024. More, if anything, because I now understand precisely what it is for.
A belief is not a bet
The most important thing I have learned as a technical leader is to keep two things apart: what I believe about a technology, and what I am willing to bet a product on.
Belief is about direction. I believe software should give people more ownership of their data and identity, not less. I believe networks that do not depend on one company are more resilient than networks that do. I believe the cost of running the internet should not fall entirely on whoever happens to be in the middle.
A bet is about a specific product, a specific team, a specific moment. When we evaluated peer-to-peer for Circo, the question was never whether the beliefs were right. It was whether this architecture, for this product, this year, delivered the promises we were making to creators: that their messages arrive, their accounts can be recovered, their communities can be kept safe and their paid videos can only be watched by the people who paid.
For those promises, at that time, a different architecture was the better bet. That does not weaken the belief. Confusing the two is how teams end up either shipping their ideology or abandoning their convictions at the first hard result.
What peer-to-peer is genuinely for
The exploration left me with a clearer picture of where peer-to-peer is not just viable but better.
Products where ownership by the users is the promise. A private messenger whose whole point is that no company holds your conversations. A collaboration tool where your documents live on your devices first. For these, a peer-to-peer design is not a trade-off; it is the product.
Sharing the load of popular content. A swarm is at its strongest when many people want the same thing at once. As a layer on top of an origin that guarantees availability, peers can carry a meaningful share of a popular video. The origin keeps the promise; the swarm reduces the cost of keeping it.
Distributing software itself. Pear's model of distributing applications by a link, loaded from peers, is one of the most interesting ideas in the stack, and it fits a world where software updates are constant and centralised app distribution is a choke point.
Resilience. Systems that keep working when a central party fails, or refuses, matter more each year, in Africa as much as anywhere.
None of these is speculative. They are the cases where the always-on node that every system needs can be small, blind or owned by the users themselves.
What changed in how we work
The experiments changed Circo's engineering more than any one decision did.
We think of messages as signed facts rather than rows, and we build delivery to be safe to retry. We design from the offline case first. We separate access from custody, which is why our protected video is the same encrypted bytes for every viewer and only the licence decides who watches. We treat provenance as its own problem, which is why it gets its own layer.
It also changed how I lead evaluations. With a sixteen-person engineering organisation there is no room for research for its own sake, and no excuse for refusing to learn. The pattern we use now came out of these experiments:
- Write the question first. Not "should we use peer-to-peer" but "can a fan's message reach a creator whose phone has been asleep all day".
- Find the always-on node. Every design has one. Ask who owns it, who runs it and what it is allowed to know.
- Build the smallest real thing. A demo answers the easy case. The product lives in the cases the demo leaves out.
- Write down what you learned. Especially when the answer is "not here, not yet". That document is worth more than the prototype.
Respect for the people building it
I want to be clear about Holepunch and the wider peer-to-peer community, because a series like this can easily read as a verdict on them. It is not.
Their documentation is unusually honest about the hard parts. It says plainly that data is only available while a peer that holds it is online. It explains blind peering as the mechanism that restores the server role in a serverless design. It does not pretend that holepunching works on every network. That honesty is what made our evaluation possible. We could test the claims precisely because the claims were precise.
The choices we made reflect Circo's product, not the quality of their work. A different product, with a different promise, would choose differently, and should.
Where I think this goes
I do not think the future is peer-to-peer versus servers. I think it is hybrid, and the interesting work is in deciding which layer each promise belongs to.
Accountable services where safety, payment and recovery demand them. Peers where ownership, resilience or shared load are the point. Signed records, provenance and verifiable logs running through both, so that trust does not depend on which path a piece of data took.
A decision like ours should also say what would reopen it. If phones let a peer stay useful in the background without spending a user's battery and data, if always-on blind peers become something anyone can run as easily as a website, if creators start asking to hold their own libraries, the calculation changes. Those conditions are written down next to the decisions they would reopen. A good architecture decision is not a door you close. It is a door you know how to open again.
We chose different architectures for Circo. We did not choose a different belief. The work is to keep holding both, and to know, every time, which one is speaking.