Read on the hub  →  deskvnc-hub.pages.dev/90-days-of-releases

title: "90 days, 26 releases, and the shape that emerged" description: "Ninety days of DeskVNC releases form one shape: protocol cores, an MCP agent interface, the Boundary support module, and a polished per-OS surface." date: 2026-10-09 tags: ["mcp", "boundary", "rust", "tauri", "release-cadence", "ai-agents"]

90 days, 26 releases, and the shape that emerged

Some projects ship a 1.0 and start filling in features. DeskVNC did the opposite. It opened a repository on 30 July 2026, shipped a working build a few days later, and kept shipping for ninety days straight. Twenty six releases, and one shape that became visible only when the changelog was read as a single document. The shape has four pieces, in this order: hand written protocol cores, an MCP agent interface, the Boundary attended support module, and per-OS polish that turns a working binary into something people install without a fight. This page reads the cadence as one story.

The cadence of ninety days

The release page is the canonical record. Twenty six tags, with the gap between releases settling into a working rhythm: quiet days for deeper changes, a cluster of releases on the days the boundaries shifted, and a steady drumbeat of polish on top. The most recent ten are below, from the published changelog.

Twenty six releases in ninety days is roughly a tag every three to four days. The cadence is the point. The repository treats the changelog as a public surface rather than a private log, and each entry reads like a short post about a real change, which is what makes the four pieces of the shape visible at a glance.

The protocol cores, written from scratch

The first piece is the cores. DeskVNC ships its own VNC, RDP and SSH implementations in Rust on Tauri 2, written rather than wrapped. That choice is load bearing: every layer above it inherits the same property, with no surprises leaking in from a third party wire format.

The VNC core speaks RFB 3.3 through 3.8, every common encoding, and continuous updates. Authentication is layered: VeNCrypt, RA2 and Apple authentication sit on top of the handshake. The core has been verified end to end against x11vnc, TigerVNC, QEMU, RealVNC and macOS Screen Sharing, the realistic matrix of servers a person is likely to meet.

The RDP core covers Windows desktops with NLA, RemoteApp, resolution control, and the usual codecs. NLA is the property that lets the client walk up to a domain joined Windows box the way the official client does, without inventing a parallel credential story.

The SSH core gives a terminal that survives a drop, SFTP transfers for moving files both ways, tunnels, and PuTTY key files. The PuTTY key path is the one that matters on Windows, because it lets existing .ppk files a person has been collecting for years keep working without conversion.

Three protocols, three cores, one binary. The picture is decoded in Rust and painted through WebGL2, so whole frames never cross the process boundary. H.264 has hardware acceleration where the webview offers it. Scroll wheel, trackpad, keyboard layouts, dead keys, CJK input methods and system shortcuts behave the way a person would expect, because the input path is the same one the host operating system uses for its own windows.

The MCP server and the twenty five tools

The second piece is the part no other client ships. DeskVNC installs a Model Context Protocol server called dvv alongside the desktop client. The manifest declares exactly twenty five tools, asserted as TOOL_COUNT: usize = 25 in crates/dvv/src/mcp/manifest.rs, so the count is a decided constant. The set covers discovery (dvv_hosts, dvv_limbs), connection (dvv_open, dvv_wait, dvv_control, dvv_status, dvv_signals, dvv_reconnect, dvv_close), the agent's eyes and hands (dvv_screen, dvv_click, dvv_type, dvv_key), files and clipboard (dvv_files, dvv_transfer, dvv_clipboard), a terminal (dvv_term_read, dvv_term_send, dvv_run), and the group family dvv_group_open, dvv_group_list, dvv_group_run, dvv_group_grow, dvv_group_shrink, dvv_group_close for addressing several machines as one.

An agent that connects through MCP runs one loop. It lists what is open with dvv_hosts, attaches the mirror with dvv_open and perceive: true, acquires the input lease with dvv_control, reads a frame with dvv_screen, sends a click fenced by the geometry generation it just read, reads again, types, sends keys, and closes. On a real 1920x1080 Windows desktop over LAN, that loop runs in 19 milliseconds, roughly fifty two observe-then-act cycles per second. dvv_type reaches 447 characters per second at the steady state.

The loop is protected by typed fences. dvv_screen prints an imageSpace line with the region, dimensions, and scale. Clicks carry a generation read from the screen. A click computed against a screen that has since resized is refused and reports GEOMETRY_CHANGED with nothing delivered. Typing and keys are refused until the screen has been read in pixels since it last changed significantly, so the agent cannot send input against a picture it has not actually looked at. With scale: 0.5, a point at (mx, my) on the picture is (mx*2, my*2) on the machine.

