Model private information in multiplayer
https://patrickz.ai/learn/private-multiplayer-state/

OUTCOME
Separate public room state from private player information.

YOU NEED
A chat assistant and a paper or local prototype with two fictional players. No access to private source is required.

1. 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.

2. Build step 1
Build an offline pass-and-play round.

3. Build step 2
Define public and private state as separate schemas.

4. Build step 3
Add rooms and join codes.

5. Build step 4
Assign each seat an unguessable token.

6. Build step 5
Move private-hand creation to the server.

7. Build step 6
Add realtime updates for public state.

8. Build step 7
Test with two ordinary browser sessions, not only one developer account.

9. 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.

PROMPT
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.

EXAMPLE / 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
[ ] Private hands are absent from public state.
[ ] Each player request is authorized independently.
[ ] Reconnect preserves the correct player boundary.

IF IT FAILS
A hidden UI element does not protect data already sent to a browser. Private values must stay out of unauthorized responses.

MY RESULT / NEXT CHANGE