archy/.planning/phases/13-aiui-functional-conversational-node-control-and-content-surf/13-DISCUSSION-LOG.md

# Phase 13: AIUI — Conversational Node Control & Content Surfaces - Discussion Log

> **Audit trail only.** Do not use as input to planning, research, or execution agents.
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

**Date:** 2026-08-03
**Phase:** 13-aiui-functional-conversational-node-control-and-content-surf
**Areas discussed:** Where the tool-calling loop lives, How much authority the chat gets, Content scope and what "music" means, Two-repo split and delivery

---

## Where the tool-calling loop lives

| Option | Description | Selected |
|--------|-------------|----------|
| Node-side in Rust | Binary owns loop, tool registry and key; AIUI is a thin client | ✓ |
| Node proxies the model, AIUI runs the loop | Key stays server-side but tools execute through the ContextBroker | |
| Browser-side in AIUI | AIUI calls the model directly; key lives in the browser | |

**User's choice:** Node-side in Rust
**Notes:** Chosen with the tradeoff stated — this makes the RPC surface a contract AIUI and the later voice pipeline are written against.

| Option | Description | Selected |
|--------|-------------|----------|
| One assistant, many front doors | Extend the existing mesh assistant into a shared service | ✓ |
| Separate subsystem for AIUI | Leave the radio-shaped mesh assistant alone, build beside it | |
| Shared backend, separate authority | Share the key/plumbing, keep tool registries strictly separate | |

**User's choice:** One assistant, many front doors
**Notes:** Directly realizes the user's Phase 2 wording — "the same command surface as Pine".

| Option | Description | Selected |
|--------|-------------|----------|
| Split by nature: node does data+control, broker does UI | Node owns node-touching tools; broker keeps navigate/open-app/theme + consent | ✓ |
| Broker becomes consent-only | Strip back to permissions and theme | |
| Keep the broker as the single front door | Everything forwards through the broker | |

**User's choice:** Split by nature

| Option | Description | Selected |
|--------|-------------|----------|
| Local Ollama when present, Claude as fallback | Node data stays local when a local model exists | ✓ (amended) |
| Claude by default, Ollama opt-in | Best tool-calling reliability, context leaves the node | |
| User picks at setup, no default | Explicit choice, no implicit default | |

**User's choice:** Option 1, **amended by the user** — "but we also want to integrate this as part of it, please plan that too `https://github.com/routstr` so it would be local Ollama or Claude/Routstr as fallback"
**Notes:** Routstr was researched during the discussion rather than assumed: OpenAI-compatible endpoint, Cashu ecash per request, Nostr provider/model/price discovery. All three substrates already exist in-tree, which is why it is a smaller lift here than elsewhere.

| Option | Description | Selected |
|--------|-------------|----------|
| Prepaid budget, auto-spend within it | Hard ceiling a prompt-injected model cannot exceed | ✓ |
| Confirm every paid request | Maximum control, unusable with a multi-call tool loop | |
| Routstr only when explicitly selected | No automatic fallback to a paid path | |

**User's choice:** Prepaid budget the user sets

| Option | Description | Selected |
|--------|-------------|----------|
| Curated allowlist of hand-written tools | Every capability is a deliberate decision | ✓ |
| Auto-generate from the RPC dispatcher | Fast coverage, blast radius = whatever the allowlist forgets | |
| Tiered: curated for writes, generated for reads | Broad reads, hand-written mutations | |

**User's choice:** Curated allowlist of hand-written tools

| Option | Description | Selected |
|--------|-------------|----------|
| Local model gets tools, writes confirmed anyway | Confirm gate does the safety work | ✓ |
| Reads local, writes escalate to the strong model | Undercuts the privacy default at the sensitive moment | |
| Require a tool-capable local model | Honest but costs weak-hardware users the feature | |

**User's choice:** Local model gets tools; every write needs confirmation regardless
**Notes:** Consequence recorded in CONTEXT.md — backend choice becomes a privacy decision, not a safety one.

| Option | Description | Selected |
|--------|-------------|----------|
| Node-side, in the existing per-node data dir | Inherits backup, factory-reset, future LUKS | ✓ |
| Browser-only, never persisted server-side | Nothing accumulates on disk | |
| Ephemeral — no history at all | Strongest privacy, no memory | |

**User's choice:** Node-side in the per-node data dir

---

## How much authority the chat gets

| Option | Description | Selected |
|--------|-------------|----------|
| Reads + app lifecycle + settings writes | Keys, seeds, wallet spends, federation trust, factory reset excluded | ✓ |
| Read-only first | Prove the sandbox before granting power | |
| Full control including wallet and payments | An LLM adjacent to spending authority | |

**User's choice:** Reads within granted categories + app lifecycle + settings writes

| Option | Description | Selected |
|--------|-------------|----------|
| Authority never derives from content; untrusted text fenced and labelled | Injected instructions still face a human confirm | ✓ |
| Keep peer content out of the model entirely | Removes the injection path and much of the appeal | |
| Sanitize and strip suspicious patterns | Rejected as an arms race that reads as a guarantee | |

