Skip to content
Hussh
Connect MCP

One App Shell, unified dashboard and onboarding architecture

The One App Shell is the unified experience container for the personal operating layer, consolidating setup, connected systems, and agent sessions into one responsive web and mobile interface, and the surface where choosing AI access provisions a person's own private agent in their own pod.

Product6 days ago

TL;DR: The One App Shell is the unified experience container for the personal operating layer. It consolidates setup, connected systems, and agent sessions into one responsive web and mobile interface, and it is the surface where you watch your own private agent, One, come online in your own pod, with Hussh acting only as the control plane that never holds your holdings.

Relations

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.

In the latest release, the top shell has been upgraded with top-level tabs, an ambient mask, news and map surfaces, an Activity Feed pane, and a breadcrumb trail. Agent Chat now streams One's thinking process and its sources live, while workspace chrome and consent routing maintain full compatibility with the connected-systems layer.

Hussh is the control plane, not the custodian

The App Shell makes one idea concrete on the screen: Hussh is the control plane, not the keeper of your holdings. Your private agent, One, does not run inside a Hussh data center that owns your information. It runs in your own pod, a small container in your own cloud (bring your own cloud), with keys on your own device (bring your own keys).

Hussh operates that pod on your behalf but holds none of your information. It keeps only public metadata (an identifier and the pod's public key), relays sealed ciphertext between parties, and authorizes consent. There is no Hussh vault of your records and no Hussh backup of record.

Plaintext exists only inside your pod and on your device. Everything Hussh and the network see is encrypted. The durable backup is your own, in your own cloud, unlockable only with material that never leaves your device.

Consent is explicit and scoped through PCHP: each exchange rides a single-use, signed, revocable grant. This is what "Own your AI. Own your data. Own your compute." means in practice. Hussh is the enabler for exchange, not the holder of what is exchanged. The App Shell is where you see that boundary, watch grants get issued and revoked, and confirm that the plaintext side of the line is always yours.

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.

3. High-Fidelity Responsive Navigation

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.

One step in the hub is no longer a preference. AI access, where a person chooses whether their agent thinks on Hussh-managed access or on their own key, is the compute gate: it is the only event that causes that person's own private agent to be built in their own pod. Both branches of the choice are proved on the server with a real generation before anything is created, so an unverified or absent connection produces no agent and no cost. Setup itself never waits on it; the rest of the journey continues while the agent is prepared in the background.

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.

Onboarding and "Warm Cream" Revamp

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

  • "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: Account deletion is unified into a single client-settled transaction flow, ensuring no orphaned tokens or records remain in local storage or the consent databases on closure.
  • 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.

Where your private agent comes from

Setup is also where a person's own private agent comes into existence. The order matters more than any single step in it.

  1. You choose how your agent thinks: Hussh-managed access, or your own key.
  2. Hussh proves that choice actually works, on the server, with a real generation. This is the gate. No working connection, no agent.
  3. Only then is your own container built, one per person, reachable only through Hussh and never from the open internet, running under an identity that holds no permissions of its own.
  4. It starts up and says hello. Hussh collects its public key from the address it recorded when it created the container, rather than trusting an address the container offers, so a container cannot claim to be someone else's.
  5. It is granted a renewed, least-privilege permission to reach only what it needs, refreshed rather than issued once and left to expire.
  6. From then on, your agent's answers are computed there, on compute that is yours, using the model access you chose, and holding no key to any shared store. Everything it needs to know, it has to ask for.

The reason step 2 sits where it does is worth stating plainly: the agent used to be built the moment a phone number was verified. Signing in says nothing about whether an agent could answer a question, so that put real, always-on compute behind an event that carried no such promise. A successful answer is evidence; a sign-in is not.

Honest status: this runs in the development environment today and has not been promoted to the released app. The machinery is live there (an agent can be created and can run a turn), but no person's agent has yet answered a question this way. Until that happens, this describes a capability rather than a track record.

Watching your agent come online

Because the pod is yours and Hussh only operates it, the App Shell treats your agent's status as something to show you honestly rather than hide behind a spinner.

  • Live provisioning status. As your pod is built and starts up, the App Shell streams its status to you step by step: created, starting, greeting Hussh with its public key, granted its least-privilege permission, ready to answer. You watch it come online instead of waiting on an opaque loading state, and the same surface tells you plainly if a step has not completed yet.
  • Reachable, not resurrected. If your agent ever becomes unreachable, the App Shell offers to rebuild it. Before it does, it checks first whether the agent is simply asleep. A pod that has gone idle to save cost is not a broken pod, so a healthy agent is never torn down and rebuilt just because it was resting. Only when the agent is genuinely gone does the rebuild path open, and even then it re-runs the same ordered handshake, so a rebuilt agent is provisioned exactly as carefully as a first one.
  • The control-plane guarantee holds through recovery. A rebuild re-creates the container and re-collects its public key; it does not reach into your holdings, because Hussh never held them. Your durable records stay in your own cloud, unlockable only with material that never leaves your device, so bringing an agent back online is an operational act on the control plane, not a restore from any Hussh copy of your information.

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: Account deletion is unified into a single client-settled transaction flow, ensuring no orphaned tokens or records remain in local storage or the consent databases on closure.
  • 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.

Sources

  • Hussh Research Repository
  • Public control-plane framing per the One product brand: Hussh operates the pod, holds no plaintext, and authorizes consent through PCHP.