202 lines
7.1 KiB
Markdown
202 lines
7.1 KiB
Markdown
# Verse Authority Policy
|
|
|
|
Aetheria authority is Verse policy, not topology. A Raven Unity client, a
|
|
Starfire RTS client, a headless host, and later an MMO witness quorum should all
|
|
use the same policy boundary:
|
|
|
|
```text
|
|
typed operation
|
|
-> resolve subject and claim kind
|
|
-> resolve authority mode from the active Verse policy
|
|
-> apply, forward, defer, or reject
|
|
```
|
|
|
|
The first implementation is intentionally fast for trusted co-op. It does not
|
|
build quorum consensus on the hot path. It compiles the active policy document
|
|
and authority leases into an in-memory routing table, then tests incoming typed
|
|
commands before simulation.
|
|
|
|
## Policy Modes
|
|
|
|
The policy schema names the authority shapes Aetheria needs without requiring
|
|
all of them to be implemented at once.
|
|
|
|
- `any-trusted-runtime`: trusted co-op mode. Any runtime with the active Verse
|
|
rules may author matching claims.
|
|
- `host-authoritative`: only the configured host runtime may author matching
|
|
claims.
|
|
- `delegated-runtime`: one of the configured runtime ids may author matching
|
|
claims.
|
|
- `owning-runtime`: the runtime that owns the subject may author matching
|
|
claims. This is schema-level intent for now; ownership resolution must be
|
|
supplied by the runtime before this mode is enabled.
|
|
- `interest-lease`: a runtime with a matching unexpired lease may author
|
|
matching claims.
|
|
- `witness-quorum`: eligible witnesses publish observations; policy forms a
|
|
candidate; authority commits a fact. This is not implemented in the current
|
|
Aetheria hot path.
|
|
- `operator-finality`: operator or host finality is required before the fact is
|
|
committed.
|
|
- `mergeable-crdt`: independently authored state converges through explicit
|
|
merge laws. This is for state with real merge semantics, not simulation facts.
|
|
|
|
Unsupported modes fail closed with an explicit policy rejection. This keeps the
|
|
schema open without pretending future authority structures already exist.
|
|
|
|
## Command Claims
|
|
|
|
Daemon commands are lowered to a subject and claim kind before execution:
|
|
|
|
```text
|
|
subject key: entity/run/zone/item key affected by the operation
|
|
claim kind: movement, targeting, combat, inventory, economy, ai, metadata...
|
|
author runtime: command.AuthorRuntimeId, falling back to ClientId
|
|
```
|
|
|
|
For example:
|
|
|
|
```text
|
|
SetMoveVector(entity.player.raven)
|
|
-> subject entity.player.raven
|
|
-> claim movement
|
|
|
|
SetTarget(entity.player.raven -> entity.hostile.3)
|
|
-> subject entity.player.raven
|
|
-> claim targeting
|
|
|
|
TradePurchase(station -> player cargo)
|
|
-> subject target/destination entity
|
|
-> claim economy
|
|
```
|
|
|
|
The command executor only sees authorized commands. It should remain boring:
|
|
validate payload shape, mutate the run, emit intents. Authority decisions belong
|
|
to the policy router.
|
|
|
|
## Trusted Co-Op Shape
|
|
|
|
The default Aetheria policy is permissive trusted co-op:
|
|
|
|
```text
|
|
*
|
|
*
|
|
any-trusted-runtime
|
|
```
|
|
|
|
Raven/Starfire tests can then tighten this without changing gameplay systems:
|
|
|
|
```text
|
|
entity.player.raven
|
|
movement,targeting,combat
|
|
delegated-runtime: raven-unity
|
|
|
|
entity.rts.starfire.
|
|
movement,targeting,ai
|
|
delegated-runtime: starfire-rts
|
|
|
|
entity.hostile.
|
|
ai,movement,targeting
|
|
delegated-runtime: starfire-rts
|
|
|
|
entity.hostile.
|
|
close-combat-response,combat
|
|
interest-lease
|
|
```
|
|
|
|
That leaves the door open to witness-authoritative MMO policy later while
|
|
keeping the co-op hot path as a few string/prefix checks and set lookups.
|
|
|
|
## Simulation Host Packaging
|
|
|
|
Aetheria should not require the current C# daemon executable to be the only
|
|
packaging shape forever. It does require the Aetheria simulation host role to be
|
|
daemon-shaped: a runtime that owns the typed state graph, applies Verse policy,
|
|
advances simulation, publishes high-performance views, serves assets, and emits
|
|
Eve/CultUI surfaces.
|
|
|
|
A standalone process, embedded native host, or future WASM/native kernel can
|
|
package that role. Those are deployment choices, not gameplay authority modes.
|
|
Unity, Godot, Electron, Hermodr, and browser shells are render/input lowerers
|
|
unless they are explicitly running the daemon-shaped simulation host behind the
|
|
same typed CultMesh boundary. A renderer does not gain authority because it
|
|
spawned, embedded, or happens to sit beside the host.
|
|
|
|
The important boundary is not the executable. It is the policy document:
|
|
|
|
```text
|
|
runtime CultMesh client
|
|
-> typed command/proposal document
|
|
-> Verse authority policy
|
|
-> simulation-capable runtime lease/host
|
|
-> committed facts and local projections
|
|
```
|
|
|
|
If no standalone daemon process is deployed, an embedded host may still run the
|
|
same daemon-shaped simulation role and publish the same typed documents. The
|
|
client shell around it remains a renderer/input surface. Starbridge can refine
|
|
hot claims without changing client protocols:
|
|
|
|
```text
|
|
entity.player.raven
|
|
movement,targeting,combat
|
|
delegated-runtime: raven-unity
|
|
|
|
entity.hostile.
|
|
ai,movement,targeting
|
|
delegated-runtime: starfire-rts
|
|
|
|
*
|
|
inventory,economy,system
|
|
host-authoritative
|
|
```
|
|
|
|
This keeps every client honest: it can run CultMesh and submit typed commands,
|
|
but the daemon-shaped simulation host owns the committed game state.
|
|
|
|
## Current Local-Mirror Constraint
|
|
|
|
The current C# implementation is not a pure remote-client architecture yet.
|
|
Unity can select a remote CultMesh Verse, but gameplay boot still requires that
|
|
Verse to be hydrated into a readable local CultCache replica before the Unity
|
|
shell starts. The Electron Starbridge client likewise uses local daemon
|
|
publications while using CultMesh for typed command submission.
|
|
|
|
That constraint is acceptable as a migration bridge, but it must not become the
|
|
architecture. The end state is:
|
|
|
|
```text
|
|
CultMesh transport/subscription
|
|
-> typed Verse documents and operations
|
|
-> local runtime projection/cache when useful
|
|
-> renderer/input surface
|
|
```
|
|
|
|
The local cache is an optimization and offline/debugging aid. It is not the
|
|
authority boundary.
|
|
|
|
## Rust/WASM Simulation Kernel Migration
|
|
|
|
If browser-only clients are expected to take over simulation authority when no
|
|
local .NET daemon is available, the daemon should be split into an embeddable
|
|
simulation kernel and thin host shells. Rust is the strongest candidate for that
|
|
kernel because the same core can target native hosts and WebAssembly without
|
|
preserving the current local process/file assumptions.
|
|
|
|
The staged migration is:
|
|
|
|
1. Freeze the simulation contract in typed CultMesh/CultCache documents:
|
|
command inputs, authority policy inputs, tick inputs, committed facts,
|
|
frame/projection outputs, and deterministic error outputs.
|
|
2. Keep the C# daemon as the compatibility host while extracting every hot
|
|
simulation decision behind that contract.
|
|
3. Port the deterministic simulation kernel to Rust with matching schema
|
|
bindings and fixture-based parity tests against the C# host.
|
|
4. Compile the Rust kernel to native and WASM. Native and WASM hosts package
|
|
the same daemon-shaped simulation role behind the same typed CultMesh
|
|
contract.
|
|
5. Replace local-file-only readers with CultMesh subscriptions plus optional
|
|
local cache hydration, so remote Verse access does not require a C# process
|
|
on the same machine.
|
|
|
|
The C# daemon should then become one host shell among several, not the canonical
|
|
definition of simulation authority.
|