One App Shell, unified dashboard and onboarding architecture

TL;DR: The One App Shell brings setup, connections, consent, and agent sessions into one web and mobile experience. It can show a person's private agent being provisioned on a selected pod path. Custody and readiness claims depend on the selected deployment and verified runtime, rather than the presence of a pod alone.

Relations

One
PCHP
Connected Systems
BYOA
Three-layer architecture
Personal Operating Layer
🤫 Agent One First-Time User Guide — first-time guide

Overview

The One App Shell represents a major consolidation of Hussh's user-facing surfaces. Previously, individual agents (such as Kai) and platform capabilities (such as location sharing and connected systems) operated in separate or disjointed interfaces. The App Shell brings these together under a single unified cockpit, providing a cohesive experience across desktop and mobile form factors.

Designed to align with modern responsive standards, the App Shell integrates the core ideas of PCHP (the consent protocol) directly into a person's daily flow, turning privacy and consent management from a secondary setting into a primary, accessible dashboard feature.

All account-level onboarding terminology and routes have been unified into the Setup space, routing people through a clean, single-pass setup hub.

The September 17 source snapshot described top-level tabs, an ambient mask, news and map surfaces, an Activity Feed pane, and a breadcrumb trail. Agent Chat streaming and connected-systems compatibility should be evaluated against the deployed app before being presented as a release guarantee.

Hussh is the control plane, not the custodian

The private agent architecture separates the person’s information authority from the services that route requests and provision compute. A pod can run in a person’s own cloud project or on a Hussh-hosted path that meets specific key and identity conditions. The development pod is a simulation environment; other deployment targets have their own implementation status.

The App Shell should show which path was selected, whether provisioning and identity checks succeeded, and where the person can inspect or revoke authority. A recorded owner-cloud pod deployment establishes that path for one pod; it does not show that every connection, answer, recovery record, or provider interaction runs there. Shared service paths and provider processing have separate information boundaries.

A control plane that cannot read personal information is an architectural goal with deployment-specific proof. It must not be inferred from a public key registration, sealed transport, or a successful development turn. The screen should report what the selected path has actually verified.

Core Architectural Components

The App Shell is built upon six primary experience pillars.

1. The Unified Dashboard

The Dashboard serves as the primary cockpit. It aggregates active consent streams, summarizes registered Connected Systems, and hosts the interactive Consent Audit Timeline. People can instantly see which third parties have requested access, when they reached it, and the specific reasons authorized under PCHP.

2. Activity Feed

Rebuilt as a visual, media-rich activity pane, the Feed space delivers a polished, streamable timeline of agent actions, system notifications, connected-system events, and PCHP consent receipts, with smooth motion transitions and responsive card layouts.

A responsive app shell provides continuous layout parity between the native mobile apps (iOS and Android) and web browsers. Key layouts feature a flexible bottom-navigation bar tailored for thumb reach on mobile screens, morphing into a standard desktop layout on wider screens.

4. Integrated Setup Hub

The setup pipeline is consolidated into a lean, single-pass setup wizard and hub. People configure profile parameters, satisfy phone-verification requirements, initialize their consent vault, and provision system capabilities through visual interactive cards. Capabilities are scoped to dedicated setup steps (for example Gmail, location, and finance) that isolate each workflow state and smooth navigation with unified route transition animations.

AI access lets a person choose a supported model credential and starts a separate readiness flow for the selected compute path. The app must report credential verification, pod provisioning, identity checks, and an actual agent turn separately. A development provisioning flow is evidence for that lane; other deployment paths require their own acceptance checks.

5. Cross-Agent Connection Bridges

Specialized connection bridges link individual agent contexts. For instance, the Kai Circle Connect bridge lets specialized financial analysis in Kai trigger a generalized system connection, carrying the consent boundary across in a single, person-guided click.

6. Generalized Agent Bar

The legacy inline specialized agent triggers are replaced by a generalized conversation input and control surface. It features a dedicated conversational mode, allowing fluid multi-turn context transitions, while search controls are flattened to eliminate visual chrome duplication.

Where your private agent comes from

Setup asks how the person wants to use AI access. When a selected model credential and deployment target are supported, provisioning can create or reuse a dedicated pod and verify its identity before the app reports it ready. The compute target may be a person’s cloud project or a qualified hosted path; the development lane validates behavior but does not establish production custody.

The setup flow should keep credential validation, pod creation, scoped access, and the first successful agent turn as separate checkpoints. A working model connection alone does not prove that an agent has answered from the intended pod or that its information, recovery state, and connector credentials obey that path’s custody contract.

