--- import platform from '../../data/platform.json'; /** * The data path (PLAN.md §13 phase 3), drawn as inline SVG per §11's motif rule — hand-drawn * geometry, used where it explains something, and no raster anywhere. * * --------------------------------------------------------------------------------------- * THE LABELS ARE GENERIC, WITH UO AS THE CAPTION * --------------------------------------------------------------------------------------- * The org lead settled this before the diagram was drawn. The nodes say "your game server" * and "sidecar", not "ServUO shard" and "uo-link", because §10's rule is that a reader * should never need to know that `link`, `servuo-plugins` and `installer` are three * repositories in order to connect a game server — and because the tagline promises a * platform, not a UO product. * * It does NOT hide what actually ships. The sub-labels and the caption name ServUO and * uo-link outright, because §1 says the technical truth wins and today there is exactly one * implementation of this shape. An operator running a shard has to see themselves in the * picture on the first screen. * * --------------------------------------------------------------------------------------- * WHY THE SVG IS aria-hidden * --------------------------------------------------------------------------------------- * Not because it is decorative — it is the opposite — but because the steps beside it carry * the same four stages in full prose, at real font sizes, in reading order. A `role="img"` * with a `` would make a screen reader read the same path twice, and the second * telling would be the worse one. The picture is for people who can see it; the list is the * canonical version and everyone gets it. * * That also means the diagram must never gain a fact the list does not have. * * The concentric rings behind the nodes are the emblem's own geometry, centred on the * boundary line — the one place in the picture where the argument actually happens. */ ---

How it works

One path, one direction

Everything the website knows about your game arrives the same way. There is no second route in, and nothing on the internet can reach the game to ask.

Today that game server is a ServUO shard and that sidecar is uo-link. The shape is the contract; the implementations are what plug into it.

  1. Your game server

    A plugin inside the server dials out to the sidecar over loopback. The game never listens for anything, so there is nothing on it to find. Events go onto a bounded queue and the game moves on — a sidecar that is wedged or missing cannot slow the world down.

  2. The sidecar

    A small service beside the game, and the only piece of the bridge anything else can reach. It speaks a versioned wire protocol — protocol {platform.protocol} today — so a mismatched pair is refused rather than misread, and it answers only your website's backend, over an authenticated WebSocket and REST.

  3. Runic Gateway

    Your site ingests the live feed and fans it back out on two streams: a public one carrying an allowlist of safe events, and a staff-only one carrying the rest. That split is a security boundary, not a preference. When the game is down the site stays up and shows it as offline.

  4. Browser and app

    The web client reads same-origin JSON and server-sent events. The Android app talks to the same documented API with bearer tokens. Neither has any idea where the game server is, because neither is ever told.