# The Surfaces

**Track 1 of 11 · the surfaces, their official homes, and what using them is like · v5.9**

> **Read this track through [Taxonomy v1.3.8](taxonomy.html).** A **Surface is a form factor** — **Desktop web** (the Field with Ki beside it), **Mobile**, the **Chrome Sidebar** (the browser extension), and **CTV** (the shared big screen, driven by the mobile devices in the room, several people at once). What a member does anywhere is one of the **eight Scenes** — **Atlas** (discover) · **Studio** (create) · **Commons** (organize) · **Workbench** (build) · **Forum** (govern) · **Exchange** (trade) · **Garden** (enjoy) · **Vault** (store, web-only). Every Scene reaches every Surface except Vault. **A basic version of all four Surfaces — CTV included — ships in the initial release (ruled 2026-08-01).** The official homes below remain the entry points, the modes remain **Chat and Live**, and everything this track says about what using each home is like still holds; the product descriptions below are read as renderings of the Scenes on the Surfaces. The full functional consequences are in the [Initial Release Functional Specification](initial-release-functional-spec.html).

Kiduna has **two modes — Chat and Live** — and reaches people through **six surfaces**, each with an official home: **Kiduna** (the mobile app and first KAP client — kiduna.app, the App Store, Google Play), **Kiduna Studio** (the build/create environment — desktop, and kiduna.studio on the web), **Kiduna Express** (the browser extension — kiduna.express, the Chrome Web Store), **Kiduna** (the account — kidunaverse.com), **Kiduna Live** (the Live mode alone — kiduna.live), and **Kiduna One** (Chat alone — kiduna.one). All Flutter/Flame wherever they render; all renderings of one system: the same graph, the same permissions, the same ally. **The design bible is here: [Kiduna Surfaces Design Bible v0.1](surfaces-bible/Kiduna_Surfaces_Design_Bible_v0.1.html)** — the visual and interaction canon for every surface (the Field grammar, the system, Studio, Live, Express, TV, and the design directions), also as a [downloadable bundle (zip: html · pdf · docx · md · assets)](downloads/Kiduna-Surfaces-Design-Bible-v0.1-bundle.zip). **The product foundation for the two working distances is the [Studio + Live Working Design Brief](studio-live-brief.html)**: Studio is the desktop working distance (structured density, inspection, governance, commitment; the Field left, Ki right, ~70/30); Live is the mobile human distance (presence, capture, coordination, bounded decisions; Ki as a bottom sheet) — and **Live can confirm most consequential Actions**: many Sources will never use Studio, so the list of Studio-only Actions must be very small, possibly empty. The actions available everywhere are inventoried in [Actions](actions.html); the machinery is [Orchestration](orchestration.html); outside tools and building on us is [Integrations](integrations.html); how we build — and how you can — is [Create from Within](create-from-within.html).

---

## 1. The one relationship

A member does not operate Kiduna; a member **talks to their ally** — the agent that represents them, named by them, working for them across every organization they belong to, on every surface. Everything the system can do is reachable by saying so, typed or spoken. There are no menus and no navigation in the traditional sense, because when agents do the work, an interface made of places-to-go answers a question nobody asked. The member's job is the relationship: teach the ally, correct it, read its account of what happened, and personally sign the few things only a human can sign.

## 2. Kiduna — the mobile app, the first KAP client · kiduna.app · App Store · Google Play

**The member's daily surface and the first client of the [Kinship Agency Protocol](protocol.html)**, built in Flutter/Flame for iOS and Android, with the identical app on the web at **kiduna.app**. Kiduna is for participating in organizations, and it is **always switchable between its two modes: Chat and Live.**

**Chat** is the text and realtime-voice conversation with your ally — the primary flow of the whole product. Voice and text are one conversation: the composer becomes a quiet voice band, in-flight words render peripherally, completed utterances land as ordinary messages, and you can interrupt or switch modes mid-thought. The ally always offers contextual actions — chips (one-tap sayables), buttons (a chip with its consequence stated), and cards (objects with a front stating consequence and a back showing the context used) — and everything a chip does, saying it does too. Fuller UIs (a treasury view, a Forum proposal, a grant panel) slide over the conversation, do their one job, and return you to the exact sentence you left. Awareness arrives rather than being fetched: return after any interval and the ally tells you what happened, most consequential first, every claim cited, compressed to fit the gap. **Sovereign acts are unmistakable**: votes, extending a code, blessing a spin-out arrive as cards and are signed by press-and-hold; **the gold ceremony — stamp, embers, haptic — marks signed acts and nothing else, forever**; what happens *to* you is announced by light.

