Someone invited to see a screen should not have to become a lasting member of a platform first.
Linkside keeps the job smaller. A host creates a room and sends its link. The guest opens it, accepts or changes a generated nickname, and joins without an account or an email step. A Private Room can also ask for the password set by the host.
The guest joins that room. They do not register with Linkside.
Guest access can mean three different things
“Guest” describes a role, not how long the product remembers someone. It helps to separate three access models.
A lasting account
An account gives a product a durable user record and a way to authenticate that person again. That makes sense when people need saved preferences, membership, recovery, or history across many sessions.
Those conveniences come with a longer relationship. The product must decide what identifies the person, what it retains, and how account recovery and deletion work. That can be worthwhile for ongoing collaboration. It is more than a one-off screen share needs.
An email magic link
A magic link sends a login URL to an email inbox. It removes the password field, but the guest still has to receive and open an email before entering.
This model makes control of the inbox the checkpoint. A product can also use the email address for later recognition or recovery if it chooses. Passwordless access is therefore not always accountless access.
Access to one room
Linkside scopes access to a temporary room. There is no guest profile to activate, inbox to check, or past-room dashboard to maintain.
That narrow scope fits jobs such as reviewing a layout, walking through a bug, helping a relative change a setting, or looking at a document together. Once the room is gone, Linkside does not offer an account history that follows the guest elsewhere.
| Access model | What opens the door | What the design can preserve |
|---|---|---|
| Lasting account | A saved user identity | Membership, recovery, preferences, history |
| Email magic link | Control of an email inbox | Email-based recognition or recovery |
| Linkside room | A successful join to one room | Access for that room, not a guest account |
This is why Linkside’s accountless design is deliberate. It is a boundary around the relationship, not merely a shorter signup form.
What happens when a guest opens the link
The invitation contains a ten-character room code and opens the join page for that room. The link identifies where the guest wants to go; it does not admit them by itself.
The guest submits a nickname and, if the host created a Private Room, its password. After a successful join, Linkside creates a fresh participant ID and a secret for that room. The browser keeps the secret in that tab and uses it to prove that later room actions belong to the same participant.
Think of it as a temporary room pass. Joining a different room creates a different ID and secret. Linkside has no stable guest ID connecting the two visits.
Hosts still have access controls. They can enable the waiting-room option, which places a new guest in the Lobby until the host approves or denies them. A Private Room can require a password. Neither control creates an account for the guest.
The room record is temporary as well. Activity extends an open room’s expiry time. After 15 minutes without activity, the room expires. Linkside keeps a terminal marker for another five minutes so a late request can receive a clear “expired” response, then deletes the stored room record. If the host closes the room, that five-minute terminal period starts immediately.
What accountless does and does not promise
Accountless does not mean access-control-free. Treat a room link as sensitive and send it through a channel you trust. In a Free Room, anyone with the link can reach the join form and try to enter; the Lobby gives the host an approval step when they want one.
It does not mean invisible, either. Linkside’s Signal Worker knows that a room exists, roughly when guests join, and how long the session lasts. If browsers cannot connect directly, an encrypted TURN relay can forward the media. The relay can see packet routing, but it cannot decrypt the screen or audio. Network infrastructure also handles the IP-level traffic needed to make the connection work.
The media path is peer-to-peer first, and Linkside does not record sessions, keep chat history, transcribe audio, or analyse screen contents. Our session-data explanation covers that boundary in more detail.
Coarse operational analytics can outlive the live room record. Allowed fields include room and room-only participant IDs, country, room type, password and Lobby flags, relay outcome, duration, participant count, and join count. Linkside’s analytics rules exclude email, nickname, participant secrets, IP addresses, and raw browser user-agent strings from that dataset. Because each guest participant ID is fresh for each join, it is not a reusable Linkside identity across rooms.
There is a real tradeoff. Linkside cannot recover an account that does not exist, show a saved room list it never creates, or recognize a guest across rooms. If people need persistent membership and shared history, a lasting collaboration space is the better model. If they need to see one live screen now, room-scoped access is enough.
Choose the lifetime before the login method
Ask three questions:
- Should this person keep a recognizable identity after the session?
- Do they need saved history, account recovery, or repeat membership?
- Is access to one temporary room enough?
The first two answers point toward a lasting account or email relationship. The third points toward Linkside: create a room, send its link through a channel you trust, and let the guest join the room rather than the platform.