a76cb2aa6a
The run used to end by asking someone to copy a line and paste it "wherever you
got this from". That is not a loop, it is a hope. At a few hundred people in one
quiet channel, with one shot and no chance to say "please run it again, we made
a mistake", the drop-off between seeing output and pasting it somewhere is
where the whole exercise dies.
So the run now ends with a link, a plain-English list of what the link
contains, and Enter to open it. No account, no form, no mail client, no
assumption about being logged into anything.
· Query parameters, not an encoded blob. A blob would be shorter and would
let us send more; it would also mean the person clicking cannot read what
they are sending, which is the one thing this program has going for it.
· It carries more than the clipboard line did, because nobody has to eyeball
it in a chat window: every requirement check individually rather than only
the aggregate verdict -- which single requirement stops people is the thing
worth knowing -- plus the full latency triple, the 24-hour launch
histogram, and the five largest titles.
· `--submit-url` points it at a local worker; `--no-open` prints only.
· The clipboard line stays as the offline path: a headless host, a machine
with no browser, or somebody who would rather not click a link we wrote.
Three corrections
1. Steam consent now defaults to yes. This is a questionnaire and the person
running it knows that; defaulting to no framed our own instrument as
something to be wary of, and the yes/no still asks.
2. The virglrenderer check is gone. It could only ever report "present,
patch state unknown" -- a row incapable of passing -- and the box now
carries its own virglrenderer and Mesa inside the image it runs in, so the
host's copies are not on the path. It was telling prospective hosts their
machine was wrong when it was not.
3. The roadmap question -- cloud, or reach my own machine from anywhere -- is
now question one, of everybody. It was going to be a channel poll, and the
channel is no longer the only way in. It is asked first because a
respondent who quits after one question should have answered that one.
Two collisions found while wiring it up: the `gpu` check id overwrote the GPU
model parameter (last-writer-wins in a query string is a silent loss), so check
ids are prefixed `ck_`; and both renderers now take the assembled report rather
than seven positional arguments that had to be kept in step by hand.
Run your games on a GPU you don't own — or one you do. Nestri puts an interactive workload in a hardware-accelerated virtual machine and streams it to you over QUIC, at a latency that lets you play rather than watch.
Note
This repository is mid-rewrite, and the documentation is behind the code. The guest-side components arrived recently and their docs are thin. Nothing here is stable yet: expect directories to move and interfaces to change. Proper documentation is on the way — issues and questions are welcome in the meantime, and are genuinely useful for deciding what to write first.
What is here
Two halves that meet over the network and share very little else.
The control plane — TypeScript, on Cloudflare Workers
apps/api |
The public REST API. Identity, teams, machines, games, pairing. |
apps/auth |
A self-hosted OpenAuth issuer — Steam and SSH-key login. |
packages/core |
The domain: every table, every operation, no HTTP. |
packages/auth |
Shared auth types and subjects. |
Postgres for state, Alchemy for infrastructure. See
docs/alchemy.md.
The guest — Rust, inside the box
These run inside a virtual machine, beside the game. None of them talk to the control plane.
apps/nescope |
A headless Wayland compositor for one fullscreen client. A lighter answer to the same problem gamescope solves. |
apps/nescapture |
A Vulkan implicit layer. It captures frames from inside the workload's own process and encodes them on the GPU that drew them — no copy out to the CPU and back. |
apps/neswire |
Audio capture and transport. |
apps/neshub |
One connection out of the box. Muxes video, audio, cursor and input into a single QUIC stream to the client. |
crates/nesprotocol |
The wire types they all share, so no two ends can drift apart silently. |
The hypervisor these run under is nesbox,
a separate repository: a micro-VM with a real GPU in it, using virtio-gpu native
context rather than passthrough, so one card can host several boxes at once.
Why a virtual machine
A container shares the host kernel, which makes strong isolation hard and a GPU harder. A micro-VM boots in about as long, isolates properly, and — with native context — gets close to bare-metal graphics. That choice is what makes "many sandboxes, one GPU" possible instead of one tenant per card.
Getting started
bun install
bun dev # control plane, local Cloudflare runtime
cargo build --workspace # guest components
cargo test --workspace
The Rust components expect a Linux host with a Wayland-capable GPU stack. They are not much use on their own yet — they are pieces of a box, and the thing that assembles a box is not open yet.
Status
Working: the API, auth, the domain model, and the guest components listed above.
Not here yet: the box lifecycle, storage, the edge, and the client. Some of that will open as it is written; some is deliberately closed. What decides which is whether it handles your data — that half is open on principle — or decides our capacity, which is the part we sell.
Contributing
Early, and the ground moves. The most useful contribution right now is telling us where the documentation failed you. Conventional commits; explain why in the body.