Most screen sharing starts with a sentence that should be simple: “Let me show you.”
Then the setup starts. You find the right app. Maybe there is an account step. Maybe there is a download. Maybe the meeting UI wants camera and microphone decisions before anyone has seen the thing you were trying to show.
The useful part is much smaller than the machinery around it: a few people looking at the same screen, right now.
Linkside exists for that moment. Create a room, send the link, share your screen. No account. No download. No recording.
The Problem Was Shape
When screen sharing is shaped like a meeting, the extra structure can be useful: calendar invites, participant controls, admin settings, optional records, and a room that can be found again later.
Linkside is shaped like a quick show-and-tell. The job is narrower:
- The host opens a room.
- The guest opens the link.
- The host picks a tab, window, or screen.
- Everyone leaves when the useful part is over.
That narrower shape is the product decision. We are not trying to replace full meeting suites. We are trying to make the short live-share case feel closer to sending a link.
Privacy Starts With Not Collecting
The privacy instinct behind Linkside is simple: the best stored data is the data we never collect.
That shows up in the product in a few concrete ways:
- No accounts, so there is no email, phone number, password, or profile to create.
- No signup wall for guests, so joining does not start with an identity check.
- No recordings, so there is no recording library to protect later.
- No persistent chat logs or session history.
- Rooms are temporary. Live room state exists to run the session, then moves through a short cleanup window and is deleted.
This does not mean Linkside knows nothing while a session is happening. To operate the service, the signaling worker has to know that a room exists, roughly when guests join, and how long the session runs. If the connection uses the relay fallback, the relay routes encrypted packets. Cloudflare’s edge also sees IP-level traffic to the relay endpoints.
Those are real operational facts, so they are worth saying plainly. The privacy claim is not magic invisibility. It is that Linkside does not store your screen content, does not record the session, does not build an account profile around the people in the room, and does not keep session content after the room is gone.
Peer-to-peer-first, not peer-to-peer-only
The default media path in Linkside is direct browser-to-browser WebRTC. When that works, your video and audio travel from the host browser to the guest browser without a Linkside media server in the middle.
But direct browser-to-browser networking does not always work. Firewalls, restrictive networks, and some NAT setups can block the direct route. If Linkside were peer-to-peer-only, those sessions would fail.
So Linkside is peer-to-peer-first, with an encrypted TURN relay as the fallback. The relay is there for connectivity, not access. Media is encrypted by the browser before it leaves, and Linkside does not hold the media keys. On the relay path, the relay routes encrypted packets; it does not get a readable copy of your screen.
That tradeoff matters. Peer-to-peer-only is cleaner as a slogan. Peer-to-peer-first is more useful on the real internet. If you want the network version, STUN vs TURN explained walks through the moving parts.
Small groups, deliberately
Linkside is for a few people you trust, not a webinar room. Free rooms allow one host and one guest. Licensed rooms allow one host and up to three guests.
That cap keeps the product honest. A twenty-person meeting needs different tools: moderation, larger-room reliability, support expectations, and probably a different business behind it. Linkside is built for cases like:
- Helping someone debug a setting.
- Walking a client through a draft.
- Pairing on code for half an hour.
- Showing a friend the thing you just built.
Those cases do not need a large meeting platform. They need a fast path from “can I show you?” to “yes, I can see it.”
The Browser Constraint
Linkside runs in the browser. There is no desktop app, extension, or plugin to install for hosting or joining.
That browser-first choice also has a boundary. Desktop Chrome and Edge are the recommended host experience. Firefox and Safari can host with caveats. Mobile browsers are usually better as guests than hosts.
That is not a footnote. It is part of the trust story. A product earns trust by saying where it works well and where it does not.
The Solo-Maintainable Bet
Linkside is built by one person, and it is meant to stay understandable and operable by one person. That constraint shapes the product as much as the privacy choices do.
A solo-maintained product cannot promise every meeting feature, every browser edge case, and a 24/7 support desk. So Linkside stays smaller:
- Small rooms.
- Temporary sessions.
- Browser-first sharing.
- No account system.
- No recordings to store or manage.
- Relay fallback only when the direct path fails.
That list is not a lack of ambition. It is the operating model. A smaller product can be easier to reason about, easier to keep private, and faster to use.
The bet
The bet behind Linkside is that enough people want the link-first version of screen sharing. Not a meeting. Not a recorded walkthrough. Not a heavy collaboration suite. Just a private room for a few people who need to see the same screen for a short time.
If that is right, Linkside can stay small, useful, and honest about what it does. If it is wrong, we still built the tool we wanted to use.
If you want to see whether it fits your version of the problem, open a room and send the link to the person you were about to schedule a meeting with. For the account decision, read why Linkside requires no account.