DeskVNC DeskVNC

Read on the hub  →  deskvnc-hub.pages.dev/boundary-deep-dive

title: "Boundary, the handshake that turns a stranger's laptop into a room you can leave" description: "Boundary is DeskVNC's attended support mode. It pairs two machines across the open internet, prefers a direct encrypted path, and lets the person at the remote end approve every session and end it whenever they want." date: 2026-10-09 tags: ["mcp", "boundary", "attended-support", "remote-support", "ai-agents", "lease"]

The first remote support session anyone helps with over the open internet is, by definition, between two people who do not yet trust each other. One of them needs help, the other can give it, the network between them is hostile in the usual ways, and the person at the keyboard that needs help still owns the machine. The whole problem is how the second person gets a view of the first person's screen, types into it for a while, hands it back, and leaves, without leaving a credential, a background service, or a path back in.

Boundary is DeskVNC's answer to that problem. It is a small attended support mode that pairs two machines across the open internet, prefers a direct encrypted path between them, and falls back to its own relay when the networks will not cooperate. The person at the remote computer stays in charge of the whole encounter. They approve the connection before it opens, they keep a revoke control on their screen while it is open, and they can end the session at any moment, with the worker side hearing about it through the same channel the session runs over.

This post walks the protocol handshake end to end, names the four digit code service and its one lookup expiry, shows what revocation looks like to an agent on the worker side, and ties Boundary back to the per machine lease model that the rest of the MCP surface is built on. The point is to show why attended support is the load bearing word, and why it sits at the protocol level rather than in some approval UI bolted on the side.

The Boundary handshake, with the relay fallback named

The shape of the handshake is the same whether the two machines are on the same coffee shop network or on opposite sides of the planet. Each step is a deliberate act on one side that the other side can see, and each step has a yes or no answer before the next one runs.

  1. The worker installs DeskVNC. The helper app on the side that will give support ships in the same binary as the DeskVNC client. Opening Boundary support from inside the client brings up the dialog that accepts an invitation or a code. No new install, no new account.
  2. The recipient installs DeskVNC Support. The person who needs help downloads the small DeskVNC Support app from the release page and opens it. It is signed and notarized on macOS, signed on Windows, and ships as an x86_64 binary in a tarball on Linux, so the platform gates all behave normally.
  3. The recipient generates an invitation or a code. Pressing Get a code produces a fresh code on a shared Boundary code service and shows it as four digit groups, like 1234 5678 9012. Pressing Create invitation instead produces a single use invitation string the recipient sends out of band when no code service has been configured.
  4. The recipient reads the code or copies the invitation. This is the only step that depends on how the two people are already talking. A phone call, a chat, a helpdesk ticket: any channel that cannot replay or guess the value works.
  5. The worker enters the code or pastes the invitation. When a code is entered, the worker side resolves it to a live invitation. The lookup spends the code immediately. When an invitation is pasted, the worker side accepts it as a single block.
  6. The recipient approves the connection. Before any traffic flows, the recipient's screen shows who is asking, and the recipient chooses to allow or deny. A decline is final, and the code or invitation is spent either way.
  7. Boundary tries a direct encrypted path. The two endpoints open a UDP path between themselves, negotiate session keys, and verify that the recipient's machine is reachable. When the networks cooperate, the session runs end to end and no third party carries a byte.
  8. If the direct path fails, Boundary falls back to its relay. When networks do not allow peer to peer (carrier grade NAT, strict egress policies, two private LANs with no public address), the relay carries the encrypted session traffic without being able to read it. The worker side does not have to know which path is in use. Either way, the session opens with the same safety properties.

The recipient retains a revoke control on screen for the duration. Boundary's design treats every session as a deliberate act on both sides, and the steps reflect that, because the only way to skip a step is to skip the safety property it creates.

Two paths to the same machine: a direct encrypted path between the two endpoints and a relay fallback. The recipient keeps the revoke control on screen in both cases.

The code service and the four digit groups

For a one off help session, the shared Boundary code service is enough. For a tighter trust boundary, an operator runs their own private code service. The shape is identical: the support app reaches the service over the network, gets a code, and the worker side looks it up against the same service.

The recipient's Get a code button reaches the configured code service and asks for a fresh code. The service returns twelve digits, displayed as four digit groups separated by spaces, like 1234 5678 9012. The recipient reads the groups to the worker over the chosen channel. The worker types them into the Boundary support dialog in the same order, separated by spaces, exactly as spoken.

The number expires after one lookup. The worker side resolves the code against the same code service the recipient used, the service marks the code as spent, and the worker side gets back the live invitation the code pointed at. If a second worker tried to use the same code a moment later, the lookup would miss, and the code would still be useless to anyone listening in. The expiry is the whole point: a code is an address, not a credential.

The person at the remote computer still approves the session, even after a successful code lookup. The lookup gave the worker a way to reach the recipient's machine and request a session; the recipient's screen still decides whether to open it. The two halves of the safety property live in different places for the same reason: a code that approves itself would not be a code, it would be a password.

Revocation, and what the worker side sees

Every Boundary session ships with a revoke control on the recipient's side. The control is visible on screen for the whole session, not hidden behind a menu, because the safety property depends on the recipient being able to reach it under stress. Pressing revoke closes the session immediately. The worker side sees the session end with a clear message, and any held input (a drag in progress, a held modifier key, an open context menu) is released before the connection drops.

