About Mercurius

Mercurius exists because modern computing has lost the idea of a workstation as a networked presence. We have powerful, long‑lived machines that accumulate history and identity, yet we interact with them through tools designed for disposable laptops and short‑lived sessions.

My own workstation, xavier has evolved over roughly fifteen years. It is a Ship‑of‑Theseus machine: serious CPU, serious storage, serious uptime, and a home directory that actually means something. Around it lives a constellation of small Unix systems, each doing one job well: NTP, mail, DNS, storage, and other services.

To me, the system is the whole network. The workstation is not a box under a desk; it is the centre of gravity for everything I do.

What I want is simple to describe but hard to achieve: to use that machine — in the room sat at the keyboard, or from the studio, the garden, or a laptop on the road, without pretending the laptop is the machine or uprooting it into a cloud service.

Laptop as a mercurius terminal. — Using the workstation remotely

X11 deserves enormous credit for demonstrating what a network‑transparent window system could be. It proved that remote interaction could feel native, not emulated. Wayland deserves equal credit for bringing Linux graphics into the modern era. It has made Linux laptops genuinely competitive with macOS in smoothness, latency, correctness, and power efficiency. Its clarity of scope — focusing on doing local graphics well — is a strength, not a limitation.

Mercurius is not a rejection of either. It is an attempt to fill the space they intentionally do not occupy: a clean, modern, structured protocol for inhabiting a long‑lived workstation across the network, with windows, focus, and input treated as first‑class concepts.

In that sense, Mercurius is not a replacement for X11 or Wayland. It is the missing piece that allows a workstation to remain itself, wherever you happen to be.

How Mercurius differs from what already exists

When people first hear about Mercurius, a common reaction is: “but surely you can already do that?”. On the surface it sounds like X11 forwarding, Wayland remoting, or a remote desktop system. The differences only become clear when you ask where pixels are drawn, what crosses the wire, and who is trusted.

X11 over SSH moves drawing primitives from applications to a remote X server, but assumes trusted clients and 1980s graphics hardware. It exposes global input and window state, and does not model modern GPU pipelines.
Mercurius and “X11 over SSH” both give you remote GUIs, but they do it in fundamentally different ways: X11 is “run the app there, render here, trust everything,” while Mercurius is “run and render there, inhabit it here, trust almost nothing.”
Wayland plus remoting focuses on local graphics; any network transparency is an add‑on implemented by compositors and third‑party protocols. There is no single, standard, network‑native window system in the Wayland model.
RDP, VNC, SPICE, and similar systems treat the workstation as a pixel source. They stream images of a desktop, not windows, surfaces, or focus as first‑class objects.
The easiest way to think about Mercurius is to imagine a laptop plugged into a docking station: the screen, keyboard, and mouse are here, but the real computer doing the work is the laptop under the desk. Mercurius is exactly that — only the “dock” happens over Ethernet instead of a USB‑C cable. You are not watching a video of a distant desktop; you are using your workstation directly, with your own windows and applications, as if you were sitting in front of it. When the network is poor, Mercurius can fall back to a video‑style view, but that is the exception, not the design.

Mercurius is different in three important ways:

It is network‑native. The protocol is defined from the outset to run over a multi‑stream transport, with message boundaries, ordered control traffic, and explicit session semantics.
It is structured. Windows, surfaces, focus, and input are protocol objects with explicit behaviour, not side effects of a framebuffer or compositor implementation.
It is zero‑trust by design. Authentication, encryption, and per‑client isolation are part of the protocol’s model, not optional layers added around it.

In other words, Mercurius is not “X11 done over TLS” or “Wayland with a remote‑desktop plugin”. It is a network window system in its own right, designed for modern GPUs, modern security, and long‑lived workstations.

What Mercurius enables

Mercurius makes several workflows possible that traditional window systems cannot:

Move a live desktop session between physical machines.
Switch between several long‑lived desktops without closing anything.
Use any desk as “your” desk with a follow‑me workstation environment.
Work securely from untrusted networks without exposing data.
Switch between different operating systems at the same desk without rebooting.

For detailed examples, see the full set of use cases.