XRUIOS.Barebones.wiki

1 - Welcome

Mon, 24 Aug 2026 21:30:16 GMT

The full XRUIOS solution: one Manager, a worker per class, and a permission wall between every one of them.
This is the assembled system, ported from XRUIOS.Barebones onto the Plagues trust model. Barebones was one project with ~400 functions. Here each system class is its own worker process with its own password and its own key, and a single XRUIOS.Manager holds the master key, gates login, and brokers every request through a permission check.This wiki is about the permissions. If you want the function catalog, that lives in the Barebones wiki; here we cover the walls: the groups, the per-worker isolation, the login that unlocks everything, and how one program shares data with another without either of them touching a key they shouldn't.This is a project I knew I wanted to make back since 2017 and after thousands of hours of work, grinding and time it seems things are finally coming together.The XRUIOS.XR library and Linux Distro are next, although keep in mind the XRUIOS works on Linux and Windows right now. apps ──► XRUIOS.Manager (broker) ──► worker (one class) │ permission check │ its own key + password │ per-worker key handoff ▼ └────────────────────────► another worker One Manager per device. It takes a global lock on start; a second Manager steps aside. It holds the master key and never hands it out. A worker per class. ~27 of them. Each compiles only its own class, so a breached worker doesn't even contain another class's code. Each gets its own password (PSK) and its own encryption key, both from the Manager. Nothing talks to a worker directly. Apps ask the Manager; the Manager checks the permission, then routes to the worker. Cross-class work goes worker → Manager → worker, so the same wall applies between workers. Process isolation. One class per worker. Compromise the Songs worker and you still can't reach Calendar's code - it isn't loaded there. Password isolation. Each worker has its own PSK. Only the Manager holds it, so only the Manager can talk to a worker, and a leaked PSK unlocks exactly one worker. Key isolation. Each worker's store is encrypted under its own key, derived from the master. A worker only ever receives its own key, so a breach reads its own data and nothing else. "Least privilege isn't a setting. It's the architecture."
1 - The Model - permission groups, the per-class workers, the three walls, and the threat model.
2 - Login and Keys - the login gate: Argon2 + OS-seal, and how one master key becomes a key per worker.
3 - Capabilities and Sharing - the capability naming, and the Höllvania calendar sharing events safely.
4 - Installing - start it in the background and at boot.
5 - Permission Catalog - every capability, by group and worker.
6 - Aether Engine Integration - the same gate that walls off Aether Engine mods, with a real test.
7 - Proven at Runtime - the end-to-end run, the pentest, and the bug the parallel launch found.
8 - Building a XRUIOS App - writing an app three ways: CMD, desktop, and an Aether Engine mod. Building - project setup, with the exact .csproj and DLLs for each kind:
1 - Project Types - the five project types and the reference matrix.
2 - A Worker - a system class as an isolated worker process.
3 - A CMD App - the smallest broker client.
4 - A Desktop App - the client behind a WPF/Avalonia window.
5 - An Aether Mod - a mod, and the multi-mod proving ground that registers each as its own app.
6 - The Diagnostics Harness - the fleet self-test. XRUIOS.Permission - the encrypted {app → {capability: level}} grant store the Manager checks. Pariah Cybersecurity - post-quantum primitives, SecureData, the anti-tamper watchdog every worker + the Manager run on start. Eclipse - the AES-256-GCM + Kyber encrypted transport between apps, the Manager, and workers.
Notary - the Blake3 anti-tamper check the Manager runs on a worker before it launches, and periodically after. Check 2 - Projects This Relies On to see all of these (They're Open Source)
Code: NON-AI MPL 2.0 Artwork: — NO AI training. NO reproduction. NO exceptions.
Unauthorized use of the artwork — including but not limited to copying, distribution, modification, or inclusion in any machine-learning training dataset — is strictly prohibited and will be prosecuted to the fullest extent of the law.

1.1 - What Is The XRUIOS

Mon, 24 Aug 2026 21:20:14 GMT

This is the assembled XRUIOS system, ported from XRUIOS.Barebones onto the Plagues trust model. Barebones was originally one project containing roughly 400 functions. In XRUIOS, those responsibilities have been broken apart: each system class runs as its own worker process, with its own password, its own cryptographic key, and its own isolated permissions. A single XRUIOS.Manager holds the master key, controls authentication, and brokers requests through an explicit permission check.This wiki is about those permissions. If you want the function catalog, that lives in the Barebones wiki; here we cover the walls: the groups, the per-worker isolation, the authentication process that unlocks the system, and how one program can share data with another without either program ever receiving a key it should not possess.The XRUIOS is ultimately an attempt to build a spatial operating environment rather than simply another VR application.
There are already projects moving in this direction. Stardust XR, for example, approaches XR as a Linux display server and spatial environment where traditional 2D applications and native 3D applications can coexist in physical space. Other projects such as Ethereal Engine/XREngine approach the problem from the perspective of the open social spatial web, while WebXR-based systems demonstrate that immersive experiences can increasingly move between browsers, desktops, phones, and headsets.The XRUIOS takes inspiration from that general direction, but its priorities are somewhat different.The goal is not to make XR something that requires the user to understand OpenXR, runtimes, drivers, compositor architecture, IPC, certificates, permissions, or cryptographic identities before they can use it.The goal is to make those things disappear behind the operating environment.Install it. Run it. Open an application.Whether the user is wearing a headset, using AR glasses, sitting at a conventional monitor, or interacting with another device should be an implementation detail rather than a fundamental division in the platform.That means XRUIOS is designed around three principles:Spatial computing should not require spatial-computing expertise beyond making cool UIs and basic coding knowledge.An application should be able to request a capability from the operating environment without needing to understand the entire security architecture underneath it. The Manager, workers, authentication system, and permission model handle the complicated parts.The same philosophy applies to users. If a device can provide the capability, The XRUIOS should attempt to expose it through the same environment rather than forcing developers to create completely separate applications for every form factor.Security is not supposed to be something added after the system works.Every major system capability is isolated behind a worker boundary. Workers do not simply receive unrestricted access to the rest of XRUIOS; they receive the credentials and permissions necessary to perform their assigned role.The Manager is the trust anchor.Applications authenticate with the Manager, requests are evaluated against permissions, and the appropriate worker performs the operation. A compromised worker therefore should not automatically become a compromised operating system.This is the part where the XRUIOS differs significantly from the traditional "one giant application with a lot of internal classes" approach that Barebones started from.The walls are part of the architecture.The XRUIOS is intended to treat XR as one possible interface to a broader computing environment, rather than defining the entire operating system around a headset.A headset might provide spatial windows, hand tracking, eye tracking and a 3D environment.A desktop might provide conventional windows, keyboard and mouse.A phone or tablet might provide a touch interface.Another computer might provide compute, storage, sensors, or a specialized service.The underlying application and permission model should not have to be reinvented simply because the display or input device changed.This also means that the XRUIOS is not intended to be XR-only.If somebody has no headset whatsoever, they should still be able to use the same ecosystem through a conventional display. If somebody later buys an XR device, that device should become another interface into the same environment rather than requiring them to abandon the desktop version.That idea is visible in several modern XR projects already: WebXR applications can expose the same experience through ordinary browsers while providing an "Enter VR" path when compatible hardware is available, and projects such as Flock XR explicitly allow projects to remain usable in a normal browser even when VR functionality is enabled.Te XRUIOS is taking that concept further down into the operating-system architecture itself.A useful way to think about the landscape is: Stardust XR — a spatial display-server/environment approach for Linux, allowing 2D and 3D applications to coexist spatially. WebXR / immersive-web projects — make XR experiences accessible through browsers and allow the same content to potentially work across conventional screens and XR devices. Ethereal Engine / XREngine — approaches the problem as an open social/spatial platform, with worlds, avatars, applications, and communication. XR desktop projects — focus on bringing conventional desktop computing into spatial displays, such as head-tracked virtual monitors. The XRUIOS — combines the spatial-computing idea with a general-purpose, cross-device application environment and a strongly isolated permission architecture, with usability and security treated as first-class requirements. The XRUIOS isn't trying to win by saying "we invented spatial computing."It is trying to answer a more practical question: What would happen if a spatial operating environment were designed from the beginning to be easy to use, secure by default, and capable of existing on devices that aren't even XR devices? The answer is what this project is becoming.This is also not a project that appeared overnight.I knew I wanted to build something like XRUIOS as far back as 2017.What started as an idea for a spatial operating system eventually became years of experimentation: hardware, rendering, input, tracking, operating-system architecture, application APIs, IPC, authentication, permissions, and eventually the realization that the system needed actual security boundaries rather than simply a large collection of cooperating classes.After thousands of hours of work, countless rewrites, and more than a few architectural mistakes along the way, the pieces are finally beginning to converge.The XRUIOS is the result of that process.The objective is no longer simply to make a VR interface.It is to build a computing environment where XR is a first-class interface, security is built into the architecture, applications can communicate without sharing trust they shouldn't have, and the same ecosystem remains useful even when the user isn't wearing a headset.

2 - Projects This Relies On

Mon, 24 Aug 2026 20:16:55 GMT

The XRUIOS is a project that took many years to create from concept alongside the many projects born to act as the foundation.Every Requirement Of The XRUIOS is Open Source, with a good chunk of them being creating by us @ Walker Industries. The Spatial Runtime for the XRUIOS.Coming soon...A seer for your files, watching over every file and remembering its every change even without constant observation.
Go Here
A tiny, cross-platform, fully local, per-user encrypted-at-rest secure key/value store that only the current logged-in user can read or write.
Go Here
A Free, Open Source Solution For Secure Application To Application Communication
Go Here
A Five Stage Protocol Handling Decentralized Sync and Communication
Go Here
A post-quantum code-signing and app-validation system that lets an app prove that every byte it ships is exactly what its author signed, and that no compromised host slipped something in (Before it ever launches).
Go Here
A complete .NET 8 security framework built for real-world apps — from password managers to distributed systems.
Go Here
A per-device, fail-closed permission system for XRUIOS — apps ask, the store answers, and nothing is trusted just because it says so.
Go Here
The orchestration layer that makes your phone, computer, headset, and TV behave like one device instead of five.
Go Here
A fully local, zero-trust system that splits every privileged operation into isolated, self-defending agents so a single breach doesn't mean death.
Go Here
The secure, Aether Engine focused content runtime designed to load, run, budget, and contain mod packages without trusting user input.
Go Here
An XR Focused Game Engine — Godot 4.7, rebuilt with VR, C#, and in-engine authoring baked in by Walker Industries.
Go Here
The System allowing millions of people to use the XRUIOS together. Coming Soon...

SCCN

Mon, 24 Aug 2026 20:04:07 GMT

AetherEngine

Mon, 24 Aug 2026 20:02:51 GMT

HangarBay.AetherEngine

Mon, 24 Aug 2026 20:02:19 GMT

Plagues Protocol

Mon, 24 Aug 2026 20:01:17 GMT

XRUIOS

Mon, 24 Aug 2026 20:00:35 GMT

XRUIOS.Permissions

Mon, 24 Aug 2026 20:00:04 GMT

Pariah Cybersecurity

Mon, 24 Aug 2026 19:59:16 GMT

Notary

Mon, 24 Aug 2026 19:58:24 GMT

YuukoProtocol 1

Mon, 24 Aug 2026 19:58:02 GMT

Eclipse

Mon, 24 Aug 2026 19:56:58 GMT

SecureStore

Mon, 24 Aug 2026 19:56:18 GMT

KeeperOfTomes

Mon, 24 Aug 2026 19:51:51 GMT

3 - ToDo

Mon, 24 Aug 2026 18:46:18 GMT

Implement WalkerWorks - The certificate issuance system is missing Manager needs it to encrypt/sign/verify worker certificates Currently using fallback/default signing Maybe version without WalkerWorks? Fix NotaryGuard Trust System - Currently trusts on first fire Should only trust the Manager's opinion This is a security vulnerability Remove Development Fallbacks Remove AllowAllPermissionGate() from workers Remove hardcoded "Test" encryption key Disable fallback mode paths (./XRUIOS, ./XRUIOSPublic) Complete App Registry Encrypted storage of per-app credentials PSK (32-byte identifier) system App Identifier verification (untampered install folder, process verification) Implement Audit Trail Workers log requests/responses to append-only audit trail Manager can read but not modify WalkerWorks - The certificate issuance system ServiceHost - Windows Service and SystemD integration AutostartInstaller - Startup configuration for both platforms

1 - The Model

Mon, 24 Aug 2026 18:45:37 GMT

XRUIOS splits into permission groups, and every group is made of per-class workers. The group is how you reason about access; the worker is where the isolation actually lives.That's ~27 workers. Each is its own executable (XRUIOS.Worker.), launched and supervised by the Manager.A shared library would put every class's code in one process. The permission check only guards the network boundary - it does nothing about code already loaded in memory. So a breached worker holding one big library could call any function in it, granted or not.Instead, each worker compiles only its own class. The Songs worker literally does not contain Calendar's code. There is nothing to reach.Cross-class calls go through the broker, never in-process. When a worker needs another class it asks the Manager, which permission-checks and routes to that worker. Same wall between workers as between apps and workers - and it's what lets an Android or macOS worker slot in later without changing any caller.1. Process isolation - one class per worker. Compromise a worker and you get its class, full stop. The other 26 classes aren't in that process.2. Password isolation - one PSK per worker. The Manager mints a fresh 256-bit password for each worker and hands it over out-of-band at launch. Only the Manager holds it, so only the Manager can complete a worker's handshake. A leaked PSK unlocks exactly one worker. On top of that, the worker verifies the Manager's signature, so a compromised worker (which holds only the Manager's public key) can't impersonate it.3. Key isolation - one key per worker. Each worker's store is encrypted under a key derived from the master (HKDF(master, "xruios-worker:")). The Manager can reproduce any worker's key, but each worker only ever receives its own. A breach reads that worker's data and nothing else - see 2 - Login and Keys. An app connects to the Manager's broker with its own app password + stable id. It asks for a capability by name. The broker checks the app's grant in XRUIOS.Permission - the encrypted {app → {capability: level}} store. Not granted means denied, before the request goes anywhere. If allowed, the broker relays it to the worker over the Eclipse channel and returns the result. The app never learns which worker answered, never holds a worker key, and never touches the OS directly.The point of three separate walls is that breaching one doesn't cascade. Concretely:The walls are independent on purpose: code isolation survives a key leak, key isolation survives a PSK leak, and the login gate survives everything downstream being wrong, because nothing downstream has a key until a human authenticates.
Next: how login unlocks all of this - 2 - Login and Keys.

