Scripts

Objects in The Wired can carry behavior as WebAssembly scripts. A script is called on three fixed entry points: init, once on load; update, once per rendered frame; and fixed-update, on a fixed interval independent of frame rate.

Scripts are sandboxed. They act on the world only through the host interfaces below, with no ambient network or filesystem access.

Interfaces

• scene — read and write prims: transforms, meshes, materials, colliders, rigid bodies, relationships.
• physics — raycasts, and live velocity/force control over a dynamic body, gated by holding authority over its document.
• portal — open a portal on a prim, or travel the local agent through one.
• input — listen for grab, menu, and scroll events on a prim, or globally.
• event — emit and listen for arbitrary messages, scoped globally or to a radius around a prim.
• kv — a small networked key-value store scoped to a document.
• agent / peer — read the local agent’s bones and camera, and identify the peer that owns a document.
• registry — query which registries the client follows.

Trust

A script is granted a fixed set of interfaces when loaded — a capability list, not something it negotiates at runtime. The space owner decides which documents, and therefore which scripts, are loaded into a space at all.

physics calls that move a body only take effect while the calling script’s document holds authority over it, claimed and released explicitly.

Portability

Scripts compile to a single WebAssembly binary, stored as a blob and loaded from that one blob by any UNAVI client — desktop, VR, or web.

Persistence

A script changes the scene it is attached to, and everyone present sees those changes immediately. Whether they outlast the session is separate: only saving the document, by someone holding its secret, makes a change durable. Scaffolding a script rebuilds every time it runs, so it never accumulates in the document, and no activity in a space can quietly rewrite what is saved without that explicit save.