**User's choice:** Fenced and labelled; authority never derives from content

| Option | Description | Selected |
|--------|-------------|----------|
| In neode-ui's trusted chrome, outside the iframe | Iframe cannot spoof, restyle or pre-click it | ✓ |
| Inside AIUI, styled as part of the conversation | Better feel, drawn by the influenced context | |
| Node-issued confirmation token, UI-agnostic | Strongest and works for voice; more protocol to build | |

**User's choice:** neode-ui's trusted chrome, outside the iframe

| Option | Description | Selected |
|--------|-------------|----------|
| All closed; user opens what they want | Matches the sandbox promise literally | ✓ |
| Low-sensitivity open, sensitive closed | Immediately useful, harder claim to defend | |
| Open on first grant, per-category prompts in context | Just-in-time consent, more moving parts | |

**User's choice:** All 10 categories default closed

---

## Content scope — and what "music" means

Presented alongside verified research findings: AIUI's grids are fed by regex-parsing the model's own reply text against fixture catalogs injected into the system prompt; every "real" data path is Vite dev middleware absent from a static `dist/` deploy; `vite-fs.ts:7` hardcodes `/Users/dorian/Projects`; `ContentPanel.vue` is dead code taking `ArchyAppsGrid`, `FavoritesGrid`, `DiscoverPanel`, `RecipeDetail` and `AppDetail` with it.

| Option | Description | Selected |
|--------|-------------|----------|
| Feed the existing grids from Archy | Keep the design, replace the LLM-synth source | ✓ |
| New Archy-native surfaces alongside | Doubles surface area, splits the design language | |
| Revive ContentPanel and the Archy bridge path | Risks investing in an abandoned architecture | |

**User's choice:** Feed the existing grids from Archy

| Option | Description | Selected |
|--------|-------------|----------|
| Audio files from the two transports you already have | MIME-filtered files, no new entities; folds in the m4a/aac/opus mime bug | |
| Build a real library — albums, artists, metadata | A substantial backend domain | ✓ |
| Leave music to wavlake, wire only files and video | Music already works in prod against wavlake | |

**User's choice:** Build a real library
**Notes:** Chosen after being told explicitly that no library domain exists today and that it deserves its own phase. Concern raised once, user decided, proceeded — sequencing handled by the follow-up below.

| Option | Description | Selected |
|--------|-------------|----------|
| Its own plans inside Phase 13, not blocking the rest | Phase still delivers if the library runs long | ✓ |
| Library first — the rest follows | Cleanest data model, delays everything visible | |
| Split it into its own phase | Its own discussion round | |

**User's choice:** Its own non-blocking wave inside Phase 13

| Option | Description | Selected |
|--------|-------------|----------|
| Surface this node's + peers' existing content; no new payment rail | Uses the invoice/X-Payment-Token/Range flow that exists | ✓ |
| Include the cross-node content source with payments | The full Phase 2 vision; a federation distribution feature | |
| Movies out of scope this phase | Narrowest cut | |

**User's choice:** Surface existing content through the existing paid-unlock subsystem

---

## Two-repo split and delivery

| Option | Description | Selected |
|--------|-------------|----------|
| Built and shipped with the frontend, versioned and verified | Pin the commit, enforce the base path, fetch a live asset to verify | ✓ |
| Make AIUI a real catalog app | Architecturally right; changes a platform rule mid-phase | |
| Vendor AIUI's build output into this repo | One artifact, loses source separation | |

**User's choice:** Built and shipped with the frontend, versioned and verified

| Option | Description | Selected |
|--------|-------------|----------|
| Keep standalone; embedded mode delegates to the node | Dev loop stays fast, no node needed to work on the UI | ✓ |
| Embedded-only from here | Less surface, loses AIUI's independent life | |
| Standalone with the node as an optional backend | "Optional" risks the secure path being the forgotten one | |

**User's choice:** Keep standalone; embedded mode delegates

| Option | Description | Selected |
|--------|-------------|----------|
| Confirm push access before planning starts | Treats it as a prerequisite, not a mid-plan discovery | ✓ |
| Work on a branch, hand merges to a maintainer | Human gate mid-phase, same inert-until-merged risk | |
| Plan the archy side to degrade gracefully | Robust, but designs for a half-landed state throughout | |

**User's choice:** Confirm push access before planning starts

---

## Claude's Discretion

- What the music library indexes over, the tag-extraction library, and where the index lives.
- Streaming/token delivery for chat responses; context-window budgeting over node data.
- Which specific tools make the first curated allowlist, within the authority ceiling.
- Routstr provider selection among Nostr-advertised providers.
- Per-category mapping of the 10 permission categories onto individual tools.

## Deferred Ideas

- Cross-node "archipelago content source" with payments (federation distribution feature).
- AIUI Nostr integration polish (carried from Phase 2's deferred list).
- Reviving `ContentPanel.vue` and the plugin-renderer path — cleanup, not architecture.
- A production answer for AIUI's dev-only Vite middleware beyond what this phase replaces.
- Wiring Pine's voice pipeline to the shared tool registry.