Before you start
A chat assistant and a paper or local prototype with two fictional players. No access to private source is required.
Why this lesson exists
This lab adapts the “Model private information in multiplayer” project write-up into a practice build. The time is an estimated first session, not a promise to finish a production system. Use the public repository as a reference when available; the exercise can be built with original sample content.
Do the exercise
Define the practice version
The archived card-game case study is useful for a general trust-boundary exercise. Start with an offline round and a table of who may know each fact.
Build step 1
Build an offline pass-and-play round.
Build step 2
Define public and private state as separate schemas.
Build step 3
Add rooms and join codes.
Build step 4
Assign each seat an unguessable token.
Build step 5
Move private-hand creation to the server.
Build step 6
Add realtime updates for public state.
Build step 7
Test with two ordinary browser sessions, not only one developer account.
Run the experiment
Draw the data returned to each player. Confirm neither response contains the other hand. Add reconnect and round reset without broadening that visibility.
A prompt to adapt
Replace the bracketed parts with your own practice details.
Work in a disposable practice project. Explain any setup requirements before changing files. Build one small step at a time and show how I can check it. Threat-model a multiplayer card game. Separate public room state, per-player private state, server-only state, and derived UI state. List attacks involving guessed room codes, stolen seat tokens, direct database reads, replayed requests, and a dishonest host. Write acceptance tests for a two-player realtime game. Prove that joining, readying, private hand delivery, bidding, challenge voting, reconnecting, and round reset work—and that neither client can read the other hand. My first-version boundary: The archived card-game case study is useful for a general trust-boundary exercise. Start with an offline round and a table of who may know each fact.
Run this experiment
Draw the data returned to each player. Confirm neither response contains the other hand. Add reconnect and round reset without broadening that visibility.
Check your result
Use evidence from your output. A confident explanation from the AI is not enough.
- Private hands are absent from public state.
- Each player request is authorized independently.
- Reconnect preserves the correct player boundary.
If it isn’t working
A hidden UI element does not protect data already sent to a browser. Private values must stay out of unauthorized responses.
Optional. Progress stays in this browser.
Where this came from
Adapted from an archived project architecture write-up. Its repository is private; this lesson uses only a general practice scenario and requires no private source code. Project coverage.
Prepared September 2026. Tools and interfaces change; use current official setup instructions. Session lengths are estimates.