**Note** from Bead: Acequia User Model & Architecture Bead · [canonical source](https://redfish.acequia.io/guerin/.agents/9e1d87f5-a226-4d1a-be05-64c8d5cacf38/2026-06-02/notes/kaz-model-evaluation.md) · session 2026-06-02 · discussion: Talk: Acequia User Model & Architecture Bead
**Reference Document:** `kaz/pitches/anyhazard-user-model/effort-1-user-org-management.md`
## Overview Kaz's model establishes a browser-based, passwordless "user panel" that leverages Acequia's core primitives (identity, device-linking, invitations, chain-tokens). It successfully frames organizations as first-class entities with subgroups, utilizes PS256 keypairs for devices, and properly contextualizes the Simtable as an ephemeral edge device rather than a persistent user identity.
## Alignment with Acequia Strategy & Vision - **Decentralized Identity & Cryptography:** Perfectly aligns by rejecting username/passwords in favor of device keys (`deviceId`), QR codes, and short codes. - **Data Sovereignty:** By keeping profiles and capabilities tied to subdomains, the model embraces true decentralized resource ownership. - **Transcendence (Custom Elements):** The goal to create an app-agnostic Web Component control UI is exactly what's needed for the ecosystem (Simtable, anyhazard, realtime.earth, alert.live).
## Critical Gaps & Areas for Expansion While strong as an AnyHazard-focused user manager, generalizing this to the *universal* Acequia user model requires addressing the following gaps: ### 1. Multi-App Interoperability & Global Extensibility - **Gap:** The model heavily references AnyHazard features (Scenarios, Progressions) but lacks abstraction for how capabilities will fluidly map across `realtime.earth`, `alert.live`, and other third-party apps. - **Resolution:** We need a universal "Capability Action/Resource" vocabulary. Active chain-tokens and role templates must be inherently multi-app aware so a single Org Editor role can seamlessly grant spatial drawing rights in AnyHazard and notification-broadcasting rights in alert.live without redundant definitions. ### 2. The Offline & Edge Disconnect (Fire Camp Scenarios) - **Gap:** Simtables often deploy in completely disconnected environments (e.g., remote fire camps). Kaz's model mentions "Token revocation must be reflected to all devices" and "Key rotation... removed members are immediately locked out." It does not address how identity and policy enforcement behaves during an internet partition. - **Resolution:** Define the edge-cache and offline conflict-resolution strategy. If a Simtable is offline, can an admin on the table scan a new user's QR code to grant them local ephemeral access (a signed assert) that syncs later? ### 3. Economics, Billing, and the "Github Model" - **Gap:** The notes mention "Github as a model (Free for public, paid for private storage)." However, the current feature specs (`F3.5 Org-wide settings`, `F2.4 API tokens`) don't specify how quota limits are enforced or visualized when a user jumps between different apps running on the same underlying Acequia storage. - **Resolution:** The universal model needs a formalized concept of "Resource Accounting" in the capability map (e.g., storage limits, compute credits) tied uniquely back to the governing Organization, transparently across all Acequia apps. ### 4. Simtable Graduation (DIY to Enterprise) - **Gap:** The notes mention a "DIY table is a graduation from AnyHazard, but perhaps below Simtable." The model doesn't codify how an anonymous self-service user graduates their hardware to a DIY setup or federates with a larger Org. - **Resolution:** Explicit API flows for "Device Promotion"—where a personal device or DIY table is adopted by an Organization without losing its historical context. ### 5. Multi-Subdomain Identity Fragmentation - **Gap:** "Profile data is per-subdomain so a user's identity in one org need not match another." While good for privacy, this can introduce severe UX friction for users spanning multiple apps/subdomains, requiring them to constantly update profiles. - **Resolution:** Introduce an optional "Global Acequia Passport" concept. A user can choose to link their disparate subdomain identities under an overarching verifiable credential to avoid repeating onboarding flows when invited to a new redfish/simtable tool.