## User Feedback Report — 2025-12-23 (based on aggregated feedback through 2025-12-22)

### Data snapshot used
- Discord discussions across **2025-12-20 → 2025-12-22**
- GitHub activity (elizaos/eliza) **Dec 22–23**: **8 new issues**, **3 active contributors**
- Notable GitHub issues opened (Dec 22): **#6270–#6274** (UI/UX refinements)

---

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

### 1) Documentation — Token utility, roadmap, and “what is this?” clarity (High frequency, High severity)
**What users report**
- Repeated confusion about **ELIZAOS token utility** and how it ties into the product (“lack of clear documentation on how the token integrates with the platform”).
- Requests to publish token/roadmap info **on the official website** instead of scattered across Discord/GitHub.
- Repeated “when” questions (“Babylon airdrop due?” answered only as “Soon”), increasing frustration and uncertainty.

**Evidence / quantification**
- In the Dec 22 Discord FAQ list, **3 of 8 questions (37.5%)** are explicitly about pricing/payment/utility for token or Cloud (“Do people need to pay in ElizaOS to use ElizaOS Cloud?” was **unanswered**).
- Across Dec 20–22 highlights, token utility/price concerns appear **daily** and dominate the “discussion” channel summaries.

**Category:** Documentation + Communication expectations (see section 4)

---

### 2) Technical Functionality — Plugin-Starknet BigInt parsing error blocks deployments (Medium frequency, High severity for affected users)
**What users report**
- Starknet plugin error: **“Failed to parse String to BigInt”** during `DEPLOY_STARKNET_UNRUGGABLE_MEME_TOKEN`.
- User attempted try/catch + logging but still couldn’t localize the failure; requested maintainers to inspect.

**Evidence / examples**
- Discord (Dec 21–22, coders): FenrirFawks blocked in deployment flow; Odilitime requested modified `unruggable.ts` for review.

**Category:** Technical Functionality

---

### 3) Integration — Twitter/X API cost/rate limits and plugin versioning confusion (Medium frequency, Medium severity)
**What users report**
- Users want Twitter agents but are blocked by **X API pricing + rate limits**.
- Confusion around what works now: “Is Twitter functionality dead?” vs “plugin-twitter works on the **1.x branch** with a **$200/mo** account.”

**Evidence / examples**
- Dec 21: multiple Q&A about X limitations; workaround requires knowing branch/version details.

**Category:** Integration + Documentation (integration guide gap)

---