The same property shows up to an automated worker through the dvv tool surface. A worker driving the session through the MCP server holds a per machine lease on the limb the session opened against. When the recipient revokes, the next input call from the agent comes back as a refusal: LEASE_REVOKED. The refusal is structured rather than exceptional. The error carries the reason and the current geometry generation, so the agent can stop, recapture, or hand the task back to the recipient entirely.

The agent should always follow LEASE_REVOKED with dvv_status. That call reads no pixels and needs no lease, and it returns the full dvv.observation.v1 object for the limb, including the lease holder field. The lease.human_took_over flag tells the agent which side of the story the refusal came from: true means a person is driving the machine now and the right move is to stop. The same loop covers a human revoking the Boundary session, a person pressing a key in the DeskVNC window by accident, or a person focusing the window mid task to take the wheel. The server returns one error and one flag in every case, because every case is the same structural event.

A worked Boundary session

To make this concrete, here is one pass through the flow on the worker side, with the dvv calls an MCP equipped worker would make after the recipient has approved the connection.

// 1. The recipient's code resolved into a live invitation and accepted.
//    Boundary hands back a limb id (LX-9c41) for the support session.
dvv_limbs {}
// -> { "limbs": [
//        { "limbId": "LX-9c41",
//          "remoteName": "kara-laptop",
//          "protocol": "vnc",
//          "path": "direct" } ] }

// 2. Attach the mirror so the agent can perceive pixels at all.
dvv_open    {"hostId": "<boundary-host>", "perceive": true}

// 3. Take an exclusive input lease with a renew-while-active timeout.
dvv_control {"limbId": "LX-9c41", "action": "acquire"}

// 4. Read the frame the agent will reason about.
dvv_screen  {"limbId": "LX-9c41", "form": "full", "scale": 0.25}

// 5. Click the Start menu, fenced by the generation read in step 4.
dvv_click   {"limbId": "LX-9c41", "x": 28, "y": 740, "generation": 1, "button": "left"}

// 6. The recipient revokes from the dialog mid click. Step 6 is refused,
//    and the lease for LX-9c41 is invalidated.
dvv_click   {"limbId": "LX-9c41", "x": 134, "y": 504, "generation": 2, "button": "left"}
// -> { "ok": false,
//      "error": "LEASE_REVOKED",
//      "lease": "LX-9c41",
//      "reason": "human_took_over",
//      "new_generation": 3 }

// 7. The agent reads the observation for the limb to confirm the reason.
dvv_status  {"limbId": "LX-9c41"}
// -> { "state": "connected",
//      "lease": { "holder": "none", "human_took_over": true },
//      "geometry": { "width": 1920, "height": 1080, "generation": 3 } }

// 8. The agent closes the limb cleanly and steps aside.
dvv_close   {"limbId": "LX-9c41"}

The same exchange would land flat against a normal saved machine in the operator's library: lease, input, screen, lease, close. Boundary adds the resolution and approval events at the start and the new human_took_over flag at the end, but the rest is the loop an agent already runs against any other limb. That is the design point: attended support and unattended operation share one control plane, so the agent does not have to learn a second language to use it.

Why Boundary is the same shape as the dvv lease model

The MCP side of DeskVNC already names its core safety property: a person can take the wheel at any moment, because the input lease sits in the same table as the human's keystrokes. Boundary is that same property in a different geometry. The recipient is the holder of a human visible lease, expressed as a revoke control on screen, and the worker holds the input lease that can be invalidated by anyone who reaches into the same window. The per machine lease in the saved host case, and the recipient held revoke in the Boundary case, are the same primitive at different scopes.

That symmetry is what makes Boundary belong at the protocol level rather than in some approval UI on the side. The revoke control is not a button somewhere that means "pause". The revoke control invalidates the same input lease the agent is holding, in the same lock free update that delivers the keystroke to the window. There is no second process to coordinate, no IPC to bridge, and no separate screen buffer to keep in sync, because the support app and the support client share the same code path that the rest of DeskVNC already runs.

The relay path does not change the picture. When the direct encrypted path fails, the relay carries the encrypted session traffic without being able to read it, and the recipient keeps the same revoke control on screen for the duration. The worker side sees the session open and the session end the same way it would on a direct path, with the same LEASE_REVOKED event when the recipient ends it. The relay sees envelopes, not contents.

The structural case for attended support at the protocol level

Boundary is the smallest possible shape that delivers attended support over the open internet, and that is its design point. It defines a handshake, names the two paths through it, ties the code to a one lookup expiry, and ties the approval to a revoke control on the recipient's screen. It does not need an account, a server side daemon on the recipient's machine, or an out of band approval platform. The recipient downloads a small app, presses one button, reads twelve digits to the worker, and approves the session when it arrives.

The structural consequence is that attended support scales with how the two people already know each other, not with how the networks happen to be set up. A coffee shop, a corporate LAN, two home networks, a hotel room on a captive portal: the direct path is tried first, the relay fallback carries the encrypted traffic when peer to peer is not on the table, and the recipient stays in charge of the whole encounter either way. The MCP layer on the worker side reads and writes the same limb the human would, and the per machine lease on that limb keeps the human's revoke on the same code path as the agent's input.

That is the part that has to be true for an agent to touch a real machine at all. The contract from the DeskVNC project page is that an agent can open one of your saved machines, observe the screen, click and type, with nothing installed on the remote, and a person can take control back at any moment. Boundary is that contract for the case where the person you are working with is not on your network, the same way the MCP server is that contract for the case where the person is no longer in the loop. The protocol is the load bearing layer in both cases.

Read more