2 - Login and Keys

Mon, 24 Aug 2026 18:45:26 GMT

Login is the gate. Nothing the Manager guards can be decrypted until a user authenticates, because the master key stays sealed until then. This is the most important security piece in XRUIOS, so it gets its own page. XRUIOS password ──Argon2id──► KEK ──AES-256-GCM unwrap──► master key │ ┌───────────────────┴───────────────────┐ HKDF per worker HKDF for the permission store "xruios-worker:Calendar" "xruios-permissions" The master key is a random 32 bytes, minted once per user. It is wrapped (AES-256-GCM) under a key an Argon2id KDF derives from the user's XRUIOS password (64 MiB, 3 passes). Only the salt, the wrapped bytes, and the KDF parameters are stored - never the master key or the password. Each user has a world-readable login file (/Users/.login.json): username, avatar path, and the password vector (salt + wrapped master key + Argon2 params). Anyone can read it, which is the point - a login screen lists the users on the device. Nobody can use it without the password, because the master key inside is wrapped.Warm (already logged in). While the OS session is alive, the master key is also sealed with the platform vault - DPAPI (CurrentUser) on Windows. The Manager unseals it with no password prompt. This is the "you're already logged into the OS, don't ask again" path. (Linux/macOS fall back to the password until libsecret/Keychain is wired.)Cold (typed password). No seal, or a fresh machine: you enter the XRUIOS password, Argon2 derives the KEK, and the master key is unwrapped from the public file. A wrong password fails the GCM tag, which is indistinguishable from a corrupt file, by design.Either way, XRUIOS.Manager login seals the key to the session; XRUIOS.Manager run unseals it and provisions the workers. No login means the Manager comes up locked - no keys, no workers, nothing decrypts.Once unlocked, the master key never leaves the Manager. Every worker key comes from it by HKDF with the worker's name as the label, and the Manager hands each worker only its own key at launch (out-of-band, the same channel as the worker password). So: The Manager can reproduce any worker's key on demand. A worker holds one key and can decrypt one store. A breach of the Media worker can't read the Time store - it never had the key. When XRUIOS creates an OS account for a user, the OS password is autogenerated and encrypted under the XRUIOS-derived key, so the system can authenticate that account later without a human retyping it. A recovery path re-wraps the master key so a forgotten XRUIOS password isn't the end of the account. (The Identity worker already carries the OS-auth half of this - LogonUser on Windows, PAM on Linux.)Next: what a granted app can actually call, and how two programs share events - 3 - Capabilities and Sharing.

4 - Installing

Mon, 24 Aug 2026 18:45:03 GMT

One Manager per device supervises the workers and holds the keys. You'll wrap this in a proper installer; here's what it drives.XRUIOS.Manager login # create / unlock the account; seals the key to this OS session XRUIOS.Manager start # launch detached in the background XRUIOS.Manager status # RUNNING / stopped XRUIOS.Manager stop login first-time-creates the account (username + XRUIOS password) and writes the public login file. After that, login unlocks it and seals the key so start/run come up already unlocked. No login and the Manager runs locked - no workers.The deploy folder has the ready scripts: deploy/windows/install-autostart.ps1, deploy/windows/install-service.ps1, and deploy/linux/xruios.service. Data + keys: %LocalAppData%\XRUIOS\ (Data, Public, Permissions, Baselines). Workers: found next to the Manager, or point XRUIOS_WORKERS_ROOT at the deploy folder so the Manager can launch them. Lay down the Manager, the ~27 worker exes, and libs/ together (or set XRUIOS_WORKERS_ROOT). Prompt the user to create their XRUIOS account (login). Register autostart - a logon task for a normal desktop, or the service for an always-on machine. On next start the Manager unlocks, checksums and launches each worker (each with its own key + password), and the broker is up. Back to the start: 1 - Welcome.