### 4) UX/UI — Consistency and discoverability issues in the app’s agent-building flow (Medium frequency, Medium severity)
**What users report (GitHub issues)**
- Inconsistent primary action placement: **“Create Agent”** button differs between **My Agents** and **Dashboard** (#6274).
- Workflow ordering friction: avatar button position (#6273).
- Missing inline affordances: inline send button (#6271).
- Missing contextual help: system prompt tooltip (#6270).
- Missing configuration fields: Topics/Adjectives (#6272).

**Evidence / quantification**
- Of the highlighted new issues on Dec 22, **5/5 (100%)** are UX/UI improvements, indicating a concentrated push on UI polish and friction removal.

**Category:** UX/UI

---

### 5) Community / Trust & Safety — Scams, impersonation, and compromised support expectations (Medium frequency, High severity)
**What users report**
- Active scam attempts (“tickets BS is scammers”; warnings not to click suspicious links).
- Users explicitly state they **cannot rely on Discord support** due to impersonators (also echoed in GitHub issue #6211 context: “Discord support compromised”).

**Evidence / examples**
- Dec 20: moderators warn and prevent users from clicking malicious links.
- Dec 21: “tickets BS” called out as scams.

**Category:** Community + Security posture communication

---

### 6) Performance / DX (Developer Experience) — Excessive disk usage in CLI templates (Lower frequency, High severity when hit)
**What users report**
- CLI package using **~17GB** due to database files copied multiple times in starter templates.

**Evidence / examples**
- Dec 21 highlight: Odilitime identified disk space problem in CLI/project-starter templates.

**Category:** Performance + Technical Functionality

---

### 7) Documentation / Onboarding — Migration rules and wallet support confusion (Lower frequency, High severity for affected holders)
**What users report**
- Confusion about migration eligibility (“only tokens bought before snapshot can be migrated”).
- Wallet compatibility issues (Tangem/WalletConnect mentioned in related GitHub issue context; Discord users repeatedly ask for correct contract/new token info).

**Category:** Documentation + Integration (wallet tooling) + Community trust

---

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

### How users are actually using elizaOS
1. **Agents as “crypto operators”** (Web3 execution, token deployment, onchain actions)
   - Example: Starknet plugin used to deploy “unruggable meme token” via an action flow.
   - Implication: Reliability, deterministic error messages, and safe-by-default safeguards matter more than “toy demo” stability.

2. **Agents as “social automation” tools**
   - Twitter/X posting and interaction remains a high-interest integration, but platform policy changes make it brittle and expensive.

3. **Users treat Discord as the primary product documentation**
   - Recurring “what is Eliza Cloud / token utility / migration rules” questions indicate that many users expect a canonical, static source of truth, but end up depending on chat answers.

### Emerging / unexpected use cases
- **Interoperability layer (“plugin → skill” translation)**: community interest in translating elizaOS plugins into skills for platforms like agentskills.io (Jin’s proposal). This suggests users want elizaOS to be **a composable substrate**, not a closed ecosystem.

### Feature requests aligned with observed usage
- **Interoperability translation layer** (plugins ↔ skills) aligns with users running agents across multiple ecosystems.
- **Improved agent builder UX** aligns with Eliza Cloud’s “low-code builder” direction (users will judge the product by workflow smoothness).
- **More robust integration guides + versioning guidance** aligns with Twitter plugin confusion.

---

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

### Pain point A: Token utility & roadmap documentation gap (High impact)
**Solution ideas (prioritized)**
1) **Single “Token Utility & Economics” landing page on the official site** (High impact, Low–Medium effort)  
   - Include: utility today vs planned, buyback policy, staking status, ecosystem airdrop criteria, risk notes, and links to authoritative announcements.
   - Similar approach: many OSS + tokenized ecosystems maintain a “Token Utilities” page plus a changelog-style “Ecosystem updates” hub.

2) **Roadmap with dated, falsifiable milestones + status labels** (High impact, Medium effort)  
   - Use “Now / Next / Later” plus target windows (e.g., “Q1 2026”) and explicit dependencies.
   - Similar approach: Kubernetes-style enhancement tracking or Linear/GitHub Projects public roadmap boards.

3) **Short “Eliza Cloud pricing & payment FAQ”** (High impact, Low effort)  
   - Directly answer: “Do we need ELIZAOS to use Cloud?” (currently showing up as an **unanswered** recurring question).

---

### Pain point B: Starknet BigInt parsing error blocks deployments (High impact for builders)
**Solution ideas**
1) **Improve error observability + typed input validation at action boundary** (High impact, Medium effort)  
   - Add schema validation (e.g., zod) for numeric fields; reject/transform before BigInt parse with actionable messages (“expected decimal string, got hex with 0x…”).
   - Similar approach: Hardhat/Foundry plugins validate CLI params early and print “received X, expected Y”.

2) **Add reproducible test fixture for unruggable deployment inputs** (Medium impact, Medium effort)  
   - Commit a minimal failing payload + unit test that asserts parsing behavior across Node versions.

3) **Add “safe BigInt parsing utility” shared across plugins** (Medium impact, Low–Medium effort)  
   - Centralize parsing rules; ensure consistent behavior across Starknet/EVM tooling.

---

### Pain point C: Twitter/X integration brittleness (Medium impact, Medium effort)
**Solution ideas**
1) **Publish a “Twitter integration matrix” page** (High impact, Low effort)  
   - Table: supported plugin-twitter branches, required API tiers, known limitations, alternative approaches.
   - Explicitly document “1.x branch works with $200/mo plan” to reduce repeated Discord support load.

2) **Add runtime detection + warning in plugin-twitter** (Medium impact, Medium effort)  
   - Detect API errors consistent with rate limit/pricing and print a “next steps” link.

3) **Offer alternative outbound channels in templates (Farcaster/local hub, OpenChat, Discord)** (Medium impact, Low effort)  
   - Reduce dependence on X by making other channels first-class in “starter agent” flows.

---

### Pain point D: UI/UX friction in agent creation and chat workflow (Medium impact, Low–Medium effort)
**Solution ideas**
1) **Standardize primary CTAs and interaction patterns across Dashboard/My Agents** (High impact, Low effort)  
   - Directly addresses #6274 and reduces “where do I click?” confusion.

2) **Inline affordances (send button), contextual tooltips (system prompt)** (Medium impact, Low effort)  
   - Addresses #6271 and #6270; reduces onboarding friction without heavy redesign.

3) **Guided configuration prompts for common fields (Topics/Adjectives)** (Medium impact, Medium effort)  
   - Helps align “low-code” promise with real user needs.

---

### Pain point E: Scams/impersonation undermine support trust (High impact, Medium effort)
**Solution ideas**
1) **“Official Support” verification + locked channel policy** (High impact, Medium effort)  
   - One read-only channel with verified links; disable ad-hoc “ticket” flows unless controlled by vetted bots.
   - Similar approach: many crypto + OSS communities use a locked “official-links” channel and enforce “no DMs from staff” policies.

2) **In-product + website banner for official links and safety rules** (High impact, Low effort)  
   - Especially critical during migration/token events.

3) **GitHub Discussions for support escalations** (Medium impact, Low effort)  
   - For sensitive flows (migration/wallet), route users to public, auditable threads.

---

