wtclaude
9532b7b26c
`GET /config/files`, `GET /config/file` and `POST /config/write` (R18). The sidecar keeps the property protocol 4 relied on: it defines no schema for any of it, stores none of it, and judges no path — only the process holding the configuration directory can decide whether a path resolves inside it, and a guard here would be a weaker second opinion with no way to check itself. Nothing reaches the store or the feed. A config this sidecar cached would be an edit an operator made over SSH that the website then silently overwrote, so all three routes fail when the game is down, like `/status`. The one thing added beyond forwarding is a better 504 on the write: the plugin writes a whole set or restores a whole set and never half of either, so the body says to re-read rather than guess, and names the reload window that is probably still running. `CONFIG_RELOAD_WINDOW` mirrors the plugin's, and a test asserts that two of them plus slack fit inside `REPLY_TIMEOUT` — a rollback that reports after its caller has gone is worse than no rollback. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM
rust-link
The sidecar half of the Runic Gateway bridge for Rust. It terminates the loopback link from a Rust server's Oxide bridge plugin and exposes the WebSocket + REST surface the website consumes.
It is the mirror of RunicGateway/link, which
does the same job for Ultima Online, and it keeps that bridge's central invariant unchanged:
The game server is never reachable from the website. The plugin dials out to this process; this process owns the listener. Only the sidecar is exposed, and only the website's backend talks to it.
Rust server + Oxide (RunicGateway/Rust-Plugins, C#)
│ loopback TCP 127.0.0.1:7799, newline-delimited JSON, bidirectional
│ the PLUGIN dials out (the game opens no listening port for us)
▼
rust-link sidecar (this repo, Rust) ← the only network-facing bridge component
│ WebSocket (live feed) + REST (point-in-time reads), bearer-token auth
▼
website backend + module-rust (RunicGateway/Module-Rust, Node)
One server, one sidecar
This binary serves exactly one Rust game server. A community running six servers runs six
pairs, each with its own port, database and token; module-rust holds six clients and the website
core never learns there is more than one. Nothing here is multiplexed, and nothing here should
become multiplexed.
Build and run
cd sidecar
cargo build --release # → target/release/rust-link-sidecar
cargo run # info logging; writes sidecar.toml (with a generated token) on first run
RUST_LOG=debug cargo run # verbose, including heartbeats
Everything is configured from sidecar.toml — nothing is compiled into the binary. Auth is
always on: a blank token is generated and written back on first start, so there is no state in
which this process listens without one. --print-config resolves the configuration and prints it
as JSON, which is how an installer reads the token back without scraping a log.
See sidecar/README.md for the configuration reference and the endpoint list.
The protocol is a contract
The loopback JSON protocol (plugin ↔ sidecar) and this sidecar's HTTP/WS API (sidecar ↔ website)
are versioned compatibility contracts, not build dependencies. PROTOCOL_VERSION lives in
sidecar/src/main.rs; every response carries X-RustLink-Version, and a
client that declares a different one is refused 409 rather than served something it will
mis-parse.
A version is declared in three places and they must agree:
| Where | Repo |
|---|---|
PROTOCOL_VERSION |
this repo |
overlay.toml |
RunicGateway/Rust-Plugins |
module.json |
RunicGateway/Module-Rust |
The canonical spec is
docs/rust-link/. If
you add or change an event or a command, update all three repos and the spec in the same
change.
Licence
GPL-3.0-or-later. See LICENSE.md.