Architectural Note: Building an AT Proto-Native OS with Local-First Privacy - made-sick

Topic: PIXIE OS v5.0.1 Architecture, Spatial AppViews, and Data Hygiene

Status: Canonical Design & Implementation Contract

The PIXIE ecosystem is shifting from a standard web layout to a spatial, windowed operating environment. Operating at /os (and serving as the narrative front door at /), PIXIE OS blends a tactical HUD interface with decentralized identity.

To deliver an immersive experience without sacrificing privacy, accessibility, or decentralization, the system relies on two core architectural paradigms: Local-First Data Isolation and the AT Protocol Lexicon Specification.

1. Local-First Application Architecture

The interactive intake system governing PIXIE's dialogue flow operates on a zero-trust, local-first model.

On-Device Data Sovereignty: Highly sensitive user states—such as job loss context, counseling needs, disability, or capacity level—remain entirely on the client device. Session storage or local encrypted IndexedDB acts as the exclusive authoritative source.
Zero-Knowledge Distribution Boundary: Sensitive intake fields are strictly isolated from network payloads. They are never transmitted over API endpoints, saved to external databases, or uploaded to central servers.
Deterministic Local Compute: Instead of relying on client-side LLM calls that risk exposing API credentials or transmitting private text, the OS uses a deterministic client-side dialogue engine. Local responses dynamically alter interface density (e.g., explore, one small step, build, connect) entirely in browser memory.

2. AT Protocol Lexicon Standards & Data Hygiene

While private state stays local, public identity and interaction preferences connect seamlessly to the decentralized social web using custom AT Protocol Lexicons.

Separation of Protocol and Presentation: AT Protocol operates on DIDs, cryptographic signatures, and Personal Data Servers (PDS). It remains presentation-agnostic. Whether viewed as flat text or an ambient 2D desktop, the underlying protocol requirements remain identical.
Strict Schema Validation (com.loptrlab.pixie.publicProfile): Public updates are defined via a custom AT Protocol Lexicon schema. This schema accepts only broad interest arrays and computed capacity enums. Because the network layer strictly validates against this spec, unlisted sensitive intake fields cannot accidentally be serialized or written to the public PDS relay.
Explicit User-Triggered OAuth: Sensitive local state never automatically pushes to the network. Writing to a user's public profile requires an explicit, separate action authenticated via AT Protocol OAuth.

3. Universal Access & Machine-Readable Continuity

Immersive visual designs must never create accessibility barriers or break network interoperability.

The Accessible Escape Hatch (/pathway): The system provides an unencumbered, screen-reader-first route at /pathway. While "Talk to PIXIE" mounts this pathway inside a window on the OS desktop, direct navigation to /pathway delivers a docked, linear, non-draggable layout designed for screen readers, switch access, and high-zoom environments.
Canonical Manifest Contracts (/pixie/manifest.json): PIXIE's identity and status records remain anchored at /pixie. External ecosystem nodes, feed generators, and sister sites (such as Made Sick) consume /pixie/manifest.json as a machine-readable contract, allowing them to track her versioned state independently of the visual OS layout.

This architecture ensures PIXIE OS delivers a rich, narrative-driven environment while preserving absolute user data sovereignty, universal access, and native AT Protocol compatibility.