# User Feedback Analysis — 2025-12-22 (elizaOS)

## Data coverage & confidence notes
- **Discord logs available:** 2025-12-19, 2025-12-20  
- **Discord logs missing:** 2025-12-21  
- **Daily file missing:** 2025-12-22.md  
- **GitHub signals used:** December monthly summary metrics, top issues/PRs, and weekly summary (Dec 14–20)

Given missing daily logs for 12/21–12/22, findings emphasize **recurring** themes visible across Discord (19–20) + GitHub December activity.

---

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

### 1) Integration — Token migration workflow + wallet support gaps (High severity, high frequency)
**What users are reporting**
- Migration confusion and edge cases:
  - Snapshot eligibility rules (“only tokens bought before snapshot can be migrated”) repeatedly asked on Discord (12/20) and appears as unresolved/complex on GitHub (#6211).
  - Users seeing **“0 eligible”** and not understanding whether it’s expected or fixable (Discord 12/19; GitHub #6211).
- Wallet connectivity limitations (Tangem / WalletConnect incompatibility) blocks legitimate users (#6211).
- Cross-chain liquidity and selling slippage confusion (Discord 12/20: “40% price difference on Solana”; advised to bridge to BSC).

**Quantification (from available artifacts)**
- **3 of 5** Discord “Key Questions & Answers” on 12/20 (60%) were directly about **migration / contracts / token utility**.
- Discord 12/19 “Key Q&A”: **5 of 6** questions (≈83%) were token/migration-related.

---

### 2) Community — Scam/impersonation risk impacting support trust (High severity, medium-high frequency)
**What users are reporting**
- Multiple warnings about scammers sending suspicious links (Discord 12/20).
- Users explicitly stating Discord support is “compromised” by impersonators and preferring GitHub for safety (#6211).

**Impact**
- Users avoid official help channels, delaying resolution and increasing anxiety during migration.
- Support workload increases due to repeated verification and escalation requests.

---

### 3) Documentation — “Where is X?” + unclear canonical sources (Medium severity, high frequency)
**What users are reporting**
- Users can’t find docs after repo restructuring: “Where did packages/docs/ go?” (#6122).
- Requests for a public docs UI + API explorer + architecture overview (#6128).
- Migration documentation is repeatedly requested (“Create clear explanation of token migration process and deadlines” surfaced in Discord 12/19 action items).
- “What model does the agent use?” answered as “model agnostic,” indicating ongoing expectation mismatch and need for a clear explanation.

**Quantification**
- In GitHub “top issues,” **2 of 5** are explicitly docs/documentation-UX requests (#6122, #6128) (40% of top-5 by prominence).

---

### 4) Technical Functionality — Setup sharp edges for local/dev and plugin initialization (Medium severity, medium frequency)
**What users are reporting**
- Local runtime crash when `.eliza` directory missing; user expected auto-create (#6204). (Fix landed via plugin-sql directory creation work, but the pain point shows onboarding friction.)
- NPM token / publishing disruptions mentioned in Discord (12/19–12/20): NPM changed tokens, classic tokens deleted → release friction.
- Confusion about what agents can/can’t do (e.g., “can read console logs… uncertain about other capabilities” on Discord 12/20).

---

### 5) UX/UI — Plugin selection clarity + terminology mismatches (Medium severity, medium frequency)
**What users are reporting**
- Multiple UI/UX issues created around plugin selection feedback and toggles (#6235, #6236).
- Terminology confusion: rename “Knowledge” → “Files” (#6237).
- Users ask comparisons to familiar tools (“difference between this and playwright/puppeteer?”), suggesting UI/positioning needs clearer “what you get out of the box.”

---

### 6) Performance / Reliability — Streaming + chat/session robustness concerns (Medium severity, emerging)
**What users are reporting**
- Streaming is a major theme: cloud streaming “Monday release,” v1.7.0 “streaming functionality,” and multi-plugin streaming efforts.
- A conversation blocking issue fixed when no summary existed (Discord 12/19 highlight), indicating prior reliability friction in chat/session creation.

---

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

### Observed “actual” usage patterns
1. **Web3-first community segment using elizaOS as a token + migration ecosystem**
   - A substantial portion of Discord activity is about migration, liquidity, contract addresses, and deadlines (12/19–12/20).
   - This segment treats Discord as primary support—but scam risk is pushing them toward GitHub (#6211).

2. **Developer segment building agents from scratch (code-first)**
   - Example: #6204 shows a minimal runtime setup using `AgentRuntime`, SQL plugin, OpenAI plugin, and manual `.eliza` directory creation.
   - Indicates “getting started” is often **not** via polished UI flows, but by composing plugins and bootstrapping runtime programmatically.

3. **Emerging Cloud + CLI-driven workflow**
   - Cloud MVP shipping soon (Discord 12/20).
   - PRs emphasize “create → deploy → publish and monetize” flow integration (PR #6216).
   - Users are likely adopting Cloud as a default provider (PR #6208), but expectations about what’s automatic vs manual are still forming.

4. **Plugin ecosystem + integration builders**
   - Active work on unified messaging APIs for Telegram/Discord plugins and self-hosted Farcaster plugin suggests users want **multi-channel agents** and more control (self-hosted hubs).

### Emerging / unexpected use cases
- **Trading/analytics integrations** requested (TradingView chart functionality; Discord 12/20).
- **Customer support / internet support agents** (Discord 12/19 action items), implying demand for production-grade “support agent” templates and observability.

### Feature requests aligned with usage
- Public docs UI + API explorer (#6128) aligns with code-first + Cloud onboarding needs.
- Clear token migration UX + wallet support aligns with dominant Discord usage.
- Streaming improvements align with cloud release and desire for real-time agent interactions.

---

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

### Pain Point A: Token migration confusion + wallet incompatibility
**Solutions (prioritized by impact vs difficulty)**
1. **High impact / Medium difficulty:** Add a “Migration eligibility debugger” in the portal  
   - Inputs: wallet address, snapshot date, chain, holding proof hints  
   - Outputs: why eligible/ineligible, next steps, and safe official links  
   - Similar pattern: **Uniswap airdrop checkers** and **Optimism eligibility UIs** provide deterministic, user-trust-building explanations.

2. **High impact / Medium difficulty:** Add a formal “unsupported wallet” path (Tangem-like)  
   - E.g., signed message verification + manual claim initiation without requiring WalletConnect  
   - Provide an official process with time-bound tickets and on-chain proofs where possible  
   - Comparable approach: **Arbitrum airdrop support** and many NFT mints used “sign message from address” flows to prove ownership.

3. **Medium impact / Low difficulty:** Publish a single canonical migration page with a decision tree  
   - “Bought after Nov 11?” → not eligible  
   - “Held in wallet without WalletConnect?” → alternate route  
   - “Seeing 0 eligible?” → common causes checklist  
   - Include deadline callout (Feb 4, 2026) and “never send tokens to anyone” banner.

---

### Pain Point B: Scam/impersonation undermining support channels
**Solutions**
1. **High impact / Low-medium difficulty:** Implement “Verified Support” hardening in Discord  
   - Lock migration support to a single channel with slowmode + read-only pinned official steps  
   - Use Discord “Community” features: verified roles, automod link filtering, and a bot that replies with official URLs when keywords like “migration” appear  
   - Similar approach: many Web3 projects use **Collab.Land + automod + link allowlists**.

2. **High impact / Medium difficulty:** Move sensitive support flows off Discord  
   - Use GitHub Discussions or a ticket portal with verified domain + signed announcements  
   - Users already request GitHub as safer channel (#6211).

3. **Medium impact / Low difficulty:** Add an always-updated “Official Links Registry” page  
   - Contract addresses per chain (as repeatedly requested on Discord 12/20)  
   - Migration portal URL, support URLs, Cloud URL  
   - Include checksum/verification guidance.

---

### Pain Point C: Documentation findability + onboarding gaps
**Solutions**
1. **High impact / Medium difficulty:** “Docs landing + Quickstart paths” segmented by persona  
   - Paths: “Build locally,” “Deploy on Cloud,” “Write a plugin,” “Migration/token FAQ”  
   - Mirror strategy used by **Supabase**, **LangChain**, and **Vercel** docs that start with role-based entry points.

2. **High impact / Low difficulty:** Add prominent in-product pointers  
   - CLI: after `elizaos create`, print “Next steps” URLs (docs + Cloud login + plugin registry)  
   - GitHub: update README(s) to point to canonical docs repo (addresses confusion like #6122).

3. **Medium impact / Medium difficulty:** Add an “OpenAI-style API explorer” (requested in #6128)  
   - Lets users validate auth, list agents, send messages, see streaming responses.

---

### Pain Point D: Setup sharp edges (directories, env, plugin init)
**Solutions**
1. **High impact / Low difficulty:** Expand “preflight checks” + actionable errors  
   - If `.eliza` missing, auto-create (already addressed in plugin-sql area; ensure consistent across runtimes)  
   - If env vars missing, print a single consolidated diagnostic.

2. **Medium impact / Medium difficulty:** Provide a “known good minimal project” template  
   - Includes SQL + one model provider + streaming toggle + logging best practices  
   - Similar approach: **Create Next App**-style templates reduce time-to-first-success.

3. **Medium impact / Medium difficulty:** Add capability introspection page (“What can this agent do?”)  
   - Lists enabled plugins/tools, permissions, and whether it can read logs, browse web, etc.

---

### Pain Point E: UX/UI clarity (plugins, terminology, mental models)
**Solutions**
1. **High impact / Medium difficulty:** Plugin selection redesign  
   - Clear “recommended” defaults per use case (chat, support agent, social bot)  
   - Better visual feedback (issues #6235/#6236 already point here)

2. **Medium impact / Low difficulty:** Terminology alignment pass  
   - Rename “Knowledge” → “Files” (#6237) and define RAG in-context (tooltip)

3. **Medium impact / Medium difficulty:** Comparison pages (“elizaOS vs puppeteer/playwright vs agentic tooling”)  
   - Reduces repetitive Discord questions and sets expectations.

---

## 4) Communication Gaps (Expectations vs reality)

### Recurring expectation mismatches
- **“Model agnostic” vs “What model does it use?”**  
  Users expect a single default model choice; reality is multiple providers + plugins. Needs a simple explanation: “Core is model-agnostic; you choose a provider plugin or Cloud.”

- **Migration rules and deadlines not “sticky” enough**  
  Users repeatedly ask about snapshot timing and eligibility; implies current messaging is either scattered or not prominent at the decision point.

- **Capabilities uncertainty (what the agent can do)**  
  Example: Discord user confirmed console log reading but was unsure about “other capabilities.” This suggests missing capability inventory and permission model explanation.

### Documentation/onboarding gaps indicated by recurring questions
- “Where is the new contract address?”
- “Can I migrate if I bought after Nov 11?”
- “Why does selling on Solana differ by 40%?”
- “How do I connect wallet X (Tangem)?”
- “What does elizaOS do that puppeteer/playwright doesn’t?”

### Specific improvements
- Add a **Migration FAQ** embedded into portal UI (not just Discord pins).
- Add a **“Capabilities & Permissions”** doc page linked from the agent dashboard.
- Add a **“Choosing a Provider”** page shown in CLI and UI on first run.

---

## 5) Community Engagement Insights

### Power users & their needs (and how to support them)
- **Core contributors and maintainers** are pushing streaming, auth, and refactors (e.g., streaming work in v1.7.0; large infra PRs; unified messaging APIs).  
  Needs:
  - Clear contribution lanes (good first issues for docs/UI vs core)
  - Faster triage loops for ecosystem-wide changes (plugin compatibility, version mismatches)

- **Plugin builders** (Telegram/Discord/Farcaster/EVM work) need:
  - Stable interfaces (unified messaging API)
  - Version compatibility tooling (registry mismatch detection is a good step)

### Newcomer questions signaling onboarding friction
- “How do I start / what model is used / what can it do?”
- “Why is my migration 0 eligible?”
- “Where are docs now?”

### Converting passive users to contributors
- Create “one-hour contribution packs”:
  - Update a FAQ entry (migration, provider choice)
  - Add a docs snippet for a wallet/provider
  - Validate a plugin against latest core and report results
- Highlight community helpers (e.g., users providing bridging guidance and scam prevention on Discord 12/20) and invite them into a “Support Champions” role with scripts + official macros.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord:** High volume, fast responses, but **low trust** during token/migration period due to scams; also produces repetitive Q&A.
- **GitHub Issues:** Better for traceability and safety, but not optimized for high-frequency support queries (migration edge cases).

### Improvements for more structured, actionable feedback
1. **Introduce standardized intake forms**
   - Migration support form: wallet type, snapshot holdings, chain, portal result, screenshots, transaction hashes
   - “Getting started bug” form: OS, node/bun versions, plugins used, logs

2. **Weekly “Top 10 Questions” digest**
   - Post in Discord + docs; update canonical FAQ
   - Track reductions in repeats as a KPI

3. **In-product feedback hooks**
   - In migration portal: “Was this explanation helpful? yes/no” + text field
   - In CLI: prompt link after create/deploy failures

### Underrepresented segments (missing feedback)
- Non-Discord users attempting migration (they may drop silently).
- Enterprise/production users running support agents (early hints exist, but detailed operational feedback is sparse).
- Users deploying on constrained infra (performance/streaming feedback likely under-captured).

---

## Prioritized High-Impact Actions (next 2–4 weeks)
1. **Ship a canonical Migration Center (portal + docs) with eligibility debugger + decision tree**, including Tangem/unsupported wallet path and prominent anti-scam warnings.  
2. **Harden support trust:** Verified-only migration support flow, official links registry, and move sensitive cases to GitHub Discussions or a verified ticket portal.  
3. **Persona-based docs landing page + “Choosing a Provider / Model-agnostic explained” + “Capabilities & Permissions” page**, linked from CLI and UI.  
4. **Add preflight checks and capability introspection** (auto-fix common setup issues; show enabled plugins/tools clearly).  
5. **Close the loop with structured feedback:** add migration and onboarding forms + publish a weekly FAQ digest to reduce repeated Discord questions.