## User Feedback Analysis — 2025-12-28 (Aggregated from Dec 25–27, 2025 + GitHub monthly highlights)

### Data notes / coverage
- Discord: 3 daily logs (Dec 25, 26, 27) across `💬-discussion`, `💬-coders`, `🥇-partners`, `core-devs`.
- GitHub: Daily repo activity (Dec 27–28) minimal; monthly rollup provides relevant open issue (#6211) and recent UX issues.
- Quantification below is based on **frequency within the provided highlights**, not a full message-level scrape.

---

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

### 1) Token migration confusion & perceived unfairness (Category: **Documentation + UX/UI + Community**) — **High severity, high frequency**
**Frequency signal:** Token migration confusion appears in **3/3 daily Discord highlights (100%)** and also in GitHub issue context (snapshot eligibility, wallet support).

**What users report (examples):**
- Migration tool shows “**max amount reached**” and users interpret it as a limit; actually means **wallet not in snapshot** (Odilitime answering yikesawjeez).
- Users see **0 eligible tokens** and don’t understand it’s tied to **Nov 11 snapshot** and **the snapshot wallet** (Dec 25 Q&A).
- Wallet compatibility blocks migration (GitHub **#6211**: Tangem wallet not supported via WalletConnect; cannot export seed phrase).
- Users worry support channels are compromised by impersonators (GitHub **#6211**).

**Primary user impact:**
- Users feel trapped (“newly purchased tokens cannot be migrated ever”), leading to anger, distrust, and support load.
- High risk of scam losses due to confusion and users seeking help.

---

### 2) Token utility / tokenomics clarity vs platform narrative (Category: **Community + Documentation**) — **High severity, high frequency**
**Frequency signal:** Tokenomics debate appears in **3/3 daily highlights (100%)**, with escalating frustration as price declines 90–98% from ATH.

**What users report (examples):**
- Repeated direct question: **“Is elizaOS going to be the native token of Jeju?”** (DorianD); response: plans exist but **not shared externally yet** (Borko).
- Users compare against Ethereum-style clarity (“token must be essential”), criticize shifting narratives and unfulfilled promises (“life-changing event” delayed).

**Primary user impact:**
- Investors and builders can’t evaluate long-term alignment between **Eliza Cloud / Jeju** and **$elizaOS**.
- Builders hesitate to commit if pricing/monetization/token linkage is unclear.

---

### 3) Agent creation validation bugs (reserved words / numeric names) (Category: **Technical Functionality + UX/UI**) — **High severity, medium frequency**
**Frequency signal:** Prominent in `💬-coders` (Dec 27); severe because it causes exceptions and broken agents.

**What users report (examples):**
- Creating agents named **"null"** or **numeric-only** (“1”, “69”, “666”) causes:
  - not saving properly, or
  - **client-side exceptions** / application errors (DorianD).
- Weird inconsistency: **"$" works**, “null” editable but numeric breaks the app.

**Primary user impact:**
- “Footgun” in core UX: users can create agents that later break the dashboard, harming trust in the builder.

---

### 4) Deployment failures and opaque CLI/cloud errors (ECR creds, “username null”, login errors) (Category: **Integration + Technical Functionality + Documentation**) — **High severity, medium frequency**
**Frequency signal:** Deployment/login errors appear across **2/3 days (Dec 26–27)**.

**What users report (examples):**
- `elizaos deploy` failing due to **ECR credentials / repository not found** (DorianD).
- Deployment error: **username null** (Dec 26 highlights).
- Some users experience **application errors when logging into ElizaCloud** (Dec 26 action items).

**Primary user impact:**
- Builders cannot ship; failures feel random and under-documented.
- Support load increases because errors are not self-diagnosable.

---

### 5) Streaming UX gaps for multi-step interactions (Category: **UX/UI + Technical Functionality**) — **Medium severity, medium frequency**
**Frequency signal:** Mentioned on Dec 26 (streaming broken due to deps) and Dec 27 (`core-devs`: multistep UI not as good as “otaku”).

**What users report (examples):**
- Streaming broken in core due to wrong dependencies (Dec 26).
- Streaming added to a component, but **multi-step interactions UI regressed** vs “otaku” (sayonara → Stan ⚡).

**Primary user impact:**
- Users see “partial” streaming that doesn’t support real workflows (tool calls, multi-step reasoning) in a clear way.

---

### 6) Discovery friction: API endpoints, waitlist, and showcasing Cloud projects (Category: **Documentation + Community**) — **Medium severity, recurring**
**Frequency signal:** Several direct questions go unanswered or are answered vaguely (“they’re on the site”).

**What users report (examples):**
- “Where can I find Eliza Cloud API endpoints?” → “they’re there on the site” (Zoopdrop ↔ Odilitime) with follow-up request to make it clearer.
- Newcomer questions unanswered: “How to get in the waitlist?” (ryuusei), “Is there min/max AI16z to migrate?” (Tengev).
- Community wants a way for projects (e.g., **Zoria**) to identify as “built on elizaos cloud” and a dedicated channel/sub-channel.

**Primary user impact:**
- Builders can’t quickly move from “interest” to “integration.”
- Projects lose distribution because there’s no canonical “Built with Eliza Cloud” pathway.

---

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

### How users are actually using elizaOS / Eliza Cloud
1. **Cloud-first agent deployment** (intended + confirmed):
   - Users are deploying agents on ElizaOS Cloud and sharing examples (Dec 26).
   - Requests for **API endpoints** indicate users want programmatic control, not only dashboard usage.

2. **Agents as automation runners for personal workflows** (emerging):
   - R0am uses **async agents** to maintain a long streak on tip.md (“review when I get home, then merge and repeat”).

3. **Agents as interactive “product shells” / community projects** (emerging + distribution-driven):
   - Zoria identified as an “Eliza Cloud project,” and users explicitly discuss labeling to improve distribution.

4. **Expectations drifting toward “general AI assistant” capabilities** (misaligned expectations):
   - Request: plug an AI agent into **DaVinci Resolve** for video editing; suggested workaround uses Gemini screen share (Dec 26). This indicates users expect deeper desktop/app integrations than currently offered.

### Feature requests aligned with observed usage
- **Project identity + showcase**: a structured “Built on Eliza Cloud” badge + directory (requested by satsbased/MDMnvest, reinforced by Zoria discussion).
- **Better API endpoint discoverability + quickstarts**: repeated request suggests users want to build external apps around Cloud, not just use UI.
- **Streaming UX parity with “otaku”**: streaming is being built, but users want it to be usable for multi-step/tool workflows.

---

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

### Pain point A: Migration confusion, eligibility, and wallet support
**High impact / moderate difficulty**
1. **Make migrator errors self-explanatory + actionable**
   - Replace/augment “max amount reached” with: “Not eligible: this wallet was not in the Nov 11 snapshot.”
   - Add a “Why?” tooltip linking to eligibility rules + examples (“moved to Tangem before snapshot → snapshot wallet must connect”).
   - Similar approach: many airdrop claim sites (e.g., Uniswap-style claim pages) show a deterministic eligibility reason + next steps.

2. **Add a “snapshot wallet compatibility” flow**
   - Detect common wallets and show explicit support status; for unsupported wallets, provide **official alternatives** (read-only eligibility check, manual claim request process).
   - For Tangem-style cases (GitHub #6211), publish an **official manual claims policy** (if feasible) or an explicit “not supported” with rationale to reduce scammers exploiting uncertainty.

3. **Harden support against impersonation**
   - Pin a single canonical “Official Links & Support” message; add Discord role-gated support responses; require GitHub issue linking for sensitive migration cases.
   - Similar approach: major crypto projects centralize official links and use signed announcements + locked FAQ channels.

---

### Pain point B: Tokenomics / token utility expectation mismatch
**High impact / moderate difficulty**
1. **Publish a minimal “Token Utility v0” spec**
   - One page answering: what is $elizaOS used for today, what is planned, what is explicitly not planned.
   - Include relationship to Jeju in principle terms even if details are withheld (e.g., “token may / may not be the native fee token; decision criteria and timeline”).

2. **Roadmap transparency with “confidence levels”**
   - Mark items as Committed / Planned / Exploratory, and provide expected update cadence.
   - Similar to how Kubernetes and Rust roadmaps communicate “accepted RFC vs idea,” reducing rumor-driven expectations.

3. **Separate “tech progress” updates from “market narrative”**
   - Weekly engineering update (Jeju progress, streaming, auth) + monthly token/economics update to avoid mixing and to meet investor needs without derailing dev channels.

---

### Pain point C: Agent naming bug (null/numeric causing exceptions)
**High impact / low difficulty**
1. **Add server-side validation + canonical constraints**
   - Enforce: non-empty, length bounds, disallow reserved words (`null`, `undefined`), disallow numeric-only, normalize whitespace.
   - Return a clear error: “Agent name must contain at least one letter.”

2. **Add client-side guardrails**
   - Inline validation before submit + unit tests for edge cases (“1”, “69”, “null”, emoji, `$`, etc.).
   - Similar to GitHub repo naming rules and Slack channel naming: upfront constraints prevent broken entities.

3. **Add a migration/repair tool for already-broken agents**
   - If numeric-named agents exist, provide a safe rename path or auto-rename on load to prevent dashboard crashes.

---

### Pain point D: Deploy/login errors and opaque CLI/cloud failures (ECR, username null)
**High impact / moderate difficulty**
1. **Introduce a “doctor” command + structured error taxonomy**
   - `elizaos doctor` checks AWS/ECR prereqs, auth state, region, repository existence, and prints copy-pastable diagnostics.
   - Similar to `kubectl cluster-info` / `gcloud doctor` patterns.

2. **Improve error surfaces with remediation links**
   - When ECR repo missing: “Repository not found. Create it with: …” or auto-create if permissions allow.
   - When username null: block action and prompt user profile completion or re-authentication.

3. **Add a minimal deployment troubleshooting guide**
   - One page: common errors, what they mean, exact commands to resolve (ECR login, repo create, env vars, bun requirement).

---

### Pain point E: Streaming UX for multi-step/tool interactions
**Medium impact / moderate difficulty**
1. **Adopt a “message timeline” UI model**
   - Render steps as discrete timeline items: User → Tool call → Tool result → Assistant partials/final.
   - Similar to how OpenAI/Anthropic console UIs present tool invocation events.

2. **Add SSE/socket event contracts for step boundaries**
   - Explicit events: `assistant_delta`, `tool_start`, `tool_result`, `assistant_final`.
   - Ensures “otaku-like” multistep clarity regardless of provider.

3. **Add regression tests for streaming UI**
   - Golden test scenarios: multi-tool, interrupts, retries, and long-running steps.

---

## 4) Communication Gaps (expectations vs reality)

### Recurring gaps
- **Migration semantics are unclear from UI**:
  - “max amount reached” is interpreted as a quota, not snapshot ineligibility.
- **Wallet support expectations vs actual**:
  - Users assume any wallet holding tokens at snapshot can connect; Tangem case shows that’s not true (GitHub #6211).
- **Jeju/token relationship ambiguity**:
  - Users expect a direct answer; current stance is “not shared externally yet,” which fuels speculation.
- **API endpoint discoverability**:
  - “They’re on the site” is not sufficient; users want a stable docs URL and examples.
- **Newcomer onboarding**:
  - Questions about waitlist and migration min/max go unanswered, indicating missing entry-point documentation.

### Specific improvements
- Add a **single canonical “Start Here”** for:
  - migrating, deploying, finding endpoints, joining waitlists, and security warnings.
- Add a **“Known limitations”** section (wallet support matrix, bun-only policy, streaming limitations).

---

## 5) Community Engagement Insights

### Power users / highly engaged contributors (and their needs)
- **DorianD**: repeatedly reports actionable bugs (agent naming, ECR deploy, required description mismatch) and asks tokenomics integration questions. Needs: fast triage, clear issue templates, and a dev-facing roadmap.
- **Shaw**: driving core infra vision (Jeju, distributed SQLite). Needs: structured feedback from cloud users and naming/branding decisions supported by community polls.
- **Stan ⚡** and **sayonara**: actively improving streaming and chat UI. Needs: prioritized UX acceptance criteria (what “good multistep UI” means).
- **Odilitime**: doing front-line support on migration and docs. Needs: better self-serve docs to reduce repetitive Q&A.

### Newcomer friction signals
- Unanswered questions (“waitlist,” “min/max migrate”) and wallet confusion indicate onboarding gaps.
- Token-price sentiment dominates, pulling attention away from building unless builder pathways are highly visible.

### Converting passive users into contributors
- Create “good first issue” bundles around:
  - validation bugs (agent naming), doc fixes (API endpoints page), and CLI error messaging.
- Add a “Built on Eliza Cloud” submission form + lightweight review to motivate builders to share.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord**: high volume and fast help, but unstructured; repeated questions suggest knowledge isn’t being captured.
- **GitHub**: better for durable tracking (e.g., #6211), but daily activity can be minimal and users may avoid it unless prompted.
- Support risk: impersonation/scams (explicitly raised in #6211) undermines trust in Discord-only support.

### Improvements (structured + actionable)
1. **In-product feedback button** (already hinted as a request in ecosystem issues)
   - Collect: page, action, error logs, user intent (deploying/migrating/building).
2. **Standardized Discord → GitHub escalation**
   - A bot workflow that turns repeated questions into a draft FAQ entry or GitHub discussion.
3. **Segmented surveys**
   - Separate surveys for: (a) builders using Cloud/CLI, (b) token holders doing migration, (c) plugin developers.

### Underrepresented segments
- **Non-exportable hardware wallet users** (Tangem-like) surfaced as a distinct, underserved group.
- **Enterprise/devops deployers**: ECR and SSO discussions suggest this segment exists but feedback is sparse and anecdotal.

---

## Prioritized High-Impact Actions (next 2–4 weeks)

1. **Fix migrator messaging + publish a single official migration FAQ/security page** (highest impact, low–moderate effort)  
   - Replace ambiguous errors (“max amount reached”), document snapshot rules, add wallet support matrix, and pin official links.

2. **Implement agent-name validation (server + client) and provide a repair path for broken agents** (high impact, low effort)  
   - Prevent dashboard-crashing entities and reduce support/debug churn.

3. **Add CLI/Deploy “doctor” diagnostics and improve ECR/login error remediation text** (high impact, moderate effort)  
   - Converts opaque failures into self-serve fixes; reduces repeated Discord troubleshooting.

4. **Create a dedicated “Eliza Cloud API & Quickstart” docs page with stable URL + examples** (medium–high impact, low effort)  
   - Addresses repeated endpoint questions and accelerates real integrations.

5. **Ship a “Built on Eliza Cloud” identity + showcase pipeline (badge + directory + Discord channel)** (medium impact, moderate effort)  
   - Aligns with observed usage (projects like Zoria) and helps distribution/community growth.