7 - Proven at Runtime

Mon, 24 Aug 2026 18:44:23 GMT

The permission model isn't just designed - it's been run end to end and attacked. This page is the evidence.XRUIOS.Manager login demo # Argon2id wraps the master key; DPAPI seals it to the OS session XRUIOS.Manager run # unseals, launches 27 workers IN PARALLEL, broker up XRUIOS.SampleApp # the Höllvania calendar app connects and calls capabilities Observed: Login created the user, wrote the public login file + the DPAPI seal. run unsealed the master key with no password prompt. 27/27 workers launched in parallel, each announcing its own loopback port, its own Kyber public key, and its own PSK. The Calendar worker advertised caps=[GetEvents, AddEvent, DeleteEvent]; the rest advertised their placeholder. The app completed the post-quantum handshake (Kyber + AES-256-GCM): SECURE. AddEvent (granted) ran in the Calendar worker and returned a real event id. DeleteEvent (not granted) was refused: XRUIOS.Permission denied 'DeleteEvent' for app:sampleapp. Every wall in 1 - The Model fired for real: process isolation (27 separate exes), password isolation (a PSK per worker), key isolation (an HKDF key per worker), and the permission check on the one privileged call.The tamper refusal was not staged - it happened for real when the workers were rebuilt: Notary compared them against its captured baseline, saw the binaries had changed, and refused every one until the baseline was re-captured. The anti-tamper works because it caught a legitimate change it wasn't told about.
Related: 1 - The Model · 6 - Aether Engine Integration

11- Sample App

Mon, 24 Aug 2026 18:42:04 GMT

A Warframe-1999-flavoured XRUIOS app (I LOVE WARFRAME 1999!!!). It is a "plain app": it holds only its Manager-issued credentials and talks to the broker. It Enrolls with the XRUIOS Manager Writes an event Reads the day and Deletes an event (This should never work on purpose, it's a test to see if XRUIOS Permissions work) Before logging out.

2 - A Worker

Mon, 24 Aug 2026 18:41:00 GMT

A worker is one system class running in its own process, exposing a curated set of capabilities the Manager can route to. This is where a new class from Barebones becomes a first-class part of the fleet. Every worker follows the exact shape of the Calendar worker.A worker is three files plus its system source:src/workers/XRUIOS.Worker./ ├─ XRUIOS.Worker..csproj compiles ONLY this class's source ├─ Program.cs boot: bind context, init, run the secured host ├─ Capabilities.cs the [SeaOfDirac] curated surface └─ (the class source lives once at src/systems/.cs, not copied here) The isolation is the point: the worker s just its own class file, so a breached Songs worker doesn't even contain Calendar's code. See 1 - The Model. net10.0 enable enable Exe XRUIOS.Worker. XRUIOS.Worker. That's the whole file. Two things to notice: Microsoft.NET.Sdk.Web, not the plain SDK - a worker hosts a MagicOnion/gRPC endpoint the Manager connects to. No references here. Everything a worker needs is in src/workers/Directory.Build.props, which every worker under src/workers/ inherits automatically: If your class needs a package no other class does, add it to that class's own .csproj rather than the shared props - keep the shared set to what every class needs.Capabilities are static methods marked [SeaOfDirac]. WorkerOcean scans the assembly for them; the Manager routes a call by the capability name. Keep the surface curated - the cross-program calls, not every public method.using EclipseProject; using XRUIOS.Barebones; namespace XRUIOS.Worker. { public static class Capabilities { // [SeaOfDirac(name, argNames, returnType, argTypes...)]. Return plain strings/DTOs so any // client can read them without sharing the class's internal types. [SeaOfDirac("DoThing", new[] { "input" }, typeof(string), typeof(string))] public static string DoThing(string input) => Class.DoThing(input); // Async is supported - return Task / Task. [SeaOfDirac("AddThing", new[] { "a", "b" }, typeof(string), typeof(string), typeof(string))] public static async Task AddThing(string a, string b) => await Class.Add(a, b); } }
Name capabilities uniquely across the fleet. The broker routes by capability name to the first worker that exposes it, so two workers exposing the same name collide. The convention is a worker-qualified name (Calendar.Ping, Alarm.Ping); the display form in the catalog is Group.Worker:Capability. See 5 - Permission Catalog.Every worker boots the same way: take the context the Manager handed it, do its own one-time init, then run the secured host.using System.Reflection; using XRUIOS.Interfaces; // 1. Bind the paths + key the Manager passed via environment (XRUIOS_DATA_PATH, _PUBLIC_PATH, _WORKER_KEY). global::XRUIOS.Barebones.XRUIOS.BindFromEnvironment(); // 2. This worker's OWN init. Each worker sets up its own store - the Manager never reaches into it. // (The old monolithic InitializeSystemAsync is gone; its per-class Initiate... step moves here.) System.IO.Directory.CreateDirectory( System.IO.Path.Combine(global::XRUIOS.Barebones.XRUIOS.DataPath, "")); const string ServerName = "XRUIOS.Worker."; // 3. Run: hardens the process, Notary-checks the folder, locks to the Manager's PSK, then serves. await SecureWorkerHost.Run( serverName: ServerName, capabilityAssembly: Assembly.GetExecutingAssembly(), gate: new AllowAllPermissionGate(), guard: NotaryGuard.ForCurrentWorker(ServerName)); Two things people ask about: Why AllowAllPermissionGate inside the worker? Because the permission check already happened at the Manager broker before the call was relayed. A worker only ever receives calls the Manager approved, and it only completes a handshake with the Manager's PSK - nothing else can reach it. The wall is at the broker; the gate here is just the seam. The init step is yours to wire. If your class assumed the old InitializeSystemAsync ran first, move that setup into step 2. Each worker is responsible for its own directories and defaults. Two edits outside the worker: Add the class to WorkerCatalog.Defs in the Manager (short name + its PermissionGroup) so the Manager launches and supervises it. Add the project to XRUIOS.slnx. Then grant apps the capabilities you exposed (permissions.GrantAsync(appId, ".DoThing")). Ungranted names are denied at the broker before they reach the worker.
Next: the client that calls it - 3 - A CMD App.

9 - XRUIOS.SecureLayer

Mon, 24 Aug 2026 18:31:47 GMT

This is the shell that handles most of the security layer for the XRUIOS.Handles the brunt load of allowing a standalone app to work with the XRUIOS Manager.Uses Eclipse/Sea of Dirac to expose the Worker functions, reusing Eclipse's security aspects and gating the calls through the Manager's IPermissionGate (albeit with a crypto channel).A simple class containing what the workers tell the XRUIOS.Manager about itself at startup so the XRUIOS can keep hold of it in it's registry (Capabilities, where to reach it and what can it do).The private key never leaves the worker.Handles hosting a Plagues worker behind an encrypted channel. Instead of just an IPublicAcc host and the self hash handshake, we now ensure it hasn't been tampered with, enforces a secure protocol (PlaguesDiracService) and publishes the ephemeral address for clients and the Manager to find it.The Public Account Information of XRUIOS related items, although just the struct for it.That code defines the permission checkpoint inside an XRUIOS worker. The worker gives it the caller's Eclipse identity (requesterUuid) and the capability being requested, such as Time.Calendar:GetEvents, and gets back true or false. Again, AllowAllPermissionGate is just a development stub that says yes to everything, so workers can run standalone during testing.In the real XRUIOS setup, the Manager's permission system replaces that with the actual authorization decision. Handles checking for tampering both at the start and periodically between XRUIOS Workers. It however also trusts on first fire to create a signature. If anything is tampered, the entire thing kills itself.In the future, we will only trust the opinion of the Manager for this instead of a first fire system.Wraps the entirety of the handshake/enrollment/transcript check to it's instead a simple to use command.The credentials the Manager gives to an an app, allowing it to access a broker. In production these will be given the first time an app verifies itself.

5 - XRUIOS.Worker

Mon, 24 Aug 2026 17:11:19 GMT

The XRUIOS workers are the isolated OS-level workers that the XRUIOS.Manager talks to. Each has a different identity and password branching from the manager. When started, each worker: Has a part of the XRUIOS master key but never the whole thing. The key is split using Shamir's Secret Sharing, so compromising a single worker reveals nothing useful. Verifies its own binary against a signed manifest before accepting any requests. Using Kyber post-quantum signatures and Blake3 hashing, it checks that its executable and DLLs haven't been tampered with. If they don't match, it refuses to run. Establishes a secure channel with the Manager using its unique identity and password (which are derived from the Manager's root secret and not stored anywhere in the worker). The channel uses the Eclipse secure protocol, which has authentication, encryption and resistance to replay attacks. Exposes only its registered capabilities. The worker doesn't have a general-purpose API; it only responds to the specific capability names it was built with. Anything else is rejected at the protocol level. Never authenticates clients directly. All incoming requests arrive already authenticated and authorized by the Manager. The worker trusts the Manager's signature on each request envelope, but not the client itself. Runs with the least privilege possible. Its OS-level permissions are locked down to exactly what its manifest declares it needs. Logs every request and response to an append-only audit trail that the Manager can read but not modify. If a worker is compromised, the audit log shows exactly what happened. Heartbeats to the Manager every few seconds. If the Manager stops hearing from a worker, it marks it as offline and routes future requests elsewhere. If a worker stops hearing from the Manager, it terminates itself to prevent orphaned or hijacked sessions. Can be revoked instantly as the Manager maintains a revocation list. Even if a worker is running, the Manager will reject its channel if it appears on the list, effectively killing its ability to participate in the system. Exits cleanly on any validation failure, meaning tampering, manifest mismatch, channel corruption, or unexpected state all cause an immediate shutdown with a diagnostic code written to the system log. The result: workers are thin, defensible, ephemeral, and replaceable. They trust nothing except their own binary signature and the Manager's cryptographically signed requests. They don't store secrets persistently. They don't make decisions about who can call them. They just execute their one job, verify the request came from the Manager, and return the result all inside a locked-down OS container that prevents them from reaching outside their designated scope.While the AllowAllPermissionGate() looks bad at first, the XRUIOS.Manager handles permissions and not the workers. An app is unable to actually talk with a worker unless it Know the worker's ephemeral port (not published anywhere) Know the worker's 256-bit PSK (only in Manager's memory) Bypass the NotaryGuard (worker would exit if tampered) Bypass the Manager's permission checks (centralized enforcement) Making this extremely hard to break. This pattern exists elsewhere and just makes standalone development easier.

