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

11 KiB

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.