If you are deciding whether to trust a screen-sharing service, “privacy-first” is not enough. You should be able to answer three simpler questions: Does it save my screen? What does its server know? What remains after I leave?
For Linkside, the short answer is: no recording or transcript, temporary room state, a few browser settings, and limited operational analytics. The word “almost” in the title matters, so here is the longer answer.
Your screen and audio are not stored
Linkside tries to send media directly from the host’s browser to each guest using WebRTC. If a restrictive network blocks that direct path, Linkside can use an encrypted TURN relay instead.
In both cases, the media is encrypted in transit with DTLS-SRTP. The browsers handle the encryption keys; no Linkside-side server holds them. A relay can see where encrypted packets are coming from and going to, but it cannot read the screen or audio inside them.
Linkside does not record sessions, transcribe audio, or analyse what appears on screen. It also does not save chat messages. In-session chat travels between peers and remains in browser memory only for that session.
Temporary room state on the signaling service
The browsers still need help finding each other and negotiating a connection. Linkside’s signaling service does that job. It stores one temporary room record in a Cloudflare Durable Object.
That record contains:
| Temporary data | Why it exists |
|---|---|
| A random 10-character room ID | Routes participants to the same room |
| Participant IDs, nicknames, roles, and current status | Shows who is present and enforces room rules |
| Opaque participant secrets | Authenticates signaling messages |
| Room controls | Records the transport mode, lobby setting, capacity, and a password hash when a host sets a room password |
| A bounded recent-event buffer | Lets a reconnecting browser catch up on presence and connection-setup messages |
| Timing and room counters | Tracks creation, activity, relay-trial state, joins, and peak participation |
| Host country code, when available | Supplies the coarse country value used in room analytics |
The recent-event buffer deserves a closer look. It can hold WebRTC setup messages such as offers, answers, and ICE candidates. Those messages do not contain screen or audio content, but connection details can include network addresses. They are part of the temporary room record and are deleted with it; Linkside does not copy those raw details into its analytics dataset.
Room cleanup follows two paths:
- If the host ends the room, it becomes unavailable immediately. A terminal marker remains for 5 minutes so a late request can receive a useful “room ended” response, then the room record is deleted.
- If an open room receives no activity for 15 minutes, it expires. Its terminal marker remains for another 5 minutes, then the record is deleted.
The signaling worker has no separate KV, D1, or R2 database containing room history. Deleting the room record removes its participant list, secrets, password hash, setup messages, and other room state.
A few things stay in your browser
Linkside uses browser storage for settings and short-lived session credentials:
| Browser storage | What it keeps | Lifetime |
|---|---|---|
localStorage | Theme, playback volume, and whether the chat panel was open | Until you clear site data |
localStorage | A paid license key and its activation instance ID, if you save a validated license | Until invalidated or you clear site data |
sessionStorage | Participant secret and room transport mode | For that browser tab’s session |
sessionStorage | A sanitized ?ref= campaign label, if the link included one | For that browser tab’s session |
The campaign label is not a person or device ID. If that tab later hosts a room, Linkside includes the label in the host’s session-outcome event so it can measure whether an outreach link led to a real session. Guests do not send it.
There is no persistent Linkside user ID or account cookie connecting one room to the next. The browser also does not write the screen or audio stream to local storage, session storage, IndexedDB, or a local file.
Operational analytics outlive the room
Deleting room state is not the same as deleting every operational measurement. Linkside writes constrained events to Cloudflare’s Analytics Engine so it can measure whether sessions connect and where the product fails.
Depending on the event, those datapoints can include:
- the room ID and a fresh, per-join participant ID;
- host or guest role;
- a two-letter country code supplied by Cloudflare;
- browser family and final media state;
- the type of connection found, such as direct or relay;
- relay-trial and license status;
- connection failures, reconnect attempts, and time to first frame;
- session duration, total joins, and peak participant count;
- whether the room ended or expired; and
- the host’s campaign label, when present.
These are per-room operational records, not recordings or transcripts. Room and participant IDs allow events from one room to be related to each other, but they are newly generated rather than reused as cross-session user IDs.
The analytics schema excludes IP addresses, raw User-Agent strings, hostnames, ports, participant nicknames, room passwords, and finer location data. Country is the only stored geographic field. Analytics Engine is append-only, and its datapoints remain under Cloudflare’s retention policy after the temporary room record has been deleted.
Site page-view and performance measurements
The live Linkside site loads a Cloudflare Web Analytics beacon for page-view and performance measurements. This is separate from the room lifecycle analytics above and does not create a session recording.
IP addresses at the service edge
Any internet service receives IP-level traffic. Cloudflare’s edge sees requests to Linkside’s signaling and relay endpoints, and the relay sees the routes taken by encrypted packets.
Linkside also uses the client IP as the key for temporary, in-memory abuse limits on actions such as creating or joining rooms and requesting relay credentials. Most buckets use short windows; the free relay trial uses a longer two-hour window to prevent repeated trials from the same network. These rate-limit entries are not written to room storage or the analytics dataset, and they are not paired with an account identity.
What Linkside does not keep
- No recordings or screen captures. There is no recording feature or media archive.
- No transcripts or screen analysis. Linkside does not transcribe audio or inspect screen contents.
- No chat history. Messages disappear with the in-session browser state.
- No account profile. A room nickname is temporary room data, not an account identity. Linkside does not require an email address or phone number.
- No session history. There is no dashboard of previous rooms or searchable participant directory.
- No advertising or data sales. Linkside does not show ads, sell data, or share session data for advertising.
For more on these product boundaries, read what Linkside deliberately doesn’t do and why Linkside requires no account.
What this means in practice
Linkside cannot produce a recording, transcript, or chat history that it never creates. It may still have an operational record showing that a room existed, roughly how long it ran, its country and browser categories, and whether it connected directly or through a relay.
That is the honest meaning of “almost nothing”: session content is not retained, while the minimum room machinery and limited service measurements are acknowledged rather than hidden behind a slogan.
One final boundary is outside Linkside’s control. A guest can photograph or record what appears on their own device. Encryption protects the journey between browsers; it cannot make an untrusted viewer trustworthy. Share only with people you trust.
If that tradeoff fits what you need, open a room.