12 - XRUIOS Diagnostics

Mon, 24 Aug 2026 16:34:59 GMT

Runs a quick check to ensure all parts of the XRUIOS works (The workers, apps, permission walls) and then sends back a report. Very simple!

CalendarAppXRUIOS

Mon, 24 Aug 2026 16:23:23 GMT

10 - XRUIOS.AetherModTest

Mon, 24 Aug 2026 16:13:45 GMT

The Aether Engine mod permission system is the bridge between Aether's mod sandbox and XRUIOS.Permissions. Instead of Aether creating a completely separate permission system, every mod is treated as a requester in the same permission store used by XRUIOS apps. Each mod: Has a unique identity based on its reverse-DNS package ID, such as com.hollvania.calendarwidget. In the real sandbox, this identity is tied to the mod's Notary-verified package. Uses that identity when asking XRUIOS.Permissions whether it is allowed to perform an operation. Is granted only the specific capabilities it needs. For example, the calendar widget can be granted Time.Calendar:GetEvents without being given permission to modify or delete calendar events. Is denied by default when no permission has been granted. A mod cannot simply request a capability and receive it. Has every capability checked against its own identity. com.hollvania.calendarwidget and com.evil.dataslurp are treated as completely separate requesters even if they ask for the same capability. Cannot turn a read permission into a write permission. Having Time.Calendar:GetEvents does not grant Time.Calendar:DeleteEvent. Uses the same Handler and permission store that XRUIOS uses for its other permission decisions, giving Aether a shared security authority rather than creating another independent permission database. Is checked before the sandbox allows the mod to reach a protected capability. The permission result becomes the gate between the mod and the underlying XRUIOS capability. For example:com.hollvania.calendarwidget └── Time.Calendar:GetEvents → ALLOW └── Time.Calendar:DeleteEvent → DENY com.evil.dataslurp └── Time.Calendar:GetEvents → DENY └── Time.Calendar:DeleteEvent → DENY Aether mods don't get access simply because they're running inside the engine. Their identity is given separately, and XRUIOS.Permissions decides what that identity is allowed to do. In short, each mod is treated like an app.The important distinction is that the mod's identity answers: "Who is asking?" while XRUIOS.Permissions answers: "Is that requester allowed to do this?" So the security model becomes:Mod ↓ Mod Identity ↓ XRUIOS.Permissions ↓ Capability Check ↓ ALLOW / DENY ↓ Aether CasSandbox ↓ Protected XRUIOS capability This means Aether Engine doesn't need to reinvent permissions for every mod. XRUIOS already has the authority that decides what each requester can access, while the CasSandbox enforces that decision before the mod reaches the protected capability.

8 - XRUIOS.Manager

Mon, 24 Aug 2026 16:11:15 GMT

If the XRUIOS.Core was the most important, the XRUIOS Manager is by far the most comprehensive part of the system. We will go over each script and what exactly it does.This is the same object type as before, being built up of The current Data Path The Public DataPath and The Encryption Key Used to pass to each XRUIOS Worker.Handles the launching of workers alongside protection. It checks for tampering against a known key and refuses to launch a tampered worker. It also is what generates the worker's access password that the manager keeps for handshaking later.It can also stop a tampered worker (or all workers) alongside protecting against hackers trying to jump on a port during a relaunch.Keeps ONE warm Eclipse session per worker so the broker stops re-handshaking on every call. This is done through a handshake with an enroll + Kyber + Dilithium sign/verify in aorund 14ms per.Also handles actually connecting a worker that changed address, restarted or died. The basic setup of the different workers, also highlights which directory is used to check for the default checksums. Contains the categorized (by permission group) classes alongside the addresses to each worker.Ensures only one XRUIOS Manager exists, at least in this fashion.Ensures the XRUIOS runs as a Windows Service on Windows, on Linux it's ran by SystemD.The general usage core of the XRUIOS, can be ran protected and interacted with through another program to login, start/stop services and do more.Ensures a permission file exists for each worker, then handles the checking, granting and rejection of permissions to apps (AKA why the "AcceptAll" at the Worker level is fine)Handles the verification of the workers once again, getting it from WalkerWorks and downloading it to check if true against a just hashed version of all the workers. WARNING I DID NOT MAKE WALKERWORKS YET, THE LOADBASELINE IS STILL INCORRECT Might make a default sign come with every XRUIOS, this leaves the only attack vector to being a zero day attack though but I think it's worth it. The actual orchestration system, handling logins, startup, status checks, stops and pretty much everything you see in Program.CS.The actual API used to create and sign up users for the XRUIOS cryptographically (completely local).Holds the master key once login unlocks it, then derives a key for each worker. Also handles wiping the key on logout.This basically is a master servant system, meaning the Manager holds all the keys for the different XRUIOS Workers based on the core key, but the workers themselves know no key other than their own.The Manager's certificate vault of what we use to certify the workers are what they say they are.WalkerWorks issues a cert → the Manager ENCRYPTS + SIGNS it → VERIFIES it → and only then trusts it • KeeperOfTomes — WATCHES the incoming folder and tells us the moment a cert is added (xxHash64 snapshot ledger; it detects, it does not encrypt).• Pariah — ENCRYPTS the cert bytes with the Manager's master key (PackData) and SIGNS the ciphertext with a post-quantum keypair (EasyPQC.Signatures).• The Manager — VERIFIES both (signature valid + decrypts back to the original) before the cert is considered trusted.The core that handles talking to different applications. It Checks XRUIOS.Permissions for appID and capability (Accept or deny) Finds the registerd worker connected to the capability in question Relay to the worker through the manager only channel the information and holds the results Reencrypts the bytes onto the app's channel and returns it. This was made specifically to ensure the app doesn't touch the worker or vice versa.Handles turning the XRUIOS into something that runs at the start of the machine's turn on life. For Windows, it also includes a way to turn it specifically into a Windows Service. This isn't needed for Linux, simply use install.Handles the encrypted storage of all the per app credentials held by the Manager. Holds each password the app itself should know, with the PSK being used as the permission identifier.This makes it so the Manager and workers don't even need to know what exact app is running, just it's 32 byte identifier!In the past, XRUIOS required apps to launch through it in order to do the verification. The app identifier makes it so any app can launch anywhere and then request to do the verification with XRUIOS at the App Registry.Handling one request at a time, it: Ensures the app exists in the App Registry Ensures the install folder is untampered using the Notary checksum verification Identifies the actual process making the request rather than trusting the app's claim of who it is Ensures the process is running from the app's registered installation path If all checks pass, the Manager returns the app's unique identifier, PSK, and broker address The app can then use those credentials to authenticate with the XRUIOS broker and access whatever permissions have been granted to that app This means an app no longer needs to be launched by XRUIOS itself. It can be launched normally, verify itself afterward, and securely establish its identity with the Manager.

7 - XRUIOS.Core

Mon, 24 Aug 2026 02:25:18 GMT

The XRUIOS Barebones Context Shim is the runtime environment provider that connects XRUIOS workers to their execution context. It serves as the bridge between the Manager's orchestration and the worker's operational environment.While seemingly simple, this is the most important file, quite literally acting as what everything else builds on.To begin, the XRUIOS.Core is what manages giving each worker the data path, the public path and each worker it's own encryption key.The Manager is the sole authority for context provision:The Manager passes context to workers through environment variables. These variables are passed from the Manager process to the worker process at launch, never touching disk.┌─────────────────────────────────────────────────────────────┐ │ Master Key │ │ (held by Manager in memory) │ │ │ │ │ ┌──────────────┼──────────────┐ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ Calendar Key Alarm Key Processes Key │ │ (worker 1) (worker 2) (worker 3) │ └─────────────────────────────────────────────────────────────┘ When running outside the Manager (e.g., during development), the shim falls back to:Warning: The fallback key ("Test") is insecure and must never be used in production. It exists solely to allow workers to run standalone during development.**

