# Actor Use Cases for Prosperon

Confirmed implementation targets. These are the concrete reasons actors add value beyond basic frame scheduling.

## 1. P2P Networking (Lockstep + Input Streaming)

Actor security model enables safe P2P:
- **Lockstep**: Both peers run the same actor with the same inputs. Actors are deterministic (same messages in = same state). Synchronize input streams.
- **Input streaming** (GGPO-style): Each peer sends inputs to the other. Actors only see inputs, not internal state, so cheaters can't fabricate state — only send inputs that the other peer validates by running the simulation.
- Security-first actor system makes this safe by design.

## 2. Game Sharing (DS Download Play Style)

Send entire cell packages over the network. Receiver runs the game in a sandboxed actor.
- A cell program/game sends its entire package (code + assets) using the cell package system.
- The other person runs it in a sandboxed actor — can't touch host filesystem, can't read save data, can only draw sprites and send messages through the allowed interface.
- Same trust model as mod sandboxing but for complete games.

## 3. Mod Sandboxing

Untrusted code runs in its own actor, communicates through a controlled message interface.
- Mods can't corrupt game state.
- Related to game sharing — same isolation model.

## 4. Background Asset Loading

Refactor the resource manager (currently single-threaded) into an actor:
- Game sends: `{type: 'load', kind: 'image', path: 'player'}`
- Resources replies: `{type: 'loaded', path: 'player', data: <blob>}`
- Game never blocks. Request assets, keep running, handle them when they arrive.
- Sprites show placeholder until real texture lands.
- This is the natural actor pattern: send a message, get a message back.

## 5. Editor <-> Game Isolation

Editor runs as a separate actor, sends commands to the game actor.
- Can't corrupt game state.
- Clean separation of concerns.
- Editor can inspect/modify game state only through the message interface.