Watching in a browser
Open the link. There is nothing to install on the watching end.
Open the session link and you are in. No account, no extension, no install — the viewer is a web page that speaks WebRTC directly to the host's machine.
If you have a code rather than a link, enter it on the
home page or go straight to porthole.professorhusnain.com/s/<code>.
What you are asked for
Depending on how the host started the session:
- Your name. Shown on the host's terminal when you join and leave, so they know who turned up. Remembered for next time.
- A password, if the session is password-protected.
- Nothing at all, if you opened an invite link — your name and secret are already in it.
The header
| Element | Means |
|---|---|
| LIVE | Connected, peer to peer, receiving output. |
| read-only | You can watch but not type. |
| Request input | Ask the host for write access. |
| can type · 240s | You have write access, with a countdown if it is time-limited. |
| requests off | The host started with --no-requests; there is nothing to ask. |
Latency, e.g. 28 ms | Round-trip time to the host, with a colour for connection quality. |
| Fullscreen | Hands the whole window to the terminal. |
Asking to type
If the session is read-only, Request input sends a request to the host. They approve it from their terminal, and the header changes to can type.
If the host set --request-duration, the badge counts down and you drop back to
read-only when it lapses. Nothing is lost — you are still watching.
A host who is away from the keyboard will not answer, and the request times out rather than spinning forever.
Session context
When the host attaches context, a sidebar shows what you are looking at: title, environment, severity, notes, links, and a checklist.
It arrives over the peer-to-peer channel after you connect, never through the signaling server — those notes and internal URLs are exactly what the server is designed not to see.
If the connection drops
The viewer reconnects on its own and the host's shell keeps running throughout — their working directory, scrollback, and any running process survive. You are sent the output you missed when you get back.
Brief blips do not show an overlay at all; flashing one at a 200 ms hiccup reads as instability that is not there.
Full-screen programs work better in a terminal
The browser viewer renders through xterm.js, which is very good, but if the
host is living in vim, htop, or tmux, porthole join gives you full fidelity by letting your own
terminal do the rendering.