Skip to content
03

A runtime that hosts other people’s apps

A tablet interface other resources plug into at runtime: they register an app, it mounts inside the frame.

Context & problem

Every feature on a multiplayer server wants a screen, and each one building its own means a dozen interfaces that behave differently and fight each other for keyboard focus. This is one host that owns the frame, the home grid, focus and the way out. A guest ships a small self-registering bundle; when the player opens it the host injects the script, the bundle registers itself, and the host hands it a container and a context object. Guest interface code calls its own server-side code through that context, and the server pushes events back the same way.

Role

Sole developer.

Constraints
  • Guest code runs inside the host’s document, so styles, element ids and pointer events can bleed between them.
  • The host must keep control of the escape route no matter what a guest does.
  • A guest is written by someone else, later, without touching the host.
Decisions & why
The bridge is a context object handed to the guest, not a shared global.
A guest calls its own server code and subscribes to its own events through one object it was given. Nothing else is reachable, and the host can see every call that crosses.
Not everything should be a guest app, and the documentation says which.
Passive surfaces — dashboards, lists, history — belong in the tablet. World-triggered and modal interfaces do not, and forcing them in makes both worse.
Stack
  • TypeScript
  • React
  • Lua
  • Vite