Most remote desktop tools work the same way: your screen is captured, sent to a cloud server, and then forwarded to whoever is watching. It works, but it comes with tradeoffs that most vendors don’t talk about.

We went a different way. SeerDesk sessions are peer-to-peer. Your screen data goes directly from the host machine to the viewer, no relay server in between. Let us explain why.

The latency problem with relayed connections

When your video stream bounces through a central server, every frame picks up extra round-trip time. Even with servers in the same region, you’re adding 20-50ms on top of the natural network latency between you and the host. For a spreadsheet, that’s fine. For CAD software, video editing, or anything interactive, it’s the difference between feeling local and feeling remote.

With peer-to-peer, the stream takes the shortest path the network allows. Same LAN? The stream stays on the LAN. Across the country? It crosses the internet once, not twice.

In practice, SeerDesk sessions typically run under 30ms on local networks and under 80ms across regions. Fast enough that most users forget they’re working remotely.

What “zero-knowledge” actually means

When we say our servers never see your screen content, we mean it literally. The video stream is encrypted end-to-end between the host and the viewer. Our signalling server helps the two sides find each other and set up a connection, but once the session starts, it steps out of the way.

The streaming encryption keys are established during the WebRTC handshake between the host and the viewer. Our API handles signalling and authentication, but the media encryption is negotiated at the transport layer between the two endpoints. We don’t hold the keys to your video stream.

If you’re in healthcare, finance, legal, or defense, this changes the conversation. You don’t have to trust our security posture for your streaming data, because your streaming data never touches our infrastructure.

What about NAT traversal?

The obvious question with peer-to-peer: what happens when both sides are behind NAT? This is where most P2P solutions fall apart.

We use STUN for NAT discovery and ICE for candidate negotiation. In most cases, peers establish a direct connection even through corporate firewalls. When both sides are behind symmetric NAT (the most restrictive type), we fall back to a TURN relay. But that’s the exception, not the default.

We also built an entire testing infrastructure using Linux network namespaces to simulate every NAT type combination: full cone, restricted cone, port-restricted cone, symmetric. We test all of them. This isn’t something we leave to chance.

The cost angle

There’s a business reason too. Relayed architectures scale linearly with usage. Every active session eats server bandwidth. For a provider running thousands of concurrent sessions, that’s a big infrastructure bill that gets passed on to customers.

With peer-to-peer, our server costs stay nearly flat no matter how many sessions are running. The bandwidth is carried by the peers themselves. That’s how we keep pricing competitive without cutting corners.

The tradeoffs we accept

Peer-to-peer isn’t free of downsides. It makes some things harder:

• Session recording needs a dedicated recording participant instead of a server-side tap
• Network diagnostics have to be done from the client side since we can’t inspect traffic in transit
• Connection setup is more complex than just pointing both sides at a relay

We think the latency, privacy, and cost benefits are worth it. But we’d rather be upfront about these tradeoffs than pretend P2P is better in every way.

What this means for you

If you’re evaluating remote desktop solutions, ask your vendor where the video stream actually goes. If the answer is “through our servers,” ask why, and what that means for latency, privacy, and your data sovereignty obligations.

Want to see it for yourself? Get in touch and we’ll run a demo on your own network so you can see the numbers firsthand.