“Can I show you something?” is a now question. An installer, signup form, settings page, or calendar invite turns it into a later question.
We built Linkside to keep the answer in the present: create a room, send the link, and share from the browser. For the person using it, that feels like zero setup. For the product, it means taking responsibility for the setup instead of handing it to the user.
The four axes of setup
“Zero setup” is really four promises.
No install
The host and guest both use the browser. There is nothing to install, no extension to approve, and no separate app to keep updated.
No account
Neither person needs to create an account or provide an email address, name, or phone number. The guest gets a temporary nickname and can change it. That accountless design is deliberate: a short-lived screen share does not need a lasting identity.
No configuration
The create page has no required fields. A host can choose optional controls such as a waiting room or a licensed room password, but the normal path works with the defaults.
No scheduling
You create a room when you need it and share the URL through whatever message you already use. Linkside does not create a standing meeting or a calendar object. When the session ends, the room does not become part of a history or reusable room list.
What the result looks like
The host selects Create room, then Start sharing, and chooses a tab, window, or screen in the browser’s picker. The guest opens the invite link and selects Join room. The URL already carries the room code, Linkside checks that the room exists, and a nickname is ready. A guest may need a password or host approval only if the host enabled those controls. We have a separate short walkthrough; the point here is what makes this path possible.
The platform shift that made zero-install possible
Two browser capabilities do much of the visible work. WebRTC lets browsers exchange real-time media without a plugin. getDisplayMedia() asks the browser to show its own screen picker and return the surface the user selects. Desktop support for that picker arrived across the major browsers around 2019 and 2020.
Those APIs make browser-only screen sharing possible. They do not choose sensible network defaults, handle blocked direct connections, explain browser limitations, or clean up temporary rooms. Linkside still has to do that work. For more background, see what WebRTC is and why it matters.
Zero setup is not zero consent
Removing setup must not remove the user’s choice. The W3C screen-capture standard says a browser must not save a permanent “granted” permission for display capture. It must let the user choose from the available screens and windows each time, and a site cannot silently choose a particular surface for you. Capture must also begin from a user action in a secure context, normally an HTTPS page.
That prompt is a boundary, not unfinished setup. Because the permission does not persist, there is no standing screen-capture grant to remember or revoke later. Every share starts with a fresh choice in browser-controlled UI.
Where the setup went: our engineering budget
Every step the user skips needs a replacement. Here is what the current Linkside implementation provides:
| Setup you skip | What Linkside handles |
|---|---|
| Network configuration | Three STUN servers help the browsers find a direct route; a 10-candidate pool and 8-second timeout prevent an endless connection |
| A firewall troubleshooting guide | If a direct connection fails, the host client automatically requests one eligible 5-minute trial of the encrypted relay |
| A system-requirements page | The app checks browser capabilities and gives a specific next step when hosting or joining is unavailable |
| Choosing a display name | The guest gets one of 2,756 adjective-and-animal nicknames and can type another or shuffle |
| An appearance setting | The theme follows the operating system unless the user chooses a different one |
| Copying a meeting ID | The room code travels in the invite URL, and the join page checks it before the guest joins |
| Cleaning up old rooms | An inactive room expires after 15 minutes, followed by a 5-minute cleanup window |
The networking row matters most. Linkside is peer-to-peer first: it tries to send media directly between the browsers. Some corporate networks, firewalls, and network layouts block that route. If that happens, the host client can automatically request an eligible one-time, five-minute trial of an encrypted TURN relay; a licence removes the relay time limit. The relay forwards encrypted packets, but it does not get the browser-held keys needed to read the screen or audio. Media uses WebRTC’s DTLS-SRTP encryption on both the direct and relay paths.
Capability checks make the limits clear before someone gets stuck. Desktop Chrome and Edge are the recommended hosting browsers. Firefox and Safari can host with caveats. Supported mobile browsers can join as guests but cannot host, and in-app browsers are unsupported.
There is still service infrastructure. The signaling worker can observe that a room exists, roughly when guests join, and how long the session lasts. A relay, when needed, observes the routing of encrypted packets, and the edge provider sees IP-level traffic. These systems do not see the media content. Linkside does not retain that operational data long-term or pair it with an identity.
What zero setup costs
There are real tradeoffs. With no accounts or persistent rooms, there is no session history, saved room list, or past-participant roster. Lose an active invite link and the practical answer is to create a new room.
Free rooms support two active participants. A licence is a key, not an account; it raises the limit to four and enables room passwords and unlimited relay use. Mobile browsers are guest-only because the display-capture API is not supported there. Desktop Firefox and Safari hosting may have quirks. And the browser asks what to share every time. That last step is the consent model working as intended.
Linkside also does not record sessions, keep chat logs, or analyse what appears on screen. Rooms are temporary, and session content is not stored for later.
A feature you build, not a feature you skip
The useful measure of no-setup screen sharing is the distance between “can I show you?” and a picture on the other person’s screen. Shortening that distance takes defaults, fallbacks, honest compatibility checks, temporary rooms, and a fresh consent choice every time.
Create a room and try the short path yourself.