The error codes an agent should handle are exactly four: LIMB_GONE for a machine that has gone away, GEOMETRY_CHANGED for a screen that resized, SCREEN_CHANGED for something window sized that repainted, and LEASE_REVOKED for the case where a person took control back, which is the intended behaviour. After a LEASE_REVOKED, the right next call is dvv_status, which reads no pixels and needs no lease. It returns the full dvv.observation.v1 object, and lease.human_took_over tells the agent whether to step aside.

Boundary, attended support at the protocol level

The third piece is the module the user-facing release notes talk about most: Boundary. It is DeskVNC's attended support mode. The person who needs help downloads DeskVNC Support from the same release page, presses Get a code, and reads twelve digits to the helper as four groups like 1234 5678 9012. The helper opens Boundary support in DeskVNC, pastes the code, and connects. The number expires after one lookup, and the remote person still approves the session.

Boundary prefers a direct encrypted path and falls back to its relay when the networks do not cooperate. The relay carries the encrypted traffic without being able to read it. The recipient keeps a revoke control on screen for the whole session, and pressing it closes the session at once. The helper side sees the session end as a refusal: LEASE_REVOKED, with reason: human_took_over on the next input call.

Boundary is the same shape as the rest of the MCP surface, because the input lease an agent holds is invalidated by the same mechanism a person's keystroke uses. The support app and the support client share the code path the rest of DeskVNC already runs, which is why an MCP equipped helper can pick up a Boundary session with the same four call loop it uses against any other limb.

The agent skill and the install line

The fourth piece is distribution. The repository ships an installable agent skill at skills/deskvnc/SKILL.md whose description reads: "Drive real Windows, Linux and macOS desktops through DeskVNC, either with the dvv_ MCP tools or with the dvv command in a shell. Use when asked to operate, inspect, test or automate a remote machine over VNC, RDP or SSH, or several at once." An AI agent scanning a skills directory discovers DeskVNC on its own, picks the description, and reads the loop. That property, an agent finding the project without a human pointing at it, is the part the changelog grows toward.

For agents without MCP, the shell equivalent is the same surface exposed as dvv subcommands after dvv setup. The binary sits at /Applications/DeskVNCViewer.app/Contents/MacOS/dvv on macOS, %LOCALAPPDATA%\DeskVNCViewer\dvv.exe on Windows, and /usr/bin/dvv on Linux.

The per-OS polish, the signing, the notarization

The ninety day changelog does not stop at protocol and agent surface. It picks up the smaller things that turn a working build into something a person can install without a fight. The Windows downloads are code signed by Open Source Developer Godwin Josh through Certum, so the setup exe, the MSI, the app inside them, dvv and DeskVNC Support all carry the same signature. SmartScreen may still ask once while the new certificate builds reputation, which is the expected behaviour for a new identity.

On macOS the build is signed and notarized. On Linux the AppImage ships a copy of dvv that stays put in the working directory, the property an agent relies on: it knows where to find the binary regardless of how the AppImage was started, and an agent can start the AppImage itself when the app is closed. The fixed working directory is also why the Linux release ships as an x86_64 tarball for the support app, alongside the macOS and Windows builds.

The Boundary crates are compiled, linted and tested in CI on all three platforms. Agents installed through nvm, fnm, Volta, asdf, mise, Homebrew or npm are found and connected when the app is opened from the Dock or a desktop menu. After a crash, the app starts again on macOS and Linux. The agent plane is on by default.

The ninety day numbers

From 30 July 2026 to 8 October 2026, the repository shows 70 stars, 8 forks, 26 releases, and 836 lifetime downloads across the assets attached to those releases. The latest tag is v0.27.11, dated 2026-10-08, and the cadence settled into roughly one release every three to four days for the last stretch.

The shape these numbers describe is not a single feature or a single selling point. It is a project that picked a difficult set of problems, picked the protocols the answer must respect, and kept shipping until the protocol, agent, support, and per-OS surfaces all met at the same place. The next ninety days will go to the same place, with the same habit: a release every few days, a changelog entry that reads like a short post, and the same shape carried one step further.

What comes next

The next ninety days will widen what is already here. Boundary ships on all three platforms now, and the unattended access path inside it earns its own changelog entry when the next release goes out. The MCP surface grows the same way, with new tools added where the loop asks for them and existing tools tightened where an agent on a real machine pointed at the gap. Read the DeskVNC release page for the next entry, the project repository for the source, and the DeskVNC project page for the entry point the maintainers keep themselves.