Page 2 · Architecture

Client & Server Architecture

Choose the side by authority, not by convenience. Client systems observe and present; server systems own persistent or privileged mutation.

Why the Split Exists

The physical client is the right place for input, camera, UI and perception. The logical server is the right place for authoritative state. 1.8 makes that distinction explicit so a no-cheats singleplayer world, a dedicated server and a client-only installation do not all need the same execution path.

System	Primary side	Notes
Movement / camera / keys	Client	Acts through the local player's normal control surface.
Recognition / menus / overlays	Client	Can be loaded locally even when a remote server does not run DAI.
Worldgen / experience state	Server	Persistent and authoritative.
Server functions / set block / inventory grants	Server	Require negotiated DAI server support.

Player Commands vs Server Authority

Player command

{
  "type": "run_command",
  "action": "say hello"
}

run_command uses normal player permissions.

Server-owned function

{
  "type": "server_run_function",
  "action": "my_pack:journey/resume"
}

server_run_function requests the DAI logical server to run the function with server authority while retaining player execution context.

Direct Authoritative Actions

server_set_blockaction = block state, target = x y z or relative coordinates.

server_break_blocktarget = position, state = whether to drop items.

server_give_itemaction = item ID, value = count.

server_take_itemaction = item ID, value = count.

Optional Networking

The DAI client checks whether the server negotiated the DAI payload channel before sending authoritative requests. Use one of the equivalent server-capability conditions to branch behavior:

{
  "type": "server_authority_available",
  "operator": "is_true"
}

Dedicated multiplayer security: do not design around arbitrary clients receiving unrestricted server privilege. Server-owned gameplay should be explicitly approved by the server's DAI policy.

Integrated Singleplayer

Integrated singleplayer has both a physical client and logical server in one process, but they are still treated as separate ownership domains. This is why a no-cheats experience can use server-owned functions without turning the player into an operator.