Architecture
Core Concepts
Mercurius is designed around a small, composable set of ideas:
- A stable, long‑lived machine acts as the authoritative environment.
- Clients connect to this machine using a protocol designed for presence, not display.
- State lives on the workstation; interaction happens wherever you are.
- The protocol is optimised for SCTP and efficient over modern networks.
The architecture is intentionally minimal. Complexity belongs in the workstation, not in the protocol.
Internal Object Model
For a complete description of the internal structure of Mercurius — the Transport → Controller → Broker → Session pipeline, the Iron Rules, and the Smalltalk‑in‑C object model — see the Object Model.
The Object Model defines what Mercurius is built from; the coding standards define how those ideas are expressed safely in C. For the implementation‑level rules that enforce the Iron Rules — covering ownership, lifetimes, error handling, documentation, and safe use of the language — see the C Coding Standards.
Architectural Requirements
Why SCTP‑only is the right choice for Mercurius
The protocol’s guarantees depend on SCTP semantics, and plain TCP simply cannot provide these without re‑implementing SCTP in user space. If TCP becomes a first‑class transport, implementers will choose it because it’s easier.
This leads to:
- Degraded latency
- Broken prioritisation
- Unpredictable input timing
- A “remote desktop” feel
- The protocol being judged by its worst transport
That is exactly the fate Mercurius is designed to avoid. Its goals are specific and uncompromising — to be a successor to X11’s network transparency:
- With modern security
- With modern GPU semantics
- With relocatable sessions
- With deterministic behaviour
Mercurius isn’t just a remote desktop protocol; it’s a structured, multi‑stream, zero‑trust window system. That identity depends on:
- Independent ordered streams
- Message boundaries
- Partial reliability
- No cross‑stream head‑of‑line blocking
- Multi‑homing and stable associations
These aren’t optional. They are the foundation of:
- Deterministic compositor behaviour
- Responsive input under load
- High‑motion video surfaces
- Relocatable sessions
- Multi‑seat concurrency
Why Vulkan‑only is the right choice for Mercurius
Mercurius requires Vulkan for the same reason it requires SCTP: the system depends on properties that only Vulkan provides natively. The compositor, the Session model, and the rendering pipeline all assume explicit GPU control, predictable synchronisation, and cross‑platform consistency.
Allowing multiple GPU APIs (OpenGL, DirectX, Metal, legacy Unix GL stacks) would force the compositor to:
- support multiple backends with incompatible semantics
- fall back to lowest‑common‑denominator rendering
- lose deterministic behaviour due to implicit driver state
- abandon multi‑GPU awareness and migration
- be judged by its weakest renderer
Vulkan provides the architectural guarantees Mercurius depends on:
- Explicit resource ownership — no hidden allocations or global state.
- Deterministic command submission — the compositor knows exactly when work is queued and completed.
- Cross‑platform consistency — Vulkan is the only modern, vendor‑neutral GPU API.
- Zero‑copy surface handling — structured and video surfaces rely on explicit memory control.
- Multi‑GPU enumeration — Sessions can migrate between GPUs because Vulkan exposes devices explicitly.
OpenGL cannot satisfy these requirements: it has implicit global state, unpredictable driver behaviour, and no reliable multi‑GPU model. DirectX and Metal are platform‑specific and incompatible with the workstation‑centric, Unix‑first design of Mercurius.
Software compositing is also insufficient: Mercurius is designed for high‑motion video surfaces, GPU‑accelerated compositing, and multi‑session concurrency. A workstation without a Vulkan‑capable GPU is simply not a Mercurius workstation.