## User Feedback Analysis — 2025-12-25 (based on Dec 22–24 Discord + Dec 24–25 GitHub activity)

### Data Snapshot (what this report is based on)
- **Discord highlights reviewed:** 3 daily summaries (Dec 22, 23, 24)
- **GitHub (elizaos/eliza) activity:** **4 new issues** opened Dec 24–25; **0 PRs merged**; **2 active contributors**
- **Note:** No standalone Dec 25 Discord digest was provided; this report reflects the latest available feedback leading into Dec 25.

---

## 1) Pain Point Categorization (Top recurring friction areas)

### 1) Documentation — Token utility + revenue model clarity (High frequency, high severity)
**What users struggle with**
- Confusion about **how token value accrues**, especially the distinction between **Eliza Cloud revenue** vs **yield** (“revenue used for buybacks, yield won’t” needed repeated clarification).
- The **technical roadmap** is being interpreted as a promise of token value accrual, creating mismatch (“roadmap is technical, not tokenomics”).
- Repeated questions: “Why invest if Cloud doesn’t impact token?”, “Where does the roadmap mention value accrual?”, “What is generative treasury?”

**Evidence / quantification**
- Tokenomics/utility concerns appear in **all 3/3 Discord daily summaries (100%)** reviewed (Dec 22–24).
- Multiple unanswered token-related questions remained open in Discord (e.g., CEX listing contact, post-migration purchases).

**Category:** Documentation (+ Community expectations management)

---

