Popularity is peer-to-peer's best case. Phones, the live edge, quality levels and the long tail are where it gets hard, and they decide whether a swarm can carry a creator platform.
Dennismary Chidiebere24 November 20255 min read
Operator Notes
Get the next essay in your inbox.
Field notes from building, deciding and carrying the cost of clarity.
Here is a thought experiment we ran on a whiteboard this year, and that I now use to test any distribution design.
A creator schedules a premiere. At eight o'clock, 100,000 people press play on the same video at the same time. Now suppose the only thing delivering that video is the audience itself: a peer-to-peer swarm, every viewer downloading pieces from other viewers and serving what they already have.
What happens?
This is a scenario, not a test. We never put 100,000 viewers on a swarm, and the numbers in the model below are assumptions you can change, not measurements. The value is in walking through it carefully, because every step exposes a different property of peer-to-peer delivery.
The good news comes first
Popularity is peer-to-peer's best case. That is the insight BitTorrent was built on, and it holds.
In a server design, every new viewer is a new cost. A hundred thousand viewers means a hundred thousand streams leaving your infrastructure. In a swarm, every new viewer is also a potential source. Demand and supply grow together. The more people want a piece of the video, the more people hold it.
So the naive fear, that a swarm collapses under a big audience, is wrong. A big audience is when a swarm looks its most impressive. The hard parts are subtler, and they are what decide whether the design can carry a real product.
Who can actually upload
A swarm is only as strong as the peers that can serve. Every viewer downloads; far fewer can upload well.
Reachability. Two peers have to be able to connect. Holepunch's distributed hash table punches through home routers so connectivity "works on most networks". Most is the important word. Some networks, especially carrier networks that put many phones behind one shared address, make direct connections hard, and the public documentation does not promise what happens there. Browsers add another constraint: a browser peer speaks WebRTC, and in WebTorrent's own words it "can only connect to other clients that support WebTorrent/WebRTC".
Phones. Uploading video costs battery and, for most people, metered data. Mobile operating systems suspend background networking to protect both. A viewer watching on a phone is a viewer who is mostly taking from the swarm, not giving to it, and asking them to give more means spending their battery and their data plan on strangers.
The shape of the audience therefore matters more than its size. A hundred thousand viewers on desktops with home broadband is a strong swarm. A hundred thousand viewers on phones, many of them on mobile data, is a weak one, however large.
The Swarm
An illustrative model of a peer-to-peer swarm delivering one video. Choose the audience size, whether they watch together or over months, how many are on phones and whether always-on nodes back the swarm, then see who serves the video and where it stalls.
The Swarm
An illustrative model of a peer-to-peer swarm delivering one video. Choose the audience size, whether they watch together or over months, how many are on phones and whether always-on nodes back the swarm, then see who serves the video and where it stalls.
An illustrative model of a peer-to-peer swarm delivering one video. Choose the audience size, whether they watch together or over months, how many are on phones and whether always-on nodes back the swarm, then see who serves the video and where it stalls.
Interactive figure: The Swarm. An illustrative model of a peer-to-peer swarm delivering one video. Choose the audience size, whether they watch together or over months, how many are on phones and whether always-on nodes back the swarm, then see who serves the video and where it stalls.
An illustrative model, not a measurement: change who is watching and when, and watch the share carried by peers rise, fall and run out.
Fig. 1The Swarm. An illustrative model, not a measurement: change who is watching and when, and watch the share carried by peers rise, fall and run out. Open the full exhibit
The live edge, the quality ladder and churn
Three properties of real video make a swarm's job harder than sharing a file.
The live edge. A premiere is a moment everyone shares. That is the point of it. But at the live edge, the newest segment is the one every viewer wants at the same instant, and at that instant almost nobody has it yet. Peer-to-peer shines when pieces have had time to spread; the live edge is the one place they have not. WebTorrent's documentation is direct about this: it "cannot do live streaming out-of-the-box", because a torrent is immutable.
The quality ladder. Streaming video is not one file. It is the same video encoded at several qualities, cut into short segments, so each player can pick the quality its connection can sustain from moment to moment. In a swarm, each quality is a different set of pieces. One large audience becomes several smaller swarms, one per quality, and a viewer switching quality jumps to a swarm where they hold nothing.
Churn. Viewers leave. They skip ahead, lose signal, lock their phones. In a swarm every departure removes a source. At a premiere, churn is manageable because new viewers keep arriving. Afterwards, it is the whole story.
The long tail decides everything
The premiere ends. The video goes into the creator's catalogue.
Six months later, at three in the morning, one person in another time zone presses play. Nobody else is watching. Nobody nearby holds a single piece. The swarm, so impressive at eight o'clock, now has one member: the viewer who is waiting.
This is the case that matters most for a creator platform, because most viewing of most videos is not a premiere. It is the catalogue: thousands of videos, each watched by a few people at a time, at unpredictable hours. A piece of a peer-to-peer video is only available while some peer holding it is online. For the catalogue, that means something has to hold every piece of every video, all the time.
Holepunch's answer is the blind peer, an always-on peer that keeps encrypted blocks available. A BitTorrent-style answer is the dedicated seeder. Either way it is the same thing: infrastructure that never sleeps, holding the full catalogue. At that point you are running an origin, and the swarm has become an optional layer that helps when a video is popular.
What protection and moderation change
Two Circo-specific questions completed the picture.
Protection is compatible. Circo encrypts each video once, and every viewer receives the same encrypted segments; only the licence decides who can decrypt them. That design is friendly to a swarm. Encrypted segments can travel between peers without revealing anything, because the key never travels with them. The licence still comes from an always-on rights service, but the bytes could, in principle, come from anyone.
Removal is not. When a video has to come down, because the creator wants it gone or because it breaks the rules, every peer holding its pieces still holds them. A platform can stop issuing licences for a protected video, which makes the copies unwatchable. For anything unprotected, removal from a swarm is a request, not an action.
Used versus examined
It is worth being precise about what this exploration was.
What Circo runs in production: a conventional video pipeline, with uploads transcoded into adaptive streams at several qualities, delivered from a content network and protected by multi-DRM, with a rights service deciding every licence.
What we examined: signed logs and distributed file systems from the Holepunch stack, swarm discovery and holepunching through its distributed hash table, always-on blind peers for availability, and browser-based swarms in the BitTorrent tradition. We studied them, modelled them and tested their claims against our product. We did not put them in front of our viewers.
Where the thought experiment lands
A hundred thousand people watching at once is not where peer-to-peer fails. It is close to where it shines. It struggles with the audience on phones, with the live edge, with the split into qualities and, most of all, with the single viewer at three in the morning.
The honest conclusion is that peer-to-peer is an excellent way to share the load of a popular video and a poor way to guarantee that every video is always there. The first is an optimisation. The second is the product.
Build the origin first. Let the swarm help when it can.
Experiment 04 · Distribution
An origin, dedicated seeders or blind peers that never go offline.
Assumptions, not measurements: with few phones, 50% of viewers can upload; with most on phones, 12%. The video comes in 3 qualities, and from the catalogue about 30 of 100,000 viewers watch at any one moment.
Readout · illustrative
Watching at once
100,000
Able to uploadAssumption
50%
Served by peers
Waiting
Served by always-on nodes
Waiting
No source, stalls
Waiting
One video, delivered by its own audience. Choose who is watching, and when.
What happens, step by step
1
100,000 people press play on the same video at the same moment.
2
Nobody holds anything yet, so the first segments come from always-on nodes.
3
About 50% of viewers can accept connections and upload; the rest, on phones or hard networks, mostly take.
4
Peers pass segments to each other. In this model they carry 68% of what viewers watch.
5
Always-on nodes serve the other 32%. Nobody stalls, but the origin never goes away.