# Networking and accounts

# Networking and accounts

`net` is built on one idea: **the game owns its backend**; the engine owns the mechanism. Everything that talks to a server sits behind an interface the game implements.

## Transports and replication

A `Transport` moves entity state between clients: `MemoryTransport` (tests and local), `HttpPollTransport` (a presence server: every client sets one record and reads the others') and `LiveKitTransport` (a data channel in a LiveKit room). A `Replicated` entity lists the `fields` that travel; `bodyField` replicates a physics body, and a body at rest sends only its pose. Remote players appear as avatars driven by the received state.

Besides entity state, a transport's presence server can hold **named records**: `PresenceRecordStore` sets and reads a record by name (`set` / `get` over the same wire), the server forgets one that nobody posts for about three seconds, and a client that cannot reach the server keeps its own posts for that long, so a player alone and offline still drives the state. `ProximityTransform` in gameplay packages (skill `ferret`) uses it.

## Gateways

`Gateways` holds the game's backends, each behind an interface (`GatewaySet`): account and currency, dialogue, zone occupancy, voice. `call(name, fn, fallback)` runs a backend call safely, so a game without a backend, or with one that is down, falls back instead of failing. The Camerlengo link (`CamerlengoClient`, `CamerlengoOccupancy`, `CamerlengoVoice`) is one implementation: a single endpoint, a command and its parameters.

## Voice

Voice rooms follow zones: entering a zone joins its room, leaving it leaves the room (`LiveKitVoice`). The LiveKit client is passed in, so the engine does not bundle it.

## Accounts

`AccountService` is the player's account in the game's own process: sign-in, a session kept between page loads, balances, and a gateway for `net`. `signInCard` is a ready sign-in form, with text a game can translate (`SignInStrings`).