**Live** is the isometric, graphic rendering of the same system — the second mode on the same system, not a separate world. You still only converse with your ally; in Live you are also **steering**: navigating the space, and *seeing* what Chat narrates — allies interacting with allies, allies interacting with **actors** (NPCs with purposes and routines), organizations as places, work as visible activity, with specific goals and contextual actions surfacing as you move. Design substrate: **tile specs for backgrounds, events, and sprites**, honed over time the way Kidunaversity's has been (what began as a city hall is now a university). Where finished art doesn't exist yet, **the models and the orchestration generate the space**: a bounded room, who is present, how far away they are — spatial rendering as a live capability, not a content backlog. The middle path is generative art tooling (ImageGen, Gemini) for tiles, sprites, particle effects, HUD and menus, scoring, and wallet-moving actions. **Moves** — the authored Live experiences: scenes, vibes, and games, built in [Studio](#5-kiduna-studio--the-buildcreate-environment--desktop--kidunastudio) — run inside Live; [Kidunaversity](organizations.html) is the first, and sim-flagged Moves obey the absolute boundary: **nothing inside a sim-flagged Move affects Kiduna.** You enter through portals your ally offers; entering is a plain tap; press-and-hold stays reserved for real signatures.

**Kiduna Live · kiduna.live** and **Kiduna One · kiduna.one** are the two modes offered whole: when you don't want Chat at all, kiduna.live is the Live environment on its own; when you just want to chat, kiduna.one is Chat as just chat. Same app, same graph, same ally — the surface simply opens in one mode and stays there, and the full app remains one switch away.

## 3. Kiduna Express — the browser · kiduna.express · Chrome Web Store

**The agentic internet made visible.** Express is the Chrome extension that navigates the web with you and for you: it uses the browser, reads what you read, and **filters everything through Kinship Codes** — is this site, page, email, or account **registered** ([Protocol §4](protocol.html))? What does the registration trace to — which member, which organization, which legal entity? Registered things light up with what they are; unregistered things stay what they've always been — *a stranger, not a threat.* On that foundation the web becomes safe, automated, and alive: your ally acts across it, agent to agent, under your authority.

**Registered social accounts** extend this to people-space: log in to a social account through [Studio](#5-kiduna-studio--the-building-surface--desktop) once, and the account is bound to your registry identity. Your ally can post for you — and, more importantly, other members' allies can interact with your accounts and use your public posts as context, so relationships build across Bluesky, the open web, and messaging channels, not just inside the app.

## 4. The account · kidunaverse.com

**Not an application — the account.** kidunaverse.com is where identity, credentials, wallets, and money live: onboarding and registration, your settings and permissions, buying and selling Compute, Institution accounts (including institutions paying for their enrolled members' Compute), links to every product, and where things get published. It is **the account every app and world needs — including third-party apps** built on the [Integrations](integrations.html) surface. Public metrics of the decentralized Kiduna (ecosystems · organizations · members · allies · alliances · Compute) live here too — and so do the **directories**: **kidunaverse.com/handle** is the page for a member or an ally (handles are unique across both, and "handle" is the word — never "username").

**The protocol browser.** Kiduna's most load-bearing page: the **audit trail, navigable**. Every relationship, transfer, account, and registration is an economic relationship on the protocol, and here you can walk them — drill from an organization to its proposals to a command receipt to the settlement; from a member to their registered artifacts; from your own history outward. What you can browse is exactly what you can access: your own everything (relationships, artifacts, summaries, archives), the materials of organizations and alliances you belong to, and whatever anyone made public — the four levels, enforced in the browser like everywhere else. From here you can also hand requests to Kiduna, Express, or Studio.

**Joining and money.** All payment execution stays on the web ([the invariant](protocol.html)). At the $100 step (Kinship Duna's initial Compute purchase), three options: **(1) Stripe headless onramp** (card → USDC, no crypto knowledge required), **(2) connect a Solana wallet** and transfer 100 USDC, **(3) send 100 USDC** to your new wallet's address (copy it, use any exchange). The designed flow — invitation through onboarding, all three paths, pending/complete, and the return to Chat — is the [Cohort Journey canvas](design-r5/Cohort%20Journey%20R5.dc.html).

## 5. Kiduna Studio — the build/create environment · desktop + kiduna.studio

**Studio is where you build and create — and above all, where relationships are designed.** It runs like an agentic desktop app — one conversation with your ally over a live workspace, in the manner of Claude Cowork or Codex — not a segmented, procedural tool: whatever you drop in gets organized into the graph, and a range of actions surfaces in the chat. It ships for mac, Windows, and Linux/Chromebook, and the same Flutter/Flame build runs on the web at **kiduna.studio**. It is not a vibe-coding platform and not for coding at all; it is for **creating and maintaining your ally, inviting people, developing Moves, and building organizations**: adding context and knowledge, creating alliances, fleshing out system prompts, connecting accounts, composing skills and automations.

**The Studio↔coding-agent protocol.** For work that *is* code, Studio doesn't pretend — it passes **packages** back and forth with **Claude Code and Codex** on the local machine, over a defined protocol modeled on the dispatch pattern we run ourselves: Studio hands out a self-describing package (context, ask, constraints), the coding agent works it in its own environment, and the result comes back as a package Studio unpacks into the graph, recorded like any other work ([Integrations §1](integrations.html)).

**Designing relationships is the point.** Between two people the first-class object is a **relationship** (canon — never "connection"): both sides inform it — what each shares and exposes, what each learns and maintains about the other — and Studio is where you shape that texture deliberately. The same holds one level up: guilds, alliances, and organizations are containers whose context you design here. You are always talking to your ally, but the experience inside each container is distinct — different grounding, different shared wisdom, different rules — stored distinctly, all related on the graph ([Foundation](foundation.html)).

**Deep collaboration, not light sharing.** Studio is built for working *with* people: sharing skills and modifying them together, connecting knowledge bases, co-writing system prompts and automations — one person doing sound while another does art while a third wires the Forum conventions. **The most important thing about Studio is communications between allies**: over social media (Bluesky), over messaging (Telegram), and through direct **back-channel ally-to-ally conversations** — with the relationship, guild, alliance, or organization providing the context every exchange runs in.

**The tool room.** Studio is where outside capability gets attached: MCP servers connected and scoped to specific relationships, alliances, or organizations; local agents — Claude Cowork/Code and OpenAI Codex on your own machine — that Studio hands work to and receives results from; social accounts logged in and registered. The full integration surface, inward and outward, is [Integrations](integrations.html).

## 6. What never varies

Across all four products: citations and consequence-ordering; the meaning of **gold** (signature) and **sky** (touchable); the anatomy of a card; the four access levels; your Contract — no organization can buy louder access to you; the ally's voice, constant everywhere. Moving between organizations is a **drift** — ground temperature, Compute in play, register — never a navigation event. Each duna configures its own register; the system never changes underneath ([Organizations §3](organizations.html)).

## 7. Roles shape the experience

What you can do on any surface is gated by your [role](roles.html) in the organization you're acting in — Guests are guided by the shared Host ally; Members have the full baseline; Organizers, Creators, Builders, and Catalysts unlock their verbs ([Actions](actions.html) marks every gate). Promotion is announced by light, then quiet. Never a leaderboard.

## 8. The complete UI design

The full visual design record — start with the UX spec, then the canvases:

- **Design Round 7 — Kiduna Studio, whole** *(current round)*: **[UX Specification R7](design-r7/UX-SPEC-R7.md)** · [01 The Project](design-r7/01%20The%20Project%20R7.dc.html) (the primitive: creation with its receipt, the anatomy card, its own Scene) · [02 Field and Chat](design-r7/02%20Field%20and%20Chat%20R7.dc.html) *(drawn against the morning canon — read its chat panes as the contextual HUD's opaque state per the evening rule: the Field is the only interface)* · [03 Collaboration](design-r7/03%20Collaboration%20R7.dc.html) (presence, server-mediated handoffs, the trust matrix) · [04 The Coding-Agent Seam](design-r7/04%20The%20Coding-Agent%20Seam%20R7.dc.html) (package out, in-flight, return, acceptance) · [05 Ally and Scenes](design-r7/05%20Ally%20and%20Scenes%20R7.dc.html) · [06 The Cut](design-r7/06%20The%20Cut%20R7.dc.html) (the Lightbrush Project end to end) · [07 Studio on the Phone](design-r7/07%20Studio%20on%20the%20Phone%20R7.dc.html) (the pulse, not the workshop) · [motion](design-r7/MOTION-ADDENDUM-R7.md) · **[six open questions awaiting decision](design-r7/OPEN-QUESTIONS-R7.md)**.
- **Design Round 6 — Creating from Within** *(canvas 05 remains normative for the August 10 member journey)*: **[UX Specification R6](design-r6/UX-SPEC-R6.md)** · [01 The First Invitation](design-r6/01%20First%20Invitation%20R6.dc.html) (Ki's first session and ally creation as conversation · the Profiler intake and profile card · the one-signature invitation · swyx entering fluent · the first Chat ⇄ Live switch · Studio at three jobs + the package handoff) · [02 Live](design-r6/02%20Live%20R6.dc.html) (the HUD and sky-rim law, proximity actions, sim-flagged Moves without meters, the closed tile/sprite/event vocabulary, the generative fallback) · [03 One & Live as products](design-r6/03%20One%20and%20Live%20Products%20R6.dc.html) · [04 the /handle directory](design-r6/04%20Kidunaverse%20Directory%20R6.dc.html) · [05 the Create-from-Within Cut](design-r6/05%20Create-from-Within%20Cut%20R6.dc.html) · [motion](design-r6/MOTION-ADDENDUM-R6.md) · **[ten open questions awaiting decision](design-r6/OPEN-QUESTIONS-R6.md)**. Where R5's fuller designs and R6's cut differ, **the cut is the August 10 build; R5 is the horizon.**
- **[The Cohort Journey — R5](design-r5/Cohort%20Journey%20R5.dc.html)** — the onboarding baseline, adopted by R6: Crystal Stone's whole arc (the invitation before she has an account · onboarding at kidunaverse.com, one act per page · the $100 step with all three paths, pending/complete, and the return · first Chat, with the relationship designed conversationally and the two-sided relationship card) plus one-panel vignettes of the rest of the launch cohort.
- **[UX Specification](design-r4/UX-SPEC-R4.md)** — the composed model through R4: Chat anatomy, the four voice states, the card→fuller-UI→return loop, treasury/Forum/grants/record, Kidunaversity entry and exit, the money handoff.
- **Screen canvases** (mobile 390×844 unless noted):
  [Core screens — Chat, voice, treasury, Forum, grants, record, portals, money handoff](design-r3/Key%20Screens%20R3.dc.html) ·
  [Voice + crossing, final form](design-r4/Redraws%20R4.dc.html) ·
  [The web money surface (desktop + mobile web)](design-r4/Web%20Money%20Surface%20R4.dc.html) ·
  [Kidunaversity](design-r4/Kidunaversity%20R4.dc.html) ·
  [Levels, guilds, institutions, domain registration](design-r4/Levels%20%26%20Social%20Objects%20R4.dc.html) — *predates the "registered / unregistered" vocabulary; read "accountable" as "registered"*
- **Motion:** [base motion system](design-r2/MOTION-SPEC.md) · [Chat/voice/portal additions](design-r3/MOTION-ADDENDUM.md) · [crossing, promotion, command receipts, web press-and-hold](design-r4/MOTION-ADDENDUM-R4.md)
- **Realm expression:** [what an organization may and may never style](design-r2/REALM-EXPRESSION.md) · **Making:** [the making surface](design-r2/MAKING-SURFACE.md)
- **Design system** (binding for all visual work): [colors & type](_ds/kidunaverse-2de4dee0-9628-4871-a4e3-fc4ddc902d31/colors_and_type.css) — espresso ground, Avenir body, Goudy Heavyface display, IBM Plex Sans callouts, sky = touchable, gold = signature.
- Round 6 delivered the Creating-from-Within surfaces (above). Deferred by its cut, awaiting later rounds: the full Studio redesign, the protocol browser, Express's surfaces, and Live voice.

---

*Changes in v5.9: read through Taxonomy v1.3.8 — Surfaces are form factors (Desktop web · Mobile · Chrome Sidebar · CTV); the eight Scenes installed (Atlas · Studio · Commons · Workbench · Forum · Exchange · Garden · Vault); Vault is web-only; CTV enters the canon as the shared-screen surface driven by the mobile devices in the room. v5.8: the Studio + Live Working Design Brief v0.1 installed as the product foundation for the two working distances (Studio desktop · Live mobile); Live confirms most consequential Actions. v5.7: the Surfaces Design Bible v0.1 posted (page + downloadable bundle). v5.2: six surfaces — Kiduna Live (kiduna.live) and Kiduna One (kiduna.one) added; the modes are **Chat and Live** (Live supersedes "Move" as the mode name; **Moves** are the authored Live experiences — scenes, vibes, games); Studio gains kiduna.studio and the package-passing protocol with Claude Code/Codex; kidunaverse.com gains directories (/handle) and publishing. v5.1: Design R5's first delivery installed — the cohort journey (invitation → onboarding → the three-path $100 step → first Chat and the relationship card). v5.0: track renamed from "The Experience" and rebuilt around the four products; the app's areas are **Chat and Move** (Move supersedes "Reality"; sim experiences are **Games**, Kidunaversity first); member↔member canon is **relationship**, never "connection"; the three-option USDC onboarding adopted. Full history: [versions](versions/index.html).*
