# Server architecture

The typical approach in a centralized single-world MMO, like EVE Online or Elite Dangerous, is to assign users to servers based on their location in in-world space.

This has several problems, some of which are specific to a decentralized game:

* Handover of players between servers in a continuous space is extraordinarily tricky. Elite is glitchy to this day, and EVE works around this by having discrete solar systems players must jump between.
* Resource shortages can still be caused by players crowding onto one server (e.g. Jita in EVE)
* In a decentralized world, the "owner" of an area of space, who operates the infrastructure for it, has disproportionate power. This can be abused in ways that do not detectably break the rules of the game, and thus cannot be punished by any sort of governance mechanism. For example, the server can reveal the positions of players to their enemies, who can then track them down with a plausible cover story.

Instead, we use a **org-based, non-local sharding system**. Some key features:

* **Player orgs run servers for their own entities** (players, assets, code, etc). The org server simulates game logic for all their players, as well as handling other intra-org logic such as communication, governance, software updates, etc.
* **Player-orgserver uses a server-authoritative client-server architecture**, similar to Eve Online. A player cannot cheat without a complicit orgserver.
* **Orgservers connect to each other with a generally mutually-trusting peer-to-peer architecture**, similar to traditional multiplayer games. Cheating is handled through governance and penalties against entire orgs.
* **Orgservers sync information pairwise tit-for-tat**. For example, A might ask B to provide A with a list of all entities visible from coordinate (x, y, z), but in the same request A must provide what exact entity is observing the world from (x, y, z).
  * This ensures *information symmetry between any two organizations*. Entities that enter stealth (e.g. submarines, ships in warp) cannot observe anything except through data gathered by other in-org entities that are not in stealth. Non-stealth is two-way.
  * This meshes nicely with "there is no stealth in space"
  * "Stealth abuse" (entering stealth without a plausible in-game physical reason, using stealth to hide evidence of teleportation cheating) is punished using governance. Orgs that properly keep merkle logs should be able to exonerate themselves.

## Efficient synchronization

Sending full entity lists to every orgserver does not scale.

Instead, orgservers A initially provides B with *a small number of* bounding boxes guaranteed to contain all their entities. Only if B is interested in data for a particular region does B then share exact coordinates of sensors in that region to obtain responses from A.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ostomo.gitbook.io/ostomo-notes/server-architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.