Track 1 of 11 · The Four Products

The Surfaces

Kiduna (the app: Chat and Move) · Kiduna Express (the browser) · Kidunaverse (the account and the protocol browser) · Kiduna Studio (the building surface, where relationships are designed). Four renderings of one system.

← The Kidunaverse — home Surfaces Orchestration Foundation Protocol Organizations Actions Roles Sentinel Legal Institutions Integrations
You are always talking to your ally — on the phone, in the browser, at the account, in the Studio. The gold ceremony marks signed acts and nothing else, forever; what happens to you is announced by light.

1. The one relationship

A member does not operate the Kidunaverse; 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, 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 Kidunaverse, 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 — run inside Live; Kidunaversity is the first, and sim-flagged Moves obey the absolute boundary: nothing inside a sim-flagged Move affects the Kidunaverse. 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)? 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 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. Kidunaverse — 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 surface. Public metrics of the decentralized Kidunaverse (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. The Kidunaverse’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). 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.

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).

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).

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.

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).

7. Roles shape the experience

What you can do on any surface is gated by your role 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 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:


Changes in 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.