### Pain point F: CLI disk usage explosion (High impact for affected devs, Medium effort)
**Solution ideas**
1) **Fix templates to avoid duplicating DB artifacts** (High impact, Medium effort)  
   - Ensure DB files are `.gitignore`d and generated at runtime; avoid copying in starter scaffolds.

2) **Add a CLI post-create check** (Medium impact, Low effort)  
   - Warn: “Project size unusually large; likely template duplication bug. Run cleanup: …”

3) **Document expected on-disk footprint** (Low effort)  
   - A simple baseline helps users detect abnormal states early.

---

## 4) Communication Gaps (expectations vs reality)

### Gap 1: “Token utility exists” vs “I can’t find it anywhere canonical”
- Users expect a single authoritative explanation; current info is perceived as scattered (Discord answers, repo activity channel, informal comments).
- Recurring questions (Dec 22 FAQ) suggest users can’t determine:
  - whether Cloud requires ELIZAOS payment (**unanswered**),
  - what the token does today vs later,
  - when airdrops occur beyond “soon”.

**Suggested improvements**
- Publish canonical pages (token utility, Cloud pricing, roadmap).
- Ensure Discord responses link to canonical pages, not vice versa.

### Gap 2: “Eliza Cloud is close to launch” vs unclear user-facing details
- Users ask basic operational questions (“run our own agents with env vars?”).
- Missing clarity: deployment model, secrets management, supported frameworks (beyond “initially elizaOS focused”).

**Suggested improvements**
- “Eliza Cloud MVP: What you can do on day 1” checklist + “What’s not included yet” section.

### Gap 3: Integration reliability expectations (Twitter)
- Users assume “Twitter plugin” is turnkey; reality depends on X pricing tier and plugin branch selection.

**Suggested improvements**
- Integration compatibility matrix + branch/version guidance.

---

## 5) Community Engagement Insights

### Power users / high-leverage contributors and their needs
- **Odilitime**: actively troubleshooting (Starknet), identified CLI disk bloat, provides Twitter plugin guidance.  
  **Need:** faster path from Discord debugging → tracked issue + reproducible case + maintainer confirmation.
- **Jin**: pushing interoperability/composability strategy; flagged major security issue (n8n CVE).  
  **Need:** an RFC process/lightweight design review channel to turn ideas into roadmap items.
- **borisudovicic**: heavy UX issue creation (multiple UI improvements opened).  
  **Need:** product triage feedback loop so issues are batched, prioritized, and validated with users.

### Newcomer friction signals
Common repeated questions indicate onboarding gaps:
- “What is Eliza Cloud?”
- “How do I buy tokens / where are contracts?”
- “Is Twitter integration dead?”
- “Migration eligibility rules / wallet compatibility”
- “Do I pay in ELIZAOS to use Cloud?” (notably **unanswered**)

### Converting passive users into contributors
- Create “good first issue” bundles from the UX batch (#6270–#6274) with screenshots, acceptance criteria, and file pointers.
- Offer “debug bounty” style tasks: reproduce Starknet BigInt parsing with provided logs and minimal payload.
- Add a structured “Integration Maintainers” program (Twitter/Starknet/Discord) with clear ownership and docs responsibilities.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord**: high volume, fast response, but repetitive questions and safety risks (scams/impersonation) reduce trust for sensitive issues.
- **GitHub Issues**: good for UI refinements, but lacks structured reproduction details in some reports (e.g., Starknet issue currently being debugged via DMs/log snippets).

### Recommendations for more structured, actionable feedback
1) **Issue templates by type** (Bug / Integration / UX) with required fields:
   - version/branch, plugin version, steps to reproduce, expected/actual, logs, minimal config.
2) **Monthly “Top questions → Docs PR” cadence**
   - Turn repeated Discord Qs into docs within 72 hours; close the loop by posting the link back in Discord.
3) **Public “Known Issues & Workarounds” page**
   - Especially for Twitter/X, migration edge cases, and plugin-specific pitfalls.

### Underrepresented segments
- **Non-crypto builders**: feedback is dominated by token/market discussion; need more signals from teams using elizaOS purely for automation/productivity.
- **Enterprise/self-host operators**: limited feedback on deployment, security hardening, observability, and compliance—likely because there’s no obvious intake channel for them.

---

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

1) **Publish canonical docs pages**: Token Utility, Roadmap, and Eliza Cloud “pricing/payment + MVP capabilities” (reduce repeated unanswered questions and expectation mismatch).  
2) **Ship a Starknet plugin hotfix path**: add input validation + improved error messages for BigInt parsing; create a minimal repro test to prevent regression.  
3) **Create an “Official Links + Safety” enforcement package**: locked Discord channel, no-DM policy, and in-product/website banner during migration/token events.  
4) **Release an Integration Compatibility Matrix (starting with Twitter/X)**: supported branches, required tiers, setup steps, and fallback channels.  
5) **Implement the small UI quick wins (#6270–#6274)** as a single “agent builder UX polish” sprint with consistent CTA placement and contextual help.