SRDX: The Capability-Secured Remote Desktop Native to sigilOS — Parity-or-Better Versus RDP and VNC

sigilOS ships two remote desktop layers. SRDX (sigilOS Remote Desktop eXchange) is the primary protocol — kernel-native, capability-secured, pixel-perfect, low-latency, mesh-capable (2 to 16 nodes), and also the transport for RetroPie game streaming. RDP and VNC are the interop fallback layer, allowing a sigilOS host to serve any Windows/Mac/Linux client that doesn't speak SRDX. Auto-negotiate: SRDX is offered first; non-sigilOS peers fall back to RDP or VNC automatically. A sigilOS-to-sigilOS session always speaks SRDX. This document positions SRDX's capabilities, compares it to the industry alternatives, and explains why the "fallback" framing matters: sigilOS achieves RDP/VNC parity by supporting them directly — and then beats them on every dimension that matters. (sigil-os, syscalls 109–112 wired; SRDX RFC in sigil-os#21)

What SRDX Is

SRDX is a kernel-native remote desktop protocol implemented directly as four syscalls. There is no application-layer broker, no userspace daemon managing connections, and no separate codec process. The kernel handles framing, compression, and capability enforcement from start to finish.

The syscall surface (109–112)

What's transmitted

SRDX transmits compressed framebuffer deltas. This is a deliberate design choice that separates SRDX from every other remote desktop protocol:

• The kernel captures the raw framebuffer at the current frame tick.
• It diffs against the last acknowledged frame — only changed pixel regions enter the pipeline.
• The delta is ZSTD-compressed (fast, lossless).
• The compressed buffer is transmitted via srdx_send (syscall 110).
• The remote peer calls srdx_recv (syscall 112), decompresses, and blits the delta directly to its local framebuffer.

No intermediate codec. No lossy path unless the network demands it (future: optional lossy mode for very low-bandwidth links). The constraint on fidelity is the network pipe, not the codec.

Mesh: 2 to 16 nodes

SRDX supports up to 16 nodes in a single session. Node 0 is the controller — input events (keyboard, mouse, touch) flow outward from node 0 to the frame-source host. Nodes 1–15 receive the frame stream and render it locally. A sigilOS home server can simultaneously stream its Lumen desktop to a laptop, a wall-mounted TV, and a phone — with no additional daemon, no streaming relay, and no extra configuration. The mesh is built into the kernel socket model.

Game and multimedia streaming

SRDX is the primary transport for RetroPie game streaming. The same delta-compress pipeline that streams a Lumen desktop session also streams a RetroPie framebuffer at 60fps. There is no separate codec, no separate protocol, no special game-streaming mode. A sigilOS machine running a SNES game and a sigilOS handheld consuming the stream are using the same kernel syscalls (109–112) as any other SRDX session.

Capability gate

srdx_connect and srdx_listen require HP_NET_TOKEN — the host-proxy network capability token held by the broker. srdx_send and srdx_recv require the session's display capability. There is no ambient access. An EL0 process cannot initiate an SRDX session, eavesdrop on another session's frame stream, or inject input events without holding the explicit capability tokens. Credential theft — in the traditional sense — doesn't grant SRDX access; capability token theft does, and cap tokens are unforgeable, broker-held sentinels that cannot be extracted from a running session.

SRDX vs RDP vs VNC

The Parity-or-Better Narrative

Parity achieved

sigilOS speaks RDP and VNC as a fallback server and client. Any Windows, Mac, or Linux peer carrying a standard RDP or VNC client can connect to a sigilOS machine without installing anything new. This is not a reduced-capability path — sigilOS's RDP interop layer surfaces the same Lumen framebuffer over RDP that a native SRDX client would see. Capability parity with every legacy deployment is achieved. sigilOS does not lack RDP or VNC; it includes them as a courtesy to peers who haven't adopted SRDX yet.

Better on fidelity

RDP's default codec is H.264 — lossy. VNC's Tight and JPEG encodings are lossy. SRDX is lossless by design: the delta is exact bytes from the framebuffer. On a fast network, SRDX delivers a pixel-perfect replica. The constraint is network bandwidth, not codec quality. For work that demands it — design review, code editing, pixel-level inspection — SRDX is the only remote desktop that is genuinely equivalent to sitting at the machine.

Better on latency

SRDX runs at the kernel level. There is no application-layer broker buffering frames before dispatch, no display server round-trip before the frame enters the network path. On a LAN, SRDX latency is the round-trip network time plus the delta-encode/decode cycle (approximately 2ms on M-series hardware). RDP and VNC add application-layer framing, codec pipeline buffering, and often a display server round-trip. The gap widens under load.

Better on security

RDP uses credentials — a password or certificate validated against a domain. VNC uses a shared password. Neither protocol has a concept of capability tokens. An RDP session, once authenticated, gives the remote user the desktop — the kernel does not re-check capabilities per frame, per window, or per file access. SRDX sessions are gated by HP_NET_TOKEN plus the display capability at every frame boundary. An EL0 process cannot eavesdrop on another session's SRDX stream — the kernel's capability enforcement means the receive buffer is only accessible to the session that holds the display capability. Capability tokens are unforgeable, broker-held sentinels. The attack surface is categorically smaller.

Better on mesh

RDP is point-to-point. A multi-session RDP deployment requires Remote Desktop Gateway infrastructure — a separate server role, separate certificates, separate administration. VNC is also point-to-point. SRDX supports 2–16 nodes natively, with no additional infrastructure. A single kernel-level broadcast reaches all nodes simultaneously. A home server can stream to a laptop, a TV, and a phone in a single SRDX session at no additional configuration cost.

Better for multimedia and gaming

The same SRDX pipeline that streams the Lumen desktop streams a RetroPie game session at 60fps. This is not a special mode or a separate protocol — it is the same srdx_send/srdx_recv syscall pair, the same ZSTD delta pipeline, the same cap-gated session model. RDP's equivalent — RemoteFX — requires a Windows host with a compatible GPU. VNC has no game or multimedia streaming path. SRDX has no special requirements: any sigilOS machine with a framebuffer can be the stream source.

Marketing One-Liner

Three clauses doing three jobs:

• "capability-secured, kernel-native" — positions the security and architecture. SRDX is the protocol; RDP and VNC are the interop layer, not the product.
• "pixel-perfect, network-bottlenecked" — positions fidelity. The session is not codec-limited the way H.264/RDP is. The limiting factor is your network pipe, not sigilOS.
• "speaks RDP and VNC for everyone else" — positions the fallback as a feature, not a gap. sigilOS doesn't lack RDP; it includes it as a courtesy to peers who haven't adopted SRDX yet. That framing matters: the competition has no SRDX fallback.

Current Status (0.6.0 in Progress)

The syscall surface is complete and verified. The 0.6.0 sprint delivers the encode/decode paths and the QEMU validation. RDP/VNC fallback and the full 16-node mesh follow in 0.6.x and 0.7.x respectively. The protocol architecture is fixed — what ships in later milestones is implementation coverage, not design change.