Aether Engine Integration

XRUIOS.Permissions is not only the gate for XRUIOS apps. It is the same gate the HangarBay / Aether Engine mod sandbox uses to decide what an untrusted mod may touch. To the permission store a mod is just another requester id, so "grant Photos to this app" and "grant Calendar-read to this mod" are the same operation against the same authority. There is exactly one policy engine on the device, and mods live inside it.

Two walls, not one

Mod security in Aether is two complementary systems, and XRUIOS.Permissions is only one of them.

   untrusted mod DLL
        │
        ├── CasCore  ──────────►  ambient authority is UNCALLABLE
        │   (CasSandboxedLoader     System.IO, System.Net, Process, reflection-invoke,
        │    + CasModPolicy)        Godot camera/mic/screen - the IL cannot call them at all
        │
        └── the doors that remain ──►  host broker ──►  XRUIOS.Permissions (policy)
                                            │               keyed on the mod's ModId
                                            ▼
                                   host performs the action on the mod's behalf
                                   (the mod never receives the raw handle / stream / key)

CasCore (CasSandboxedLoader + CasModPolicy) is the code-access wall. A mod is loaded under a deny-by-default IL policy, so the dangerous APIs aren't gated - they're gone. The mod can't call File.Delete and be told "no"; the call is uncallable at the IL level.
XRUIOS.Permissions is the policy wall for the few brokered doors that remain. CasCore removes the illegal paths; XRUIOS.Permissions governs the legal-but-privileged ones (read the calendar, write to a shared folder, use the mic).

You need both. A policy engine alone can't stop a mod that calls System.IO directly; CasCore alone can't express "may read the calendar, may not delete events." One removes whole classes of attack, the other makes fine-grained decisions on what's left.

The mod system, piece by piece

Piece	Role
`CasSandboxedLoader`	Loads a mod DLL under CasCore with the deny-by-default `CasModPolicy`.
`CasModPolicy`	The IL policy - which namespaces/members are uncallable (IO, Net, Process, reflection, Godot sensors).
`CasPolicyAudit`	Records what the sandbox allowed/blocked, for review. Shared with the host.
`ModProfile`	One mod's identity: `ModId` (from the Notary-verified `PackageId`), `PrivateDirectory`, `IsStable`, and a local mirror of `GrantedCapabilities`.
`ModRegistry`	Enrolls mods, grants/revokes capabilities in XRUIOS.Permissions, hot-path `IsAllowed`, and builds each mod's jailed filesystem.
`PariahPermissionBroker`	Wraps the encrypted `PermissionHandler` store with a memo TTL for fast repeated checks.
`SandboxFileSystem`	The mod's only disk door: relative-only, `..` neutralised, symlinks/junctions resolved, hardlinks refused, reserved device names blocked.

The request path

A mod can't reach user data, so it asks. The gate is ModRegistry.IsAllowed(mod, capability), which delegates to PariahPermissionBroker.IsAllowed(mod.ModId, capability, level). If it returns true, the host performs the action and hands back the result. The mod never receives the file handle, the sensor stream, or an encryption key - only the outcome. Same shape as an XRUIOS app going through the Manager broker: the caller holds a capability, never the authority.

Identity is host-assigned - a mod can't self-report

ModProfile.ModId is derived from the Notary-verified reverse-DNS PackageId (com.hollvania.calendarwidget), assigned by the host at enrollment. A mod can't claim to be another mod to inherit its grants, because it never gets to state its own id - exactly like an XRUIOS app gets a Manager-minted app: id instead of naming itself. Without this, "grant Photos to the trusted mod" would be meaningless.

Signed vs ephemeral - trust that can't accumulate

Enroll(packageId) registers a signed mod with a stable ModId. Its grants persist across sessions, anchored to a Notary signature.
EnrollEphemeral(label) registers an unsigned mod with a fresh ModId each session, so any grants are session-scoped and evaporate on restart. Unsigned code cannot bank trust over time - you can let someone try a random .dll, but it starts from zero every run.

Even the filesystem is a permission

CreateFileSystem(mod, grantableRoots) returns a SandboxFileSystem. The mod always owns its private directory; every other directory is a named SandboxRoot that only opens when XRUIOS.Permissions grants the matching capability (e.g. fs.write:<root>). "Can this mod write here?" is the same IsAllowed check as "can this mod read the calendar?" - one store, one verb, whether the resource is a folder or an OS service. Sensors work the same way: camera/mic/screen are never on a mod's allow-list and are reachable only through a brokered device service the host holds.

The broker memoizes - why it's fast enough

A mod might ask "can I write here?" thousands of times a frame. PariahPermissionBroker wraps the encrypted PermissionHandler store with a memo TTL (ModRegistry(handler, context, privateRoot, TimeSpan? memoTtl)), so a verdict is cached briefly instead of decrypting the store on every call. A grant or revoke invalidates it. You get the security of an encrypted policy store without paying the crypto cost on the hot path.

One authority - the whole point

ModRegistry takes the host's Handler + AppPermissionContext - the same PermissionHandler.Handler the XRUIOS Manager uses, and the host's AppKey that never leaves it. There is one permission authority on the device, and mods are just more requesters in it. No second, weaker path for mods to slip through; the store and the audit are shared with everything else XRUIOS gates.

The test (real, against `PermissionHandler`)

XRUIOS.AetherModTest drives the real handler exactly as PariahPermissionBroker does under the hood: stand up a store, enroll two mods by package id, grant one a single capability, and ask the gate to rule.

// grant the calendar widget exactly one capability; the sketchy mod gets none
await handler.ChangePermission(SD(saveDir), SD(permClass),
    SD("Time.Calendar:GetEvents"), SD("com.hollvania.calendarwidget"), SD(masterKey), SDInt(1));

bool allowed = await handler.CheckPermission(SD(saveDir), SD(permClass),
    SD(capability), SD(modId), SD(masterKey), requiredLevel: 1);

mod	`Time.Calendar:GetEvents`	`Time.Calendar:DeleteEvent`
`com.hollvania.calendarwidget`	ALLOW	DENY
`com.evil.dataslurp`	DENY	DENY

The calendar widget reads events but can't delete them; the data-slurp mod, granted nothing, is refused outright - the identical gate the Höllvania calendar app hit for DeleteEvent. Mods and apps converge on one XRUIOS.Permissions authority.

Next: writing an app or mod against it - 8 - Building a XRUIOS App.

6 - Aether Engine Integration