Practical guides
Connect devices without hiding the important decisions.
These guides describe the intended customer workflow and name the release gates that still matter. A setup step is not called available until its corresponding build and service are verified.
Start here
Six workflows, one consent model.
Every connection names its participants, purpose, requested permissions, and expiry. A local host can stop an active session immediately.
Windows host to iPad viewer
On Windows, sign in and enroll the browser or visible native companion. On iPad Chrome, sign in to the same account, enroll that browser, choose the Windows device, and request View. The Windows user must choose the screen and approve the request. Keep both devices on the same LAN for the current direct-only browser preview.
Passwordless account and device enrollment
Enter an email address, use the one-time email link, then register a passkey. Each browser or native installation creates its own non-exportable device key. Removing a device revokes its future session requests without exposing another device key.
Direct connection security
The API authenticates both devices, records the exact requested grants, and signs a short-lived ticket bound to the two device identities and WebRTC fingerprints. Media and session content travel between endpoints. A refreshed lease keeps the authorization short-lived.
Files and one-to-many sessions
Select explicit recipients under the same account, review file name, size, type, and destination, then approve the transfer at each receiving device. Group membership never becomes an automatic permanent grant, and files are not uploaded to the control service.
Work input and game controllers
View-only works in a browser. System-wide keyboard, pointer, touch, pen, and controller injection require the visible native companion plus operating-system permissions. Game-controller support remains experimental until signed builds and physical-device latency tests pass.
Extensions and local applications
Browser and editor extensions use the same authenticated account and narrowly scoped local-agent protocol. They may request a named product action; they may not create a remote shell, general proxy, unrestricted port forward, or hidden capture path.
Direct-session checklist
- 01
Verify the account
Use the email link and passkey; never share a bearer link or device private key.
- 02
Name both devices
Check the target name and identity before requesting a session.
- 03
Approve exact grants
View, input, files, clipboard, audio, and controller access remain separate.
- 04
Confirm visible status
The host indicator and stop action must remain available throughout control.
Platform truth
Browser viewing and native control are different jobs.
iPad Chrome can be a viewer and can share a browser-selected surface. It cannot silently grant Windows-level input or run a background host. Install the signed native companion for system-wide control once that platform package reaches a verified release.
Compare platform surfaces