Why Peer-to-Peer Video and Content Moderation Fight Each Other
There is an architectural conflict sitting inside most live video products, and it usually surfaces late, around the time somebody in legal asks how sessions are monitored.
The short version: if media flows directly between two browsers, your servers never see it. That is the entire selling point of peer-to-peer WebRTC, and it is also the reason server-side moderation cannot work on it. You cannot scan what does not arrive.
Most teams discover this after they have built the fast, cheap version.
What Actually Happens On the Wire
The Baseline Case
For two participants, plain WebRTC is close to ideal. Signaling goes through your server, a session description gets exchanged, ICE candidates get gathered, and then the media stream establishes directly between the peers. STUN handles NAT traversal for most connections. TURN relays the ones that fail, which is typically somewhere between 8 and 20 percent depending on your user base and how many are behind symmetric NAT or corporate firewalls.
Your bandwidth cost for a successful P2P session is roughly zero. Your latency is the best you will ever get, because the packets are not making a detour.
Where It Stops Scaling
Add participants and mesh topology gets expensive fast. Each peer maintains a connection to every other peer, so upload requirements scale linearly per client and connection count scales quadratically overall. Four participants is usually fine. Six is where laptops start getting warm. Eight is where you begin fielding support tickets about fans.
This is the point where teams move to an SFU, a Selective Forwarding Unit. Each client sends one stream up, the server forwards what each participant needs. Server bandwidth cost appears, latency increases slightly, CPU stays reasonable because the SFU forwards rather than transcodes.
The Option Nobody Picks Twice
An MCU mixes all incoming streams server-side into a single composited output. Bandwidth to each client drops to one stream, which is genuinely useful on poor connections. The cost is transcoding, which means CPU per room rather than bandwidth per room, and CPU is the more expensive resource by a wide margin.
| Topology | Server bandwidth | Server CPU | Media visible to server | Practical ceiling |
|---|---|---|---|---|
| P2P mesh | None | None | No | 4 to 6 peers |
| SFU | High | Low | Yes | 50+ peers |
| MCU | Moderate | Very high | Yes | Cost-limited |
That “media visible to server” column is the one that turns into a policy problem.
The Moderation Problem This Creates
You Cannot Moderate What You Never Receive
Post moderation is a solved shape. Content arrives, sits in storage, gets classified, and a decision happens before or shortly after publication. The latency budget is generous. You can queue, retry, and escalate to a human.
Live video has none of that. There is no artifact at rest, the harm happens during transmission rather than after it, and on a P2P connection the media never enters your infrastructure at all. Your options collapse to two.
Route the Media, or Run Inference on the Client
Routing through an SFU gives you frames to classify. It also means accepting bandwidth cost per session, adding a hop of latency, and abandoning the claim that media is not touched by your servers, which is a real cost if privacy was part of your positioning.
Client-side inference keeps the P2P path intact. A model runs locally, flags frames, and reports metadata rather than content. It preserves the privacy story and adds no server bandwidth. It is also running on hardware you do not control, in an environment a determined user can tamper with, and the model has to be small enough to run in a browser tab without destroying frame rate.
Neither option is clean, and choosing between them is a product decision dressed as an infrastructure one.
Why This Is Becoming Urgent
Regulators have started treating live conversation platforms as in scope rather than adjacent. Ofcom’s June 2026 online safety bulletin recorded £2.17 million in penalties and five new investigations, two of them into chat services, examined over grooming risk and exposure to minors. One fine, £540,000 against 4chan, was specifically for failing to conduct an adequate illegal content risk assessment.
The relevant detail for engineers is that a risk assessment requires you to describe your moderation capability. “Media is end-to-end between peers and therefore unmonitored” is an accurate description of a P2P architecture and an unhelpful answer to a regulator.
Which means the architecture choice now carries compliance weight it did not carry three years ago. Consumer platforms in the one-to-one space, from language tutoring to a video call random girl service, sit in exactly this bracket, because their default session is two people and P2P is the obvious build.
What A Workable Design Looks Like
What tends to hold up combines both approaches rather than choosing.
Keep P2P as the default path for the media itself, since it is cheapest and fastest and there is no reason to give that up. Run lightweight client-side classification on sampled frames, not every frame, reporting scores rather than images. Set a threshold that promotes a session to SFU relay when the client-side signal crosses it, so that server-side review only costs bandwidth on sessions that warranted it.
Then design the pre-session layer properly, because that is where most of the actual risk reduction happens and it costs nothing in latency. Age assurance before access. Video off or blurred until both parties act. Blocking that takes effect immediately rather than after a queue. None of that requires seeing a single frame.
The engineering instinct is to treat safety as something layered on after the media pipeline works. On live video that ordering does not survive contact with the problem, because the pipeline you build determines which safety options remain available to you. Deciding to relay media later means rebuilding the transport layer, and nobody has budget for that in the quarter a regulator asks.
Worth working out which topology you are committing to before the first user session, rather than after the first risk assessment.