“Why not use P2P for screen sharing?” sounds like a networking question. It is really a product question.
Peer-to-peer, or P2P, means the live media can travel directly between participants instead of through a service that handles the media. That arrangement fits Linkside: a free room permits one host and one guest, while a private room permits one host and up to three guests. Linkside does not record sessions, transcribe audio, or analyse the shared screen.
Those choices make a direct-first path practical for the product we built. A product that must create cloud recordings, provide transcripts, or serve a much larger audience has a different job. Its media path deserves a different design. P2P is a tradeoff, not a badge of virtue.
Peer-to-peer does not mean server-free
Every Linkside room uses a signaling service to create the room and introduce the browsers. The service passes WebRTC offers, answers, and connection candidates between participants. Those are setup messages; the screen and audio tracks do not pass through the signaling service.
After that introduction, the browsers try to establish a direct WebRTC media path. If the networks block it, Linkside can fall back to TURN, a relay that forwards the packets. The media stays encrypted in transit, and the DTLS-SRTP keys remain in the participants’ browsers rather than on the relay.
That is why we say peer-to-peer first, not peer-to-peer only. Linkside always needs signaling, prefers a direct media path, and uses encrypted relay fallback when needed. Our signaling-server explainer separates those jobs in more detail. STUN vs TURN explains how browsers find a route and what changes when a relay is required.
Some features change the media path
The useful question is not “Is P2P better?” It is “What must this product do with the media?”
Cloud recording
To create a cloud recording during a room, Linkside would need a service-controlled recorder with access to usable media. Another design could record in a participant’s browser and upload the finished file. Linkside implements neither path.
Either option would create a stored session artifact. We would then need to decide who could access it, how long to keep it, and how to delete it. Linkside avoids those questions by not offering recording.
Service-provided transcription
A service-provided transcript also needs a new processing path. A product could send usable audio to a transcription service, or transcribe in a participant’s browser and upload the text. The first design gives another service access to session audio. The second still creates session content that needs storage and access rules.
Linkside does neither. It does not transcribe audio or analyse the shared screen, so it creates no transcript or screen-derived artifact to store after the room.
Large audiences
Linkside creates one WebRTC peer connection for each active guest and adds the host’s screen and audio tracks to each connection. In plain English, every admitted guest adds another connection and another outbound media path from the host’s browser.
Linkside bounds that fan-out: one guest path in a free room, or up to three in a private room. If we redesigned Linkside for a much larger audience, we would revisit that topology instead of assuming the host should connect directly to every viewer. A service-controlled media system could receive a contribution and distribute it downstream, moving work away from the host while placing that service in the media path.
What Linkside’s smaller scope means for trust
Linkside caps a free room at two participants and a private room at four. It requires no account or email address and has no recording library, transcript history, or session-content archive.
Its current features do not require Linkside’s services to receive decryptable media. When a direct connection succeeds, the media path runs between participants. When TURN is needed, the relay can see packet routing but does not hold the browser-managed media keys.
This does not mean Linkside learns nothing about a session. The signaling service observes that a room exists, its temporary room state, the rough timing of guest joins, and the session duration. When relay fallback is used, Cloudflare’s edge sees IP-level traffic to the relay endpoints. These systems need that routing information to operate, but neither the signaling service nor the relay sees the screen or audio content.
Room metadata is temporary too. An open room expires after 15 minutes without activity. An ended or expired room enters a five-minute tombstone window, then its record is removed on the next lifecycle check.
Linkside is not the right tool when you need a recording, transcript, webinar audience, persistent workspace, or administrative archive. We list those boundaries plainly in what Linkside deliberately doesn’t do.
Choose the product promise first
A service-controlled media path can be a sensible choice when a product must create cloud recordings, produce transcripts as a service, or distribute one contribution to more viewers than its direct topology supports. Those features require clear decisions about media access, storage, and retention.
Linkside makes a narrower promise: show a screen to at most three guests, talk through it, and end the room without creating a recording or transcript. P2P-first fits that promise. It would not automatically fit a different product with a different set of features.
Architecture is only part of the trust question. What a service collects, what it stores, and how long it keeps that data matter too. For the exact encryption boundary, read what WebRTC actually guarantees.
If Linkside’s smaller, temporary-room model matches your job, create a room and share the link.