Dated status: A development pod flow was documented on 2026-09-17. The first owner-cloud pod was separately reported from its owner registry. Those observations are limited to their measured environments. Current installed images, full specialist execution, recovery, and migration require their own evidence.

Watching your agent come online

The App Shell can present provisioning states as they are observed: requested, created, starting, identity verified, authorized, and ready to answer. It should distinguish a sleeping pod from a missing one before offering recovery, and report when a step has not completed.

Rebuilding compute is not the same as restoring information. A recovery claim requires proof that encrypted state was retained, rehydrated under the right owner, and that the selected runtime still enforces its key and consent boundaries. The interface should display verified progress without implying that every deployment has completed that path.

Default accent and theme options

To align precisely with Apple's guidelines, the app accent focuses on clarity and simplicity.

Apple Blue default: All primary buttons, links, focus states, selected bottom tabs, and active card outlines are styled in Apple System Blue (#007aff), replacing the former default gold accent.
Molten Gold option: The original warm-gold accent (a deep gold in light mode, a brighter gold in dark mode) is preserved as a switchable theme choice ("Molten Gold") accessible from profile settings.
Theme-aware wordmark: The shell uses a responsive, dark and light aware brand mark alongside the "hushh One" visual layout.

Responsive and mobile optimization

To guarantee visual parity across varied viewports, the App Shell incorporates several engineering solutions.

Standardized page metrics and clean headers: Application shells rely on standardized page metrics that collapse stacked typography on mobile route wrappers to prevent double headers.
Immersive location map and native workspace navigation: An immersive location map presence view and native workspace navigation give continuous mobile-to-desktop parity in the web application.
Expressive motion physics: Dialog and sheet motion use underdamped spring easings and focal scale swells, with a physics-based segmented control tracking routes across the Kai workspace dashboard tabs.
Touch-friendly tables: Wide tables are wrapped in scrollable containers with momentum scrolling, preventing layout overflow on narrow screens.
Dynamic padding: Spacing adjusts dynamically for mobile safe areas (such as the iOS home indicator) to ensure no overlap with critical interactive elements.
Pinch-zoom viewers: Embedded diagrams (such as architecture maps or data flows) support native pinch-to-zoom and drag-pan interactions without trapping the page scroll.

Onboarding and "Warm Cream" Revamp

The onboarding setup process has been significantly hardened and redesigned for a high-trust, smooth first-run experience.

Updated 2026-09-17: repo commits 2026-09-17 include fix(onboarding): polish auth and intro step layout and centered privacy notice (111854b53) and related AuthStep/IntroStep changes, plus 0-to-1 iconography and motion audit documentation (docs(ui): add 0-to-1 iconography and motion audit and update skills). The Setup hub continues to consolidate account-level onboarding routes under the unified Setup space.

"Warm Cream" styling: Onboarding screens (the intro step, setup completion, and account authentication) feature a refined, calm "warm cream" background palette matching the Summer 2026 design standards.
Robust journey guards: The onboarding journey guard drops the legacy URL query parameter dependency. This prevents URL clutter and state synchronization race conditions, ensuring robust redirection transitions.
Unified account deletion: The account closure flow coordinates local and service cleanup. Complete provider and retained-copy erasure requires separate acceptance evidence.
Voice action integration: Conversational voice setup prompts are tightly coupled to the setup steps, letting the root One agent direct a person verbally while the interface updates its transition states dynamically.

Hosting choices and Puppy

Accounts with no pod assignment and no setup pending resolve to Hussh Shared by default after the server confirms both states. Existing assignments and setup in progress are preserved. BYOC places the pod in the owner's Google Cloud project; new Hussh Pods assignments remain gated. Shared has no dedicated personal pod. Model-provider credentials are separate and do not create a pod for Shared.

Puppy requires a BYOC pod and its private device relay because both devices must connect directly through that relay. Backend authorization is gated to a registry-confirmed BYOC deployment and binds inference to the owner, device, and pod. Shared and Hussh Pods are refused, and the app has no hub-relay fallback. The Hermes client still lacks verified binding discovery and direct pod connection, so end-to-end device use is not established.

Software updates

The source candidate reviewed on September 24, 2026 adds a Software updates view with installed and available version labels, reviewed release notes, and an explicit unverified state when release evidence is missing. Release metadata binds the notes to an immutable image, source revision, deployment environment, and publishing workflow run.

An update requires owner approval and explicit compatibility with the installed image. The candidate release currently declares no supported predecessor images, so it does not establish an available upgrade for existing pods. Release publication, deployment, and live update continuity remain unverified.

Sources

Hussh Research Repository