the working notes behind inworld.help — bots, a viewer, a hub, and one language everywhere
this is a quick sketch of the system and how we build it. it's written so a stranger (or an ai) can read it fast and know what exists, why it's shaped this way, and how work moves through it.
the thing, in one breath
we run a presence on the grid — some bots and a viewer — all scripted in luau (roboblox's lua, chosen because it's fast, sandboxed, and typed). every script talks to the grid through one global table, client. bots and the viewer are driven over one central hub, which routes control and exposes a model context protocol (mcp) api so ai tooling — and us — can drive any of them.
key point: none of this needs a remote server. a bot runs fine on a local machine, with or without a hub. the remote host is optional; it exists for the bonuses it adds (a stable presence, a persistent relay, mcp over the network, many hosts behind one door).
- bots — headless grid clients on a server, driven by luau services.
- viewer — a full grid client with an embedded vm; it implements the same
client surface, so the same script runs on either host.
- hub — a websocket relay + mcp server. registers every bot and viewer, routes control, persists state.
- luau — the one language for scripts, services, and our own tooling. no python.
one contract, many hosts
the core bet is a single scripting contract. a bot embeds a luau vm behind a c-abi shim; the viewer embeds the same vm over its c++ managers. both expose the same client table — chat, movement, inventory, objects, marketplace, web, rlv lockdown, timers, and a raw packet escape hatch. because the surface is identical, a script written against the reference runs the same on either host. only the binding code beneath differs.
the three places we run code
- server — a vps hosting the hub and the bot fleet. services start at login, run on timers and events, and are controllable live over mcp.
- viewer (laptop) — the interactive client the operator sits in. it hosts luau services too, loadable at login or hot-swapped live over the hub without a restart.
- laptop tooling — a standalone luau runtime for scripts, one-off automation, and the local half of our mcp bridge.
a local-only setup just runs a bot and its services on one machine, straight to the grid — no hub, no server
the workflow
- write luau — a script, service, or tool, targeting the
client contract.
- compile-check — a fast static pass catches type and syntax errors.
- run against a live host — eval a snippet on a bot, or hot-reload a viewer service in place.
- verify, don't trust — a clean build is not a working feature; confirm the behavior actually shows up over the hub.
pure-luau changes hot-reload with no restart. only changes to the bindings surface need a rebuild.
the short version
bots and a viewer, all scripted in luau against one client contract. a local bot runs fine on its own — the hub and remote host are an optional layer that adds coordination, a persistent presence, and an mcp door. we build in luau end to end, verify live, and reuse third-party code without leaving the language.
the system is molting — 蜕变 — from a patchwork of hosts into one contract, one client, one language. that's the whole shape of it.