“Can I just show you?” usually means right now. The thing might be a bug, a draft, or a chart that makes no sense without a live explanation. Every extra step between that impulse and a visible screen can drain it. After enough steps, a live conversation turns into a screenshot and a long message.
That cost is the friction tax. It is not only the number of seconds a form takes. It is the typing, waiting, decisions, and context switches imposed before either person reaches the reason they opened the tool.
The cost is attention, not just time
Nielsen Norman Group defines interaction cost as “the sum of efforts — mental and physical — that users must deploy in interacting with a digital product in order to reach their goals.” Clicks count, but so do reading, typing, waiting, remembering, and switching attention.
A signup detour can combine several of those costs. Choose an email address. Create or retrieve a password. Leave the page to find a verification message. Return and work out where you were. None of those actions helps the other person see the screen.
NN/g’s classic response-time guidance says a system response of about one second is the limit for keeping a user’s flow of thought uninterrupted. That is guidance about response time, not proof that every task longer than a second loses a user. It does explain why added waits matter: each one creates another chance for attention to move elsewhere.
The same researchers are blunt about gated access: “we rarely have seen users more annoyed than when they come across a login wall”. Their examples concern access to content, and they make room for accounts where identity is inherent, such as email or banking. This is not screen-sharing conversion data. It is a useful design warning: ask for identity only when the task actually needs it.
The closest measured comparison is checkout
The research gathered for this post did not turn up rigorous funnel data for collaboration-tool signups. The closest well-measured comparison in our sources is e-commerce checkout: another moment when someone has started a task and a form stands between intent and completion.
Baymard Institute’s aggregation across 50 studies puts the average documented cart-abandonment rate at 70.22%. In Baymard’s survey of US shoppers who abandoned an order during checkout, excluding people who were just browsing, 19% cited “the site wanted me to create an account.” Another 18% cited a checkout process that was too long or complicated.
Baymard’s separate checkout-form research found an average of 11.3 fields in US checkout flows in 2024, while its testing found that most sites need about eight. Its finding is directional: checkout usability gets worse as the number of fields grows. It does not support a claim that each extra field costs a fixed percentage of conversions.
These numbers do not mean 19% of screen-sharing guests will leave at a signup wall. Shopping and collaboration are different tasks. What they do show is that forced account creation can stop people who have already started checkout. A spontaneous screen share gives the guest less reason to tolerate a detour: they did not choose the tool and may only need it for a few minutes.
Your guest did not choose the tool
The host may accept setup because they picked the service and expect to use it again. A first-time guest has a different calculation. They received a link because someone else wants to show them something.
If that link opens a generic account-gated flow, the guest may be asked for a name, email address, password, magic-link round trip, human check, or download before they can join. Not every product asks for all of these, and a returning user may already be signed in. The underlying problem is still the same: the host’s product choice becomes the guest’s setup task. The no-install side of that problem adds another kind of friction.
For a quick share, the most useful question is simple: what must a first-time guest do before they can see the screen?
What Linkside’s link-first flow asks of you
We cannot support a percentage-per-step decay curve, but we can count the current Linkside flow.
For a host, there are four stages: open the create page, select Create room, select Start sharing, then choose and confirm a tab, window, or screen in the browser’s picker. The create page has no required fields. It offers an optional waiting room, and licensed users can add an optional room password. Hosting works in the browser with no download, extension, or plugin; desktop Chrome and Edge are the recommended host experience.
For a guest using the invite URL, the room code is already filled in and a random nickname is already generated. The page checks that the room exists. With the default settings, the guest opens the link and selects Join room without typing anything. A password-protected room requires the password, and a waiting room requires the host’s approval. There is no Linkside registration, email gate, or captcha in the join flow. You can compare the steps with the timed room walkthrough.
No account also means Linkside does not require either person to provide an email address, real name, or phone number to create or join a room. Participants use temporary room-scoped identifiers instead of a lasting user profile.
Less friction still needs a clear trust boundary
Removing signup does not, by itself, make a screen share private. The media path and what the service retains matter too.
Linkside is peer-to-peer first: it tries to establish a direct WebRTC connection between the browsers. If a restrictive network blocks that route, it falls back to a TURN relay. WebRTC encrypts the media in transit on both paths. The relay forwards encrypted packets and does not hold the media keys.
Peer-to-peer first does not mean the service learns nothing. Linkside’s signaling service observes that a room exists, roughly when guests join, and how long the session lasts. A relay sees the routing of encrypted packets, and Cloudflare’s edge sees IP-level traffic to the relay endpoints. Those services cannot read the screen or audio media. Linkside does not record sessions, transcribe audio, analyze the screen, or keep persistent chat logs.
That distinction is more useful than a blanket promise of invisibility: the session needs temporary coordination, but its content is not stored as an account history.
What we traded away
No accounts means no list of past rooms, no session history, and no account-recovery path. If you lose a live room link, you create another room. Room state is temporary: inactive rooms expire after 15 minutes, pass through a short five-minute tombstone period, and are then deleted. The reasoning behind the no-account trade goes into more detail.
The limits should be just as clear. Free rooms support up to two active participants. Direct connections do not need a license, but a free room that has to use the encrypted TURN relay gets a five-minute relay trial. A license unlocks unlimited relay use, room passwords, and up to four active participants. In the app, that license is a key, not a Linkside account.
The link is the room
A link is not proof of privacy, and a short flow is not proof of good security. The useful combination is narrower: no account gate, temporary rooms, a direct media path by default, encrypted relay fallback, and an honest description of the metadata needed to run the service.
That is what link-first design should buy: less ceremony without asking you to take the trust model on faith. The next time someone says “can I just show you?”, create a room and count what the host and guest actually have to do.