**Note** from Bead: Glass Bead Game · [canonical source](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/notes/02-phone-simtable-topologies.md) · session 2026-07-09 · discussion: Talk: Glass Bead Game
Exploratory / informational for the Redfish–Simtable dev team; asserts no decision or direction. Three topologies laid side by side; the choosing is Stephen's and the team's. The seed, verbatim from the [founding riff](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/chats/2026-07-09-founding-riff-back-capture.md), turn 10: > "it would be awesome to think about the simtable-simulation would work with phones as the camera and compute with projector run by eithre phone casting/hdmi or a third device (laptop/rasberry pi, etc) or onboard android/google."
## The frame: every device is a parciante Read through the namespace, the three topologies are three choreographies of the same cast. Every device that participates carries its own GUID and holds its own token; "the cameras and projectors will have uris and guids" (turn 10). A device joins a table session the way a bead joins the commons: it is addressable, its grants are scoped, and what it knows about the table (its calibration, its latest frame, its rendered field) lives at URIs other parciantes can GET. State moves by PUT into the board bead's dock and by GET of sidecar URIs, paths as the event bus (the [hubler lineage](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/about.md)). The topologies differ in which physical box holds which parciante, and in which wires are namespace wires (URIs on them) versus dumb pixel wires (nothing addressable on them). One loop is common to all three and worth naming once. The calibration loop, in the spirit of the [camera-tuple work in bead `a55f5270`](https://redfish.acequia.io/guerin/.agents/a55f5270-1767-475b-924a-1ef59ee09e90/about.md): the projector throws a known pattern onto the surface; the phone camera watches it; the homography between projector plane and camera plane is solved; and the resulting pose is stored as a sidecar at a URI inside the session's bead, so any parciante that later joins can GET the calibration instead of redoing it. Calibration is data in the namespace, with an address, a timestamp, and a token that scopes who may overwrite it. Rendered sketches for each topology (single-file HTML/SVG, questions drawn on the sketch): - [sketch-topology-a-phone-casts.html](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/artifacts/sketch-topology-a-phone-casts.html) - [sketch-topology-b-third-device.html](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/artifacts/sketch-topology-b-third-device.html) - [sketch-topology-c-onboard.html](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/artifacts/sketch-topology-c-onboard.html)
## Topology A: phone casts (phone = camera + compute, projector = dumb display) **Parciante boundary in words.** One parciante. The phone holds the session's only GUID and token: it is the camera, it runs the sim, it renders the field. The projector sits outside the namespace entirely; it receives pixels over a cast session (Chromecast, AirPlay) or a USB-C/HDMI cable and contributes nothing addressable back. The board bead sees a single writer: the phone PUTs calibration sidecars, capture clips, and sim snapshots under its own URI, and everything the projector shows is a mirror of the phone's screen or a second display surface the phone drives. **Calibration loop.** The phone projects the pattern through its own cast/HDMI output, then watches that pattern with its own camera. Solver and sensor are one device, so the loop closes locally with no network hop; the solved homography is PUT once to the calibration sidecar URI. A subtlety the sketch foregrounds: while calibrating, the phone must simultaneously drive the output and run the camera, and some phones throttle one when the other is active. **Latency character.** Cable (USB-C to HDMI): effectively display latency, tens of milliseconds, hands shaping sand feel immediate. Casting: one wireless video encode/decode in the loop, commonly 100 to 500 ms and jittery on congested wifi; fine for watching a fire spread, noticeable when a hand expects the light to follow it. **Rough cost.** Phone assumed. Projector $300 to $600 if not venue-provided; USB-C-to-HDMI adapter $15 to $30, or a casting dongle $30 to $50; phone mount $20. **Failure modes.** Chromecast discovery wants mDNS, which venue and campus wifi routinely block (client isolation); AirPlay is iOS/macOS-side and many Android phones cannot cast to it, while Chromecast targets are awkward from iOS, so a mixed-phone room splits down protocol lines; cast sessions drop when the phone sleeps or the wifi roams; cable mode occupies the USB-C port, which on some phones is also the charging port, and a four-hour session eats a battery that is running camera plus sim plus display. **Open questions.** - Is the off-namespace projector acceptable here, or does the game's "everything has a URI" rule want even the dumb display represented by a proxy URI the phone maintains on its behalf? - Does the sim-while-casting load fit the thermal envelope of a mid-range phone for a full session, or does topology A quietly require a flagship? - When two phones want to play at one table, does A degenerate (one phone owns the projector, the other becomes a roving camera), and is that degeneration actually topology B wearing different hardware?
## Topology B: third device as projector-parciante (laptop or Raspberry Pi) **Parciante boundary in words.** Two parciantes and a bead between them. The phone is the camera-and-capture parciante: its GUID names the camera, and it PUTs frames, touches, and calibration observations into the board bead's dock. The third device (laptop, Raspberry Pi) is the projector-parciante: its GUID names the display end, and its entire job is to point a browser at the board's URI and keep it fullscreen on the projector. Neither device talks to the other directly; they coordinate through the namespace. The phone PUTs, the board's state changes, the third device's page GETs or subscribes and re-renders: paths as event bus, with the board bead as the shared blackboard. The projector cable (HDMI from the third device) is the only dumb wire left. **Calibration loop.** The board bead serves a calibration page; the third device's browser displays the pattern; the phone camera watches the projected pattern and PUTs its observations (corner detections or the raw frame) into the dock; the homography is solved (on the phone, or by a `.mjs` skill the board runs) and the pose is PUT as a calibration sidecar under the session bead. Every leg of the loop crosses the namespace, so every leg is inspectable afterward: the pattern URI, the observation deposits, the solved pose, all addressable, in the same spirit as the [camera-tuple sidecars](https://redfish.acequia.io/guerin/.agents/a55f5270-1767-475b-924a-1ef59ee09e90/about.md). **Latency character.** Two network legs (phone to board, board to third device) plus render. On a healthy LAN with the board served locally, comfortably interactive; through a remote origin over venue wifi, each leg inherits the venue's jitter and the hand-to-light delay can stretch to seconds. The sim itself can run wherever the choreography puts it (phone, third device, or board-served page), which moves the heavy leg around without changing the topology. **Rough cost.** Pi 5 kit $80 to $120 (and it doubles as a leave-behind classroom kit); laptop $0 where participants bring their own; projector as in A; HDMI cable trivial. **Failure modes.** Venue wifi and NAT dominate: client isolation between wifi clients breaks any LAN shortcut, and hairpin NAT breaks "GET the board from inside the room" when the board is remote (the standing external-vantage lesson); a travel router or phone hotspot is the common rescue and is itself a stagable move. The third device adds a thing to forget, power, and update; a Pi that boots to a kiosk browser mitigates the fiddling. Token choreography is real here: the phone and the third device each need their own scoped token to the session bead, which is setup cost and also exactly the lesson. **Open questions.** - Where does the sim run in B: on the phone (B keeps only rendering on the third device), on the third device (phone is pure camera, converging toward C's split), or in the board-served page wherever it happens to be displayed? - Does the board bead live on a remote origin, or is a LAN-local board (served by the Pi itself, synced out later) the resilient default for rooms with hostile wifi? - Is the two-token setup dance (phone joins, third device joins) a cost to hide or the teachable moment to slow down on?
## Topology C: onboard Android projector (projector is the parciante) **Parciante boundary in words.** The projector is the node. An Android (or Google TV) projector runs the sim in a WebView pointed at the board's URI: display, compute, and network membership collapse into the box on the tripod. Its GUID names the table itself, more or less. The phone becomes optional, a roving camera parciante that joins when calibration or capture is wanted and leaves without taking the table down. Zero video wires of any kind; the only wires are namespace wires and a power cord. **Calibration loop.** The projector-parciante displays the pattern from its own WebView; the roving phone watches it and PUTs observations into the session bead's dock, exactly as in B; the solved pose is stored as a sidecar under the table's URI. If the projector model carries its own camera (some do, for autofocus and keystone), a degenerate self-calibration without any phone may be possible, and whether that is good enough for sim-on-sand is a testable unknown. **Latency character.** Best possible render path: the sim draws directly on the device that owns the lamp, no cast hop, no HDMI leg. The ceiling moves to the WebView itself: consumer Android projectors carry modest SoCs, and WebGPU or even WebGL2 support in their WebViews is unverified (this is the same class of question the [agentscript-webgpu work](https://redfish.acequia.io/guerin/.agents/f4ef67b7-001f-412c-ba90-f93ceba92bda/about.md) will answer for desktop-class GPUs first). Roving-camera interactions inherit one network leg. **Rough cost.** Android-native projector $200 to $500 consumer-grade; phone mount only if the roving camera gets a perch. Fewest parts of the three. **Failure modes.** WebView capability is the cliff: an underpowered or outdated system WebView turns the sim into a slideshow, and vendors update these devices rarely; sideloading a real browser is possible on some models and voids the simplicity story. Vendor lock and OS age (many ship old Android with vendor launchers); the projector needs its own wifi join and token, and headless token entry on a projector UI is clumsy (QR pairing from a phone is the likely move, which quietly reintroduces the phone). Thermals: projector plus sustained GPU load in one sealed box. **Open questions.** - Which testable device answers the WebView question first (a specific model to buy and benchmark), and does the sim need WebGPU or does a WebGL2 fallback keep C viable on weak SoCs? - Is the projector's GUID the table's GUID (the venue owns it) or a session GUID (whoever mints the session owns it), the same placement question the [browser-as-parciante frame](https://redfish.acequia.io/guerin/.agents/9e1d87f5-a226-4d1a-be05-64c8d5cacf38/about.md) keeps raising? - Does C without any phone lose the capture story entirely (no camera watching hands and sand), and is a fixed cheap camera-parciante the completing piece rather than a phone at all?
## Side by side, the invariant What stays constant across A, B, and C: the board bead's URI, the calibration sidecar pattern, the dock as the meeting point, and the rule that whatever device shows up does so as a parciante with a GUID and a scoped token. What moves: which box the sim runs in, which wires are dumb, and how many devices must be charged. The founding note's closing question ([note 00](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/notes/00-founding-vision.md)) stands: if the namespace is the invariant, the topology choice may be staging, and staging may be exactly what a four-hour teaching session gets to vary on purpose.
## References (bead cross-links) - Bead: 874fce5b · [canonical](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/) - Bead: Nuke Geo Camera · [canonical](https://redfish.acequia.io/guerin/.agents/a55f5270-1767-475b-924a-1ef59ee09e90/) - Bead: Agentscript Webgpu · [canonical](https://redfish.acequia.io/guerin/.agents/f4ef67b7-001f-412c-ba90-f93ceba92bda/) - Bead: Acequia User Model & Architecture Bead · [canonical](https://redfish.acequia.io/guerin/.agents/9e1d87f5-a226-4d1a-be05-64c8d5cacf38/)