### 2) UX/UI — Agent chat history behavior (High severity in product experience)
**What users struggle with**
- **Conversation duplication / cross-agent leakage:** “conversations with one agent appearing in another agent’s chat history.” (Issue #6282)
- **Wrong default context:** Opening an agent chat from Dashboard/My Agents does **not** automatically show the most recent conversation. (Issue #6281)

**Evidence / quantification**
- **2/4 GitHub issues (50%)** opened Dec 24–25 are about agent chat conversation behavior (#6281, #6282).

**Category:** UX/UI (with likely underlying data/model bug)

---

### 3) Documentation — Monorepo docs are outdated/false (Medium frequency, high severity for onboarding)
**What users struggle with**
- Monorepo documentation contains **outdated or incorrect** guidance; community members began updating it.
- GitHub issue explicitly filed for doc fixes (#6284).

**Evidence / quantification**
- **1/4 GitHub issues (25%)** opened Dec 24–25 is directly about monorepo documentation (#6284).
- Discord core-dev discussion also flags “outdated/false info” being updated.

**Category:** Documentation

---

### 4) Technical Functionality / DevEx — Environment and CI brittleness (Medium frequency, medium-high severity)
**What users struggle with**
- CLI installation friction tied to **Node/Bun version mismatches**.
- DTS generation issues mentioned.
- **GitHub Actions failure** due to external billing (Claude top-up), creating avoidable disruption.

**Evidence / quantification**
- Multiple action items and troubleshooting threads in Discord core-devs/coders on Dec 24.

**Category:** Technical Functionality (DevEx + Reliability)

---

### 5) Performance / UX — Knowledge ingestion constraints & ambiguity (Medium frequency, medium severity)
**What users struggle with**
- Users want to upload large corpora (e.g., “300 pages of book data”) and are unsure what “too much context” means in Cloud.
- Hard limit disclosed: **50MB upload cap**; markdown recommended, but guidance is thin on chunking/refresh/indexing.

**Evidence**
- Direct Q&A in Discord coders (Dec 24) about uploading book-scale content and context limits.

**Category:** UX/UI + Performance (knowledge pipeline expectations)

---

### 6) Integration — Custom model hosting not available yet (Medium frequency, medium severity)
**What users struggle with**
- Users want to run **open-source models on their own GPUs** “via ElizaOS Cloud” but can’t yet.
- Roadmap suggests “next week,” but lack of a public spec/constraints creates repeated questions.

**Evidence**
- Direct Q&A on Dec 24; feature is “on roadmap / likely next week.”

**Category:** Integration (deployment/model-provider flexibility)

---

### 7) Community / Security — Wallet migration confusion + scam risk (Medium frequency, high severity)
**What users struggle with**
- Users unsure how to migrate tokens from specific wallets (Moonshot → migration site).
- Community warning about scams/impersonation risk during migration flows; users directed to move to Phantom for safety.

**Evidence**
- Dec 24 Discord discussion includes explicit scam warnings and wallet migration guidance.

**Category:** Community (with security implications)

---

## 2) Usage Pattern Analysis (actual usage vs intended)

### How users are actually using elizaOS/Cloud
- **Cloud as “agent knowledge host” for long-form content** (books/medical/psych material), not just lightweight prompts:
  - Users ask about uploading “300 pages” and “context size,” indicating a **RAG/knowledge base** mental model rather than “chatbot config.”
- **Cloud as an AI-assisted dev tool / low-code builder** (aligned with intended), but with **expectations of advanced hosting** (bring-your-own-model GPU).
- **Power users are dogfooding UI flows** and filing high-volume UX issues (e.g., dashboard/chat behaviors), suggesting the app is being used daily as a primary interface, not only the CLI.

### Emerging / unexpected use cases
- **Health/illness-related agent** built from book data (signals demand for compliance-minded guidance, data handling clarity, and safer knowledge workflows).
- Community project: **AI gaming assistant on Steam (GAMEBORO)**—signals interest in “agent in real product surfaces” beyond crypto-native use.

### Feature requests aligned with observed usage
- **Custom model hosting / BYO GPU** (fits builders who want cost/control and open-source models).
- **Better knowledge ingestion UX** (chunking, indexing status, format conversions).
- **Interoperability tooling** (proposal to translate elizaOS plugins to skills for agentskills.io) aligns with multi-framework reality.

---

## 3) Implementation Opportunities (concrete solutions per major pain point)

### A) Token utility + revenue model confusion (Documentation / Expectation management)
**High impact / Low–Medium difficulty**
1. **Publish a canonical “Token Utility & Value Accrual” page** linked from:
   - Cloud dashboard (billing/revenue area)
   - GitHub README + Discord pins  
   Include: revenue vs yield, buyback mechanics, timeline gates (e.g., “Jeju adds X utility”), and explicit non-goals.
2. **Add a “Tokenomics FAQ” bot command and pinned Discord post** that answers the recurring questions verbatim (investment rationale, buybacks, roadmap scope).
3. **Roadmap framing fix:** add a short “What this roadmap is / isn’t” preface on GitHub (technical roadmap ≠ tokenomics plan).

**Comparable approaches**
- Many infra projects (e.g., **Arbitrum/Optimism ecosystems**) separate **technical roadmap** from **token governance/value** docs and pin both distinctly to reduce misinterpretation.

---

### B) Conversation duplication + incorrect default conversation (UX/UI + likely data isolation bug)
**High impact / Medium difficulty**
1. **Define and enforce a stable conversation keying model**:
   - Ensure conversations are scoped by `(entityId/userId) + agentId + roomId/sessionId`.
   - Add regression tests for “no cross-agent leakage” (similar to multi-tenant isolation tests).
2. **UI change:** when opening from My Agents/Dashboard, **auto-select the most recent conversation** for that agent (Issue #6281).
3. **Add a “Report chat mix-up” quick action** in the chat UI that captures diagnostic context (agentId, conversationId, timestamps) to accelerate debugging.

**Comparable approaches**
- Products like **Slack/Discord clients** treat channel/thread identifiers as immutable scope boundaries and add telemetry for “wrong thread opened” events.

---

### C) Outdated monorepo docs (Documentation)
**High impact / Low–Medium difficulty**
1. **Add versioned documentation gates**:
   - “Applies to elizaOS >= X.Y” badges at the top of key docs.
   - CI check that fails if docs reference removed packages/paths (e.g., moved docs folders).
2. **Create a single “Monorepo quickstart (15 minutes)” path** that’s continuously tested via CI (smoke test runs the documented steps).
3. **Docs ownership + rotation**: assign maintainers per doc section and require doc updates in PR template when touching core APIs.

**Comparable approaches**
- **Next.js / Vite** maintain “create-* + docs + CI smoke tests” to ensure the quickstart never drifts from reality.

---

### D) DevEx brittleness: Node/Bun/version mismatches + CI blocked by billing (Technical Functionality)
**Medium–High impact / Low–Medium difficulty**
1. **Add `elizaos doctor`** (CLI) to validate:
   - Node/Bun versions
   - required env vars
   - filesystem permissions
   - plugin compatibility
2. **Pin and auto-install toolchain versions**:
   - `.tool-versions` (asdf) or `mise.toml`
   - `.nvmrc` + Bun version guidance
3. **CI resilience:** isolate paid API-dependent checks (Claude) behind:
   - a separate workflow
   - required only on main/release
   - clear failure message + fallback (or mocked mode)

**Comparable approaches**
- **Vercel/Turbo** style “diagnostics command” and **GitHub Actions** best practice: keep paid/external checks non-blocking for core CI.

---

### E) Knowledge ingestion limits and unclear “context” expectations (UX + Performance)
**Medium impact / Medium difficulty**
1. **Make ingestion explicit**:
   - Show upload size limit in UI before upload (50MB)
   - Show indexing status (“queued / chunking / embedded / ready”)
2. **Provide a built-in “Document Prep” tool**:
   - Convert PDF/Doc → Markdown
   - Chunking presets (“book”, “faq”, “codebase”)
3. **Publish practical guidance**:
   - “300-page book” recipe: chunk size, citation approach, memory vs retrieval, when to summarize.

**Comparable approaches**
- **OpenAI Assistants / LangChain** ecosystems publish “document ingestion recipes” and surface indexing states to reduce confusion about what the system actually “knows.”

---

### F) Custom model hosting expectations (Integration)
**Medium impact / Medium difficulty**
1. **Publish a public spec** for BYO model hosting:
   - supported runtimes (OpenAI-compatible? vLLM? TGI?)
   - auth method
   - latency/timeout constraints
2. **Ship incremental support**:
   - Start with “OpenAI-compatible endpoint” integration (lowest friction)
   - Then add GPU/self-host templates (Docker + Helm)
3. **Add a “Model Provider matrix”** page showing capabilities (streaming, tool calls, embeddings).

**Comparable approaches**
- **LiteLLM** and **OpenRouter-like aggregators** succeed by standardizing on “OpenAI-compatible APIs” first, then expanding.

---

### G) Wallet migration + scam risk (Community / Security)
**High impact / Low difficulty**
1. **Create an “Official Migration Safety” page**:
   - canonical links
   - “we will never ask you to send tokens”
   - wallet-by-wallet guidance (Moonshot, Phantom, Tangem constraints)
2. **Discord hardening**:
   - locked migration support channel (read-only + verified staff replies)
   - auto-moderation to block link posts in migration threads
3. **Add an on-site verification banner**:
   - signed announcements (e.g., GitHub release notes) referenced from the migration portal.

**Comparable approaches**
- Major token migrations (e.g., **L2 airdrops/migrations**) routinely use “read-only official channels + signed links” to reduce impersonation harm.

---

## 4) Communication Gaps (expectations vs reality)

### Recurring expectation mismatches
- **“Roadmap implies token value accrual” vs reality:** roadmap is technical; users want tokenomics clarity in the same place they’re pointed to.
- **“Upload a book = agent has it in context” vs reality:** upload size is capped (50MB) and “context” is not the same as retrieval; users need an explicit mental model.
- **“Cloud lets me use my GPU models now” vs reality:** not yet; “next week” without constraints invites repeated questions.

### Recurring questions indicating onboarding gaps
- “What is Eliza Cloud?” (still asked on Dec 22)
- “What format should I upload?” (answered: markdown)
- “How do I migrate from Moonshot?” plus post-snapshot edge cases (unanswered items present)

### Specific improvements to align expectations
- Add a **Cloud “Limits & Capabilities”** page in-product: upload limits, supported formats, model provider support, streaming status.
- Add “If you are here for tokenomics, read this page” routing from Discord pins and GitHub roadmap.

---

## 5) Community Engagement Insights

### Power users / high-leverage contributors observed
- **borisudovicic**: high-volume UX issue filing; needs a tighter feedback loop (triage labels, quick confirmations, “accepted” status).
- **Stan ⚡**: actively updating monorepo documentation; benefits from doc ownership and fast review/merge lane.
- **sayitaintso25**: persistent tokenomics questions; represents a broader cohort needing clear, centralized answers (turn into FAQ improvements).
- Core responders helping unblock users: **Borko, Odilitime, Kenk, Nuclear Gandhi, Hexx 🌐**.

### Newcomer friction patterns
- Wallet migration newcomers: unsure which wallet/path is “official” and safe.
- Builder newcomers: want to upload large knowledge sources and host custom models immediately; need clearer “what works today” onboarding.

### Converting passive users into contributors
- Create a **“UX Triage Squad”** program for users like borisudovicic:
  - templates for reproducible UX bug reports
  - weekly shortlist of “needs confirmation” issues
- Offer **“Docs bounty board”**: small, well-scoped doc fixes with fast merge and visible credit.
- Run short **Cloud beta office hours** (builders bring real workloads like book ingestion; team captures requirements live).

---

## 6) Feedback Collection Improvements

### Effectiveness of current channels
- **Discord** is strong for rapid Q&A but weak for:
  - closing the loop (many unanswered questions persist)
  - converting repeated confusion into durable docs
- **GitHub issues** are capturing concrete UX problems well (e.g., chat history behavior), but lack structured product analytics context.

### Improvements for structured, actionable feedback
1. **Add an in-product “Send feedback” button** in Cloud (captures page, agentId, logs consent).
2. **Adopt GitHub issue forms** for:
   - Chat/history bugs (require agentId, steps, expected vs actual)
   - Docs issues (require page URL + version)
3. **Weekly “Top repeated Discord questions” digest** that turns into:
   - FAQ entries
   - doc PRs
   - pinned answers

### Underrepresented segments missing from feedback
- **Non-Phantom / non-exportable wallets** (Tangem-like constraints show up elsewhere in the month; Moonshot appears here): need targeted migration support docs.
- **Self-hosting / enterprise operators**: asking for BYO GPU suggests a cohort with infra needs not yet systematically captured.
- **Non-crypto builders**: health/book ingestion use case suggests broader audiences who need privacy/compliance clarity.

---

## Prioritized High-Impact Actions (next 1–2 weeks)
1. **Fix and regression-test chat history isolation** (Issue #6282) and implement “open most recent conversation by default” (Issue #6281).  
2. **Publish a canonical Token Utility / Buyback / Revenue vs Yield doc** and pin it in Discord + link from Cloud UI; add “roadmap is technical” preface.  
3. **Ship Cloud “Limits & Capabilities” page (in-product)** covering 50MB uploads, ingestion model, supported formats, and custom model hosting status/spec.  
4. **Add `elizaos doctor` + toolchain pinning** to reduce Node/Bun/version friction; make paid-API CI checks non-blocking or clearly isolated.  
5. **Migration safety hardening:** official safety page + read-only verified Discord migration channel + anti-scam link controls.