2 - Using Yuuko Bindings

Mon, 24 Aug 2026 02:24:49 GMT

Using Yuuko Bindings is very simple at the core.For an example, most usage will look likeGeneral Loop var bindings = new Bindings.DirectoryManager( Path.Combine( Environment.GetFolderPath( Environment.SpecialFolder.LocalApplicationData ), "XRUIOS", "Bindings" ) ); await bindings.LoadBindings(); var project = await bindings.GetOrCreateDirectory( @"D:\XRUIOS\Projects\MyProject" ); Console.WriteLine(project.Uuid); While saving the UUID and not the bare path.General Resolvingvar projectPath = await bindings.GetDirectoryById( project.Uuid ); if (projectPath == null) { // Ask user to locate the directory. } Binding files are usually directly saved between computers, meaning you aren't doing anything to affect the files beyond essentially copy/ To begin, create a Directory Manager. var manager = new Bindings.DirectoryManager( Path.Combine( Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "XRUIOS", "Bindings" ) ); The folder will later look likeBindings/ ├── A83F21D9C4B72E11.binding ├── 72B8D91A33F01C42.binding └── ...Although don't worry, if a manager already exists it will still When your app starts up, use await manager.LoadBindings(); To create a new binding, simply do string projectPath = @"C:\Projects\MyProjects"; var result = await manager.GetOrCreateDirectory(projectPath); Console.WriteLine($"ID: {result.UUID}"); Console.WriteLine($"Path: {result.REe2solvedPath}"); It is hashed from MachineName]FullPath should look like ID: D423FDENDVF Path: D:\Projects\MyProjects Warning MachineName is not the default one given but rather the one given by the XRUIOS Manager, from the cooresponding worker. Want to resolve a directory? All you need to do is string? path = await manager.GetDirectoryByID("D423FDENDVF"); if (path != null) { Console.WriteLine($"Path: {path}") } If the directory exists, it'll return. If there's a previously resolved path, it'll return that. If neither works, you can get a fallback. The bottom function here will create the path if it doesn't exist.string? path = await manager.GetDirectoryByID( "D423FDENDVF", "@C:\NewPath\Here" ); Let's say you have a directory at "C:\NewPath\Here" but you move the project to "D:\DifferentPath\Here". Our question is simple; how do you move the reference?You simply get the UUID ("D423FDENDVF") and create a new binding likeawait manager.UpdateBinding( "D423FDENDVF", new Bindings.DirectoryResolution( @"E:\Projects\ProjectA", verified: true ) ); Now using GetDirectoryByID will return the new path while the UUID stays the same!You can also create this explicitly with var reference = new Bindings.DirectoryRef( @"D:\Projects\MyProject", Environment.MachineName ); var binding = new Bindings.DirectoryBinding(reference); binding.SetResolution( new Bindings.DirectoryResolution( @"D:\Projects\MyProject", verified: true ) ); But it's not worth it for most cases compared to the already existing methods!

6 - XRUIOS.Contracts

Mon, 24 Aug 2026 02:09:01 GMT

For workers to work, they need a data path, the location of the public data path and their per worker encryption key. This has the interface responsible for handling these between XRUIOS Workers.Moreover, this contains the PermissionGroup enum, allowing permissions to be split across 7 groups.Very simple!

3 - XRUIOS.Systems

Mon, 24 Aug 2026 00:45:48 GMT

XRUIOS.Systems is a port of XRUIOS.Barebones, made specifically to handle the brunt of data loading and management. Each is then turned into a worker within a later step, made to be easy to use, performant and cross platform friendly. In short, this acts as the main heart of the XRUIOS.Alongside this, almost all things are encrypted at rest through AES-256 among other things from Pariah Cybersecurity.Each part has a CRUD style system alongside an initializer. Let's look at the NoteClass for example. Save Journal - Creates a new journal and saves it, encrypted AddJournalToFavorites - Adds a journal to a favorites list AddHistoryEntry - Saves a version of a journal GetAllJournals - Gets all journals on the system (OR with a specific name) GetCategory - Gets a specific category from a Journal with a specific name GetJournalFavorites - Gets all favorite journals, also has async version that can get only resolved RemoveJournalFromFavorites - Removes a specific journal from favorites GetHistory - Gets the specific history of an item UpdateJournal - Replaces a journal with a more updated version DeleteJournal - Removes journal from existence. RemoveJournalFromFavorites - Removes a journal with a specific name from favorites There are also purposefully empty workers, meant to later be filled with WIP APIs (Facade for example handles desktop mirroring/streaming).
Learn more at the XRUIOS.Barebones repo, where the indepth wiki exists.

4 - XRUIOS.Interfaces

Mon, 24 Aug 2026 00:45:00 GMT

These are mainly just the structs and records the XRUIOS works. Depending on what you want your application to do, you should reference some, all or even at times none of these!As an example, SongOverview is a field rich record made to give developers all the information they might want to make the best applications possible without placing users at risk. public record SongOverview { // Title public string SongName { get; set; } public string? AlbumName { get; set; } // Artist public string TrackArtist { get; set; } public string? AlbumArtist { get; set; } // Media Playback public TimeSpan? Duration { get; set; } public DateTime? ReleasedOn { get; set; } public DateTime? LastPlayedOn { get; set; } // Identifiers public Guid? SongId { get; set; } public string? ISRC { get; set; } public string XRUUID { get; set; } // Other Data public int? TrackNumber { get; set; } public bool? IsFavorite { get; set; } public int PlayCount { get; set; } public SongOverview() { } //Contstructor in the actual file
Learn more at the XRUIOS.Barebones repo, where the indepth wiki exists.

1 - Yuuko Protocol.XRUIOS.Interfaces

Sun, 23 Aug 2026 04:56:31 GMT

This is a DLL containing what is essentially the core of the XRUIOS and Yuuko Protocol equally.I created this because I didn't want to have to handle "Which file does this correspond to on this device?" later. It also makes a few cross platform things easier to deal with.An app is simple and has 8 records: The overview has The name of the app as a Yuuko Protocol Reference The minimum required Yuuko Version (for future Yuuko Protocol updates that add completely new features not able to be worked with older versions, we will try to not make many of these on the WI side) The developer ID The public key The UUID The name of the app itself A description and The Primary Platform it supports (Linux CMD/Windows Desktop/ Etc. Parameters are a value we feed into an event (AKA a function) A name Parameter Type (string, byte array, etc.) if it's required The default value (Optional) and A list of choices (Objects, optional) Events are just functions you can push, built up of A name A description An optional list of parameters (AKA the last thing we just hit) and The command that can be interpreted 4.OS Specific Apps are powerful, allowing you to get the same app for a different OS! This is useful for doing stuff like installing Yuuko Protocol across all your devices. Each is built of 1. The name of the OS 2. The version of the OS 3. The link to download it and 4. The Panel info (Which we will get into next)Since this deals with auto downloads, we sign each App through Notary and check it here for tampering. To begin, we have "panels". Don't think of it in the same way you normally think of panels. Instead, look at it like a "grid" within reality. It can be 2D, 3D or more but at the end of the day it's taking up some level of space. A panel contains a Mode (2D Like Desktop or CMD, 3D Like VR or MR, CMD For Command Line) View (Maximized, Minimized and Widget) As an example, Call of Duty is 2D Maximized while a simple graphical interface to access it could be considered 2D Minimized and a rainmeter style UI could be considered a 2D widget. Preferred Platform Mapping simply is "What does this app like?". This is important to include because it's possible to for example render a 2D view as 3D but it doesn't mean it's meant to be ran as such. Ever tried to do something between two operating systems but the way the files are interpreted are different completely in part due to their location? Bindings try to fix this issue. We simply reference files and such by a UUID rather than their path and figure out their connection from there.There is much more nuance to this, but let's look at a few bases for this. FileRecord is built up of a UUID generated and the file name. Directory is exactly this but for paths. Meaning you can name a folder "Default OS Level Documents Folder" or something as abstract as "My Movie Collection" Bindings handles figuring out the directory from a UUID alongside resolving it. This means if you save the UUID of the folder (You should do this), the XRUIOS will either automatically figure it out or take in user input.Media handles this exact same sentiment at the file level.

Aether Engine

Fri, 21 Aug 2026 14:37:19 GMT

YuukoProtocol

Fri, 21 Aug 2026 14:37:19 GMT

LibraryHeroXRUIOS

Fri, 21 Aug 2026 14:37:19 GMT

headerCapsuleXRUIOS

Fri, 21 Aug 2026 14:37:19 GMT

HangarBayAetherEngine

Fri, 21 Aug 2026 14:37:19 GMT

6 - The Diagnostics Harness

Fri, 21 Aug 2026 13:33:11 GMT

XRUIOS.Diagnostics is the fleet self-test - the old Program.cs test suite reborn for the ported architecture. Instead of calling each class in-process, it connects to the Manager broker as a normal app and exercises the live workers through it. It's the fastest way to answer "is the whole thing actually up and behaving?" - and the regression net to run before and after touching anything.Three things, end to end: Every worker is up and individually routable - each answers its own .Ping health probe. A real capability round-trips - Calendar AddEvent returns an id, then GetEvents reads it back. The permission wall holds - an ungranted call (DeleteEvent) and an unknown capability are both refused. The exit code is the number of hard failures, so it drops straight into CI or a pre-work smoke check.It's a plain broker client, same shape as the CMD app: Exe net10.0 enable enable XRUIOS.Diagnostics XRUIOS.Diagnostics ..\..\libs\EclipseProject.dll Nothing special: XRUIOS.SecureLayer for the client, EclipseProject.dll for the transport, Spectre.Console for the results table.Each worker exposes a uniform health probe - .Ping (Calendar.Ping, Alarm.Ping, …) that echoes its own identity. Because the broker routes by capability name, a unique name per worker is what lets the harness confirm each one individually. The harness holds the list of workers, pings each, then runs the Calendar round-trip and the two security probes:// liveness: ping every worker by its own name foreach (var w in workers) { string echo = await mgr.InvokeAsync(w + ".Ping", new() { ["input"] = "diag" }); bool ok = echo.Contains("XRUIOS.Worker." + w); // it answered, and it's the right one } // security: this must be REFUSED (the app isn't granted DeleteEvent) try { await mgr.InvokeAsync("DeleteEvent", new() { ["uid"] = "x" }); /* FAIL if it goes through */ } catch { /* PASS - refused by XRUIOS.Permission */ } The Manager grants the diagnostics app every .Ping plus Calendar's GetEvents + AddEvent (but not DeleteEvent, so the refusal is a real test). That grant is data-driven in ManagerHost.StartCoreAsync from WorkerCatalog.AllShortNames, so a new worker is covered the moment it's in the catalog.With an unlocked Manager and the fleet up:dotnet run --project src/XRUIOS.Diagnostics A proven run against all 27 workers:Transport Post-quantum handshake PASS SECURE Liveness Songs.Ping PASS up + routable … (all 27 workers) … Calendar AddEvent PASS uid 81e19ab7-… Calendar GetEvents WARN write ok, read didn't list it (known CalendarClass quirk) Security DeleteEvent (not granted) PASS refused: XRUIOS.Permission denied… Security Unknown capability PASS refused: XRUIOS.Permission denied… ─────────── 31 passed 1 warn 0 failed · 32 probes ───────────
The one WARN is honest: GetEvents can return empty right after a write (a date/parse quirk in CalendarClass) - a functional bug, not a security one, so it's a WARN and the run still passes. See 7 - Proven at Runtime.As a worker's curated surface fills in (right now only Calendar's is live), add real probes for it here - a granted round-trip and, where relevant, a denied call to prove the wall. The harness grows into a full behavioural test of the fleet, one worker at a time, without ever reaching past the broker.
Back to 1 - Project Types.

5 - An Aether Mod

Fri, 21 Aug 2026 13:32:45 GMT

A mod is untrusted code loaded inside a HangarBay / Aether Engine host. It can't open a socket to the broker - CasCore makes System.Net uncallable - so the host holds the permission authority and the mod asks it. The gate is the same XRUIOS.Permissions store the Manager uses for apps; a mod is just another requester id in it. The concepts are in 6 - Aether Engine Integration; this page is how to set the projects up.There are two projects: the host (which enrols and gates mods) and the mod (untrusted, loaded under CasCore).Lives in the Aether Engine solution, targets net8.0 (CasCore + the vendored XRUIOS.Permissions DLLs are net8.0). Exe net8.0 enable disable ..\refs\PermissionHandler.dll ..\refs\PariahCybersecurity.dll Why each:That last row is the one gotcha - a copies the DLL but not its NuGet dependencies, so the store's transitives must be named explicitly.The mod references nothing except the jail type it calls, and even that is not copied (the host provides it). Targets net8.0. net8.0 disable MyMod false Private=false matters: the mod uses SandboxFileSystem's type to compile, but must load the host's copy at run time, not ship its own. Everything else a mod might reach - File, Process, sockets, sensors - it simply doesn't reference, and CasCore makes them uncallable anyway.One ModRegistry over the host's shared store. Each mod is Enrolled by its package id (which becomes its host-assigned ModId) and granted its own capabilities. Grants to one never touch another.// the host's ONE permission authority var context = new AppPermissionContext(SD(storeDir), SD(permClass), SDk(masterKey)); using var registry = new ModRegistry(handler, context, privateRoot, memoTtl: TimeSpan.FromSeconds(2)); // each row = "register this as its own app, grant it exactly these" var mod = registry.Enroll("com.hollvania.calendarwidget"); // host-assigned ModId, never self-reported await registry.GrantAsync(mod, "fs.read"); await registry.GrantAsync(mod, "fs.write"); await registry.GrantAsync(mod, "fs.read:shared"); await registry.GrantAsync(mod, "fs.write:shared"); // hand it its OWN jail: private dir always; the "shared" root opens only with fs.*:shared granted var fs = registry.CreateFileSystem(mod, new[] { new SandboxRoot("shared", sharedDir) }); // live check, keyed on the mod's id (memoised so per-frame IO is cheap) bool ok = registry.IsAllowed(mod, "fs.write:shared"); Signed vs ephemeral: Enroll(packageId) gives a stable id whose grants persist across sessions; EnrollEphemeral(label) gives a fresh id each run, so unsigned code can't bank trust. Filesystem access is itself a permission - the self dir needs fs.read/fs.write, a named root needs fs.read:/fs.write:.Hangarbay.AetherEngine.MultiModProvingGround is exactly this, built and run. It loads the default mod template (HostileMod) three times under three package ids, grants each a different set, and checks the outcomes headless:app private shared escapes ------------------------------------------------------------------------------ com.hollvania.calendarwidget allow allow blocked com.hollvania.musicviz allow deny blocked com.evil.dataslurp deny deny blocked ------------------------------------------------------------------------------ Same mod code, three registrations. Access follows the grant, not the code. Same bytes, three identities, three access levels - and every raw File / Process / socket escape blocked by CasCore for all of them, regardless of grants. Run it with dotnet run in that project; it exits non-zero if any expectation fails, so it drops into CI next to the single-mod proving ground.To add a distinct mod, copy the default Mod template to a new project with its own AssemblyName, stage its DLL into the host's mods/ folder (the host's StageMods target does this), and enrol it under its own package id.
Next: the fleet self-test - 6 - The Diagnostics Harness.

4 - A Desktop App

Fri, 21 Aug 2026 13:32:04 GMT

A desktop app is the CMD app with a window on top. The broker client is UI-framework-agnostic, so the rule is simple: the connection lives in a small service, the UI binds to it, and no XAML/AXAML ever calls a worker. WPF, Avalonia, and OpenSilver differ only in the view layer.Start from the CMD app's project and add the UI framework. WPF (Windows-only): WinExe net10.0-windows true enable enable ..\..\libs\EclipseProject.dll The XRUIOS references are identical to the CMD app - XRUIOS.SecureLayer + EclipseProject.dll. Only the SDK properties change:The client stack does not care which you pick.Wrap the four-line client in a class the UI can hold. Nothing here is WPF- or Avalonia-specific.public sealed class XruiosClient { private EclipseSecureClient? _mgr; public async Task ConnectAsync() { var (addr, id, psk) = AppCreds.LoadFor("mydesktopapp"); // env / creds file, as in the CMD app _mgr = await EclipseSecureClient.ConnectAsync(addr, id + "-ui", Convert.FromBase64String(psk), identity: id); } public Task GetDayAsync(string day) => _mgr!.InvokeAsync("GetEvents", new() { ["day"] = day }); public Task AddAsync(string day, string summary) => _mgr!.InvokeAsync("AddEvent", new() { ["day"] = day, ["summary"] = summary }); } await marshals back to the UI thread, so the only discipline is: don't block on the connection, and do the work off the constructor.public sealed class DayViewModel : ObservableObject { private readonly XruiosClient _client; public ObservableCollection Events { get; } = new(); public async Task LoadAsync(string day) { string raw = await _client.GetDayAsync(day); // off the UI thread Events.Clear(); foreach (var line in raw.Split(';')) Events.Add(line.Trim()); // back on it } } The window is then just a list bound to Events and a button that calls AddAsync then LoadAsync. The XAML never sees the broker, never holds the PSK, never names a worker - it only knows the view model. Connect once, async, off the constructor. Do the handshake in OnStartup (WPF) / OnFrameworkInitializationCompleted (Avalonia), show a "connecting" state, and enable the UI only when it's up. A failed handshake is a normal state - "XRUIOS is locked, log in first" - not a crash. A denied capability is a UI affordance, not a swallowed exception. If you weren't granted DeleteEvent, don't render a delete button. The broker refuses it regardless, but a good app doesn't offer what it can't do. Catch the denial and disable. The PSK still comes from the Manager. A desktop app is more tempting to ship with a baked-in secret. Don't - load it from the creds the Manager wrote, exactly like the console app. Ship the exe with no secret in it. That is the entire difference between a desktop app and a console app: the connection is async, the denials are visible, and the four-line client sits behind a view model instead of Main.
Next: untrusted code, same gate - 5 - An Aether Mod.

3 - A CMD App

Fri, 21 Aug 2026 13:31:40 GMT

The smallest thing that talks to XRUIOS: a console program that connects to the Manager broker with its own credentials and calls capabilities by name. This is the reference shell - XRUIOS.SampleApp (the Höllvania calendar) is exactly this, and every other client is a variation on it. Exe net10.0 enable enable XRUIOS.MyApp XRUIOS.MyApp ..\..\libs\EclipseProject.dll Why each reference:That's the entire dependency set. An app needs nothing from the system classes, no keys, no Pariah - it only knows how to ask the broker.An app needs three things, none of which it invents: its id, its PSK, and the broker address. The Manager provisions them. Look for them in this order:// 1. environment handoff (the Manager can launch you with these set) string? appId = Environment.GetEnvironmentVariable("XRUIOS_APP_ID"); string? pskB64 = Environment.GetEnvironmentVariable("XRUIOS_APP_PSK"); string? brokerAddr = Environment.GetEnvironmentVariable("XRUIOS_BROKER_ADDR"); // 2. a creds file the Manager wrote (dev convenience) if (appId is null || pskB64 is null || brokerAddr is null) (appId, pskB64, brokerAddr) = TryCredsFile("myapp"); // %LocalAppData%\XRUIOS\Public\myapp.creds // 3. self-enroll against the running Manager if (appId is null || pskB64 is null || brokerAddr is null) { var prov = await XruiosEnrollment.EnrollAsync("myapp"); appId = prov.AppId; pskB64 = prov.PskBase64; brokerAddr = prov.BrokerAddress; } byte[] appPsk = Convert.FromBase64String(pskB64!); The PSK never lives in your binary. Copy the exe to another machine and it authenticates as nobody, because the id and PSK were minted by this machine's Manager. That's what makes "just send me the exe" safe.using XRUIOS.Interfaces; // brings SecureLayer's client types // post-quantum handshake (Kyber + AES-256-GCM). identity: is your stable app id. var mgr = await EclipseSecureClient.ConnectAsync(brokerAddr!, "myapp-client", appPsk, identity: appId!); // a granted capability runs in the owning worker and returns its result string uid = await mgr.InvokeAsync("AddEvent", new Dictionary { ["day"] = "2026-08-21", ["summary"] = "Ship it" }); // an ungranted capability is refused at the broker before it reaches a worker try { await mgr.InvokeAsync("DeleteEvent", new() { ["uid"] = uid }); } catch (Exception ex) { /* XRUIOS.Permission denied 'DeleteEvent' for app:myapp */ } await mgr.DisposeAsync(); InvokeAsync packs the args, sends them over the encrypted channel, and deserializes the reply to T. The capability name is the whole API - what you can call is exactly what the Manager granted you.On the Manager side, registering an app and granting it is two lines (see ManagerHost.StartCoreAsync):var cred = apps.Register("myapp"); // mints the app's own PSK await permissions.GrantAsync(cred.AppId, "AddEvent"); // grant each capability by name // then WriteDevCreds(cred, brokerAddr, "myapp.creds"); // so the app can find its creds Anything you don't grant is denied. That's not an error path to code around - it's the model. A good app doesn't offer actions it wasn't granted.Next: the same client behind a window - 4 - A Desktop App.

1 - Project Types

Fri, 21 Aug 2026 13:30:36 GMT

There are five kinds of project in and around XRUIOS. They differ mostly in what they reference and how they start; the security contract underneath is the same. This section has a page for each with its exact .csproj, the DLLs and packages it needs, and why each one is there.What each project type actually pulls in. "Project" = a ProjectReference in this solution; "DLL" = a Reference with a HintPath into libs/; "Package" = a NuGet PackageReference.● required ○ optional (only if you use it). ¹Secure Store.dll for the Aether host's store. ²the worker gets these transitively through Directory.Build.props.Whatever the shell, the app never holds the authority - it holds a capability and asks. A worker only ever receives its own key and PSK; an app only ever gets its Manager-minted id and PSK; a mod gets neither and asks the host. If a project you're writing wants to reach a key, a socket to another worker, or the OS directly, it's built wrong - route it through the broker (apps/workers) or the host (mods). See 1 - The Model.Start with the type you're building:
2 - A Worker - the biggest one; a new system class becomes a worker here.
3 - A CMD App - the smallest client; the reference shell.
4 - A Desktop App - the client behind a window.
5 - An Aether Mod - untrusted code, same gate.
6 - The Diagnostics Harness - the fleet self-test.

8 - Building a XRUIOS App

Fri, 21 Aug 2026 07:27:17 GMT

An "app" on XRUIOS is anything that holds a stable id + its own app password (PSK) and talks to the Manager broker over the Eclipse channel. It never touches a worker, a file, or a key directly - it asks the broker for a capability by name, and the broker either runs it in the owning worker or refuses it. That contract is identical whether your app is a console tool, a desktop window, or a mod running inside a game engine. Only the shell around the client changes.This page builds the same tiny app - read today's calendar, add an event - three ways: CMD, desktop, and an Aether Engine mod. Then it covers the shared pieces (initialization, capability naming, failure) that apply to all three.your app ──(app id + app PSK)──► Manager broker │ post-quantum handshake (Kyber + AES-256-GCM) │ XRUIOS.Permissions check on the capability name ▼ owning worker runs it, result comes back Three things your app always needs: An id the Manager minted for it (app:yourname). You don't invent it; the Manager registers it and mints the matching PSK. Its PSK, delivered out-of-band (a creds file the Manager writes, or an env var it sets). The PSK never ships inside your app binary. The broker address (loopback host + port the Manager is listening on). With those, every app is four lines: connect, invoke a granted capability, handle a denied one, done.var mgr = await EclipseSecureClient.ConnectAsync(brokerAddr, appId, appPsk, identity: appId); string uid = await mgr.InvokeAsync("AddEvent", new() { ["day"] = today, ["summary"] = "Ship it" }); string day = await mgr.InvokeAsync("GetEvents", new() { ["day"] = today }); // anything you weren't granted throws before it reaches a worker Everything below is just where those four lines live.The console is the reference shell - the smallest thing that proves the contract. This is exactly what XRUIOS.SampleApp (the Höllvania calendar) is.Project: a plain Microsoft.NET.Sdk exe on net10.0, referencing XRUIOS.SecureLayer (for EclipseSecureClient) and, if you want the UI, Spectre.Console.using System.Text; using Spectre.Console; using XRUIOS.SecureLayer; Console.OutputEncoding = Encoding.UTF8; // the wordmark stays white; everything else is yours AnsiConsole.Write(new FigletText("XRUIOS").Color(Color.White).Centered()); AnsiConsole.Write(new Rule("[green]HÖLLVANIA MUNICIPAL CALENDAR[/] [grey]· ON-LYNE BBS · est. 1999[/]").Centered()); // creds the Manager wrote for this app: broker addr + id + PSK var (brokerAddr, appId, appPsk) = AppCreds.LoadFor("sampleapp"); string today = DateTime.Now.ToString("yyyy-MM-dd"); await AnsiConsole.Status().Spinner(Spinner.Known.Dots).StartAsync("Handshaking…", async _ => { var mgr = await EclipseSecureClient.ConnectAsync(brokerAddr, appId, appPsk, identity: appId); // GRANTED string uid = await mgr.InvokeAsync("AddEvent", new() { ["day"] = today, ["summary"] = "Ship XRUIOS" }); AnsiConsole.MarkupLine($"[green]added[/] event [aqua]{uid}[/]"); string events = await mgr.InvokeAsync("GetEvents", new() { ["day"] = today }); AnsiConsole.Write(new Panel(events).Header($"[white]{today}[/]").BorderColor(Color.Green)); // NOT GRANTED - the broker refuses before it reaches the worker try { await mgr.InvokeAsync("DeleteEvent", new() { ["uid"] = uid }); } catch (Exception ex) { AnsiConsole.Write(new Panel($"[red]{ex.Message}[/]").Header("[red]ACCESS DENIED BY THE OPERATOR[/]")); } }); Run it: start an unlocked Manager, then run the exe. It prints the new event id, the day's events, and a red denied panel for delete. That denied panel isn't error handling for show - it's the permission model firing. The app was granted GetEvents + AddEvent, not DeleteEvent, so the broker never let the delete reach the Calendar worker. See 7 - Proven at Runtime for the actual run.When to reach for this shell: services, cron-style jobs, install/setup tooling, anything headless. It's also the fastest way to smoke-test a new capability before you put a face on it.A desktop app is the CMD app with a window bolted on. The client is UI-framework-agnostic, so the rule is: the broker connection lives in a small service, the UI binds to it, and no XAML/AXAML ever calls a worker. This holds for WPF, Avalonia, or OpenSilver - only the view layer differs.The service (identical across frameworks - this is the whole app, really):public sealed class CalendarService { private EclipseSecureClient? _mgr; public async Task ConnectAsync() { var (addr, id, psk) = AppCreds.LoadFor("calendar-desktop"); _mgr = await EclipseSecureClient.ConnectAsync(addr, id, psk, identity: id); } public Task GetDayAsync(string day) => _mgr!.InvokeAsync("GetEvents", new() { ["day"] = day }); public Task AddAsync(string day, string summary) => _mgr!.InvokeAsync("AddEvent", new() { ["day"] = day, ["summary"] = summary }); } The view model binds to it and keeps the UI thread clean - await marshals back for you, so the only rule is don't block on the connection:public sealed class DayViewModel : ObservableObject { private readonly CalendarService _cal; public ObservableCollection Events { get; } = new(); public async Task LoadAsync(string day) { string raw = await _cal.GetDayAsync(day); // off the UI thread Events.Clear(); foreach (var line in raw.Split('\n')) Events.Add(line); // back on it } } The window (WPF shown; Avalonia is the same shape with axaml) is just a list bound to Events and a button that calls AddAsync then LoadAsync. The XAML never sees the broker, never holds the PSK, never names a worker - it only knows the view model.Three things a desktop app must respect that a console app can ignore: Connect once, off the constructor. Do the handshake in an async OnStartup/OnFrameworkInitializationCompleted, show a "connecting" state, and only enable the UI when it's up. A failed handshake is a normal state (Manager locked or not running), not a crash - show "XRUIOS is locked, log in first." A denied capability is a UI affordance, not an exception you swallow. If the app wasn't granted DeleteEvent, don't show a delete button. The broker will refuse it regardless - the wall doesn't depend on your UI - but a good app doesn't offer what it can't do. Catch the denial and disable, don't crash. The PSK still comes from the Manager, not your app settings. A desktop app is more tempting to ship with a baked-in secret. Don't - load it from the creds the Manager wrote, exactly like the console app. If someone copies your .exe, they get no id and no PSK, so they get nothing. That's the entire difference. A desktop XRUIOS app is a normal MVVM app whose "backend" is the four-line broker client, wrapped so the connection is async and the denials are visible.
A mod is an app that runs inside a host (a HangarBay/Aether game or scene) instead of as its own process, so it can't even open a socket to the broker - CasCore made System.Net uncallable. Instead the host holds the broker connection and the mod asks the host. The permission story is identical - one XRUIOS.Permissions authority, capabilities by name - but the plumbing is the mod registry, not EclipseSecureClient. Full detail in 6 - Aether Engine Integration; here's the build.On the host side (the game integrating XRUIOS - written once, not by the mod author):// one registry over the host's real XRUIOS.Permissions handler + context var mods = new ModRegistry(handler, appContext, privateRoot, memoTtl: TimeSpan.FromSeconds(5)); // enroll the mod by its Notary-verified package id -> host-assigned ModId var widget = mods.Enroll("com.hollvania.calendarwidget"); // grant it exactly what it may do - persisted in XRUIOS.Permissions under its ModId await mods.GrantAsync(widget, "Time.Calendar:GetEvents"); // note: no AddEvent, no DeleteEvent granted // give it a jailed filesystem: its own private dir, plus any named roots it's granted var fs = mods.CreateFileSystem(widget, grantableRoots); On the mod side, the author writes against a host-provided interface - never against System.IO, System.Net, or the broker. The mod calls a host service; the host runs IsAllowed and either serves the result or refuses:// inside the mod - the host injected this; the mod has no other way to reach data public void OnTick(IXruiosHostServices host) { // the host checks mods.IsAllowed(thisMod, "Time.Calendar:GetEvents") internally string today = host.Calendar.GetEvents(DateTime.Now); // ALLOWED -> returns events Draw(today); // this is not granted; the host refuses it. the mod cannot bypass - it holds no key, // no socket, no file handle. all it can do is ask. // host.Calendar.DeleteEvent(uid); // would throw: not allowed }
The mod author's mental model is the same four-line contract, minus the connection: ask for a capability, get a result or a refusal. What changes is that identity is host-assigned (ModId from the Notary package id - a mod can't claim to be another), grants are persisted per-ModId, sensors and files are themselves capabilities, and an unsigned mod (EnrollEphemeral) can't bank trust across sessions. The runtime proof is in 6 - Aether Engine Integration: com.hollvania.calendarwidget ALLOW GetEvents / DENY DeleteEvent; com.evil.dataslurp DENY both.A worker owns its store, and it sets that store up itself on first launch - the Manager doesn't reach into a worker's data. Each system's Initiate… routine (the ones from Barebones - InitiateCalendar, InitiatMusic, and so on) moves into its own worker and runs at worker startup, so by the time the broker routes your first AddEvent the Calendar worker has already created its Calendar directory. That's why the Calendar worker's Program.cs creates its data folder before it serves: an app should never have to initialize a worker it can't even see. When you stand up a new worker, put its init on the worker's boot path, not in any app.
Your app's surface is the set of capability names it was granted. Names read Group.Worker:Capability (Time.Calendar:GetEvents) so a grant is unambiguous about which worker it reaches - see the full list in 5 - Permission Catalog. Design your app around the names you'll request, then have the Manager grant exactly those. Anything else is denied by construction.Every surface has the same three failure modes, and a good app names them:The denial and the handshake failure are the security model doing its job. Treat them as expected states, not exceptions to bury.Console, desktop, or mod - your app is not trusted with a secret it can leak. The console/desktop app loads its PSK from the creds the Manager wrote; the mod never has one at all (the host connects). Copy any app binary to another machine and it authenticates as nobody, because the id and PSK were provisioned by that machine's Manager. This is what makes "just send me the exe" safe.
Related: 1 - The Model · 3 - Capabilities and Sharing · 6 - Aether Engine Integration · 7 - Proven at Runtime

6 - Aether Engine Integration

Fri, 21 Aug 2026 00:11:44 GMT

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.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.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.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. 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. 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:). "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.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.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.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); 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.
Related: 1 - The Model · 5 - Permission Catalog · 7 - Proven at Runtime

5 - Permission Catalog

Thu, 20 Aug 2026 23:40:36 GMT

Every capability an app can be granted, by group and worker. Grants are named Group.Worker:Capability. Calendar is live today (real capabilities); the rest currently expose a placeholder Ping and list their intended curated surface, drawn from each class's public methods.Proven at runtime. Login → 27 workers launched in parallel → post-quantum handshake → a granted call ran in the Calendar worker, an ungranted one was refused by XRUIOS.Permission. The catalog below is what fills out from there.Grants are two lines in the Manager - register the app (mints its own password), then grant each capability:var app = apps.Register("weather"); await permissions.GrantAsync(app.AppId, "Time.Calendar:GetEvents"); Anything not granted is denied at the broker before it reaches a worker. See 3 - Capabilities and Sharing for the worked example.

3 - Capabilities and Sharing

Thu, 20 Aug 2026 23:40:36 GMT

A capability is one named thing an app may ask a worker to do. Apps are granted capabilities, not workers - {app → {capability: level}}, stored encrypted and checked on every call. A capability that was never granted is denied before the request leaves the broker.Capabilities read as Group.Worker:Name, so a grant is unambiguous about which worker it reaches:Time.Calendar:GetEvents Time.Calendar:AddEvent Time.Calendar:DeleteEvent Spatial.WorldEvents:AddWorldEvent Interface.Notification:AddNotification Each worker chooses a curated surface - the cross-program calls, not every method. Right now the Calendar worker carries the real one:The other ~26 workers currently expose a placeholder Ping capability. Their curated surfaces (e.g. Spatial.WorldEvents:AddWorldEvent, Interface.Notification:AddNotification) are the fill-in work; the pattern is identical to Calendar's."Event stuff shared with different programs" means this: the Calendar worker owns the calendar. Any program the Manager grants Time.Calendar:* reads and writes the same calendar through it. Two apps, one shared store, each held to its own grant.The demo is the Höllvania Municipal Calendar - a Warframe-1999-flavoured XRUIOS.SampleApp, built with Spectre.Console (the XRUIOS wordmark stays white; the Höllvania chrome is green). It's granted GetEvents + AddEvent but not DeleteEvent, so it shows both sides - a call that works and a call that's refused. This ran for real against the live Manager: the post-quantum handshake completed, AddEvent created an event in the Calendar worker, and DeleteEvent came back denied (see 7 - Proven at Runtime).// connect to the Manager broker with this app's own credentials var mgr = await EclipseSecureClient.ConnectAsync(brokerAddr, "sample-app", appPsk, identity: appId); // granted: write an event, then read the day back (another granted app would see this event too) string uid = await mgr.InvokeAsync("AddEvent", new() { ["day"] = today, ["summary"] = "Ship XRUIOS" }); string events = await mgr.InvokeAsync("GetEvents", new() { ["day"] = today }); // NOT granted: the broker refuses before it reaches the worker try { await mgr.InvokeAsync("DeleteEvent", new() { ["uid"] = uid }); } catch { /* ACCESS DENIED BY THE OPERATOR */ } On the Manager side, the grant is two lines:var app = apps.Register("sampleapp"); // its own app password await permissions.GrantAsync(app.AppId, "GetEvents"); await permissions.GrantAsync(app.AppId, "AddEvent"); // DeleteEvent is deliberately withheld -> the broker denies it Run XRUIOS.SampleApp against a running, unlocked Manager and it prints the AddEvent id, the day's events, and an ACCESS DENIED panel for the delete. Grant a second app the same two capabilities and it sees the first app's event - shared, but each still walled to what it was given.
Next: getting it running - 4 - Installing.

Kennaness

Thu, 20 Aug 2026 16:46:12 GMT

WalkerDev

Thu, 20 Aug 2026 16:46:12 GMT