# User Feedback Analysis — 2026-03-20 (elizaOS) ## 1) Pain Point Categorization (Top Recurring 5–7) ### 1. Community — Token crisis + trust/continuity concerns (Highest frequency & severity) **What users reported (recurring themes):** - Token hit new all-time lows (reported “99% down”, falling below $10 into ~$9); CoinMarketCap rank drop (#990 → #1036) drove panic and anger (3/19 💬-discussion). - Perceived **leadership absence**: founder Shaw seen as active on Twitter but absent in Discord; users equate absence with lack of progress (“not building token utility”). - **CEX delistings** surfaced as a trust-breaking event; users perceived “no intervention.” - **Migration execution** (Milady → elizaOS / AI16Z → ELIZAOS confusion) described as “poorly managed,” confusing new investors; some feared old token could trade higher than new. **Scale signal (from provided highlights):** - In the 3/19 discussion summary, token/leadership topics dominated; only **~3 technical Qs** appeared in that channel (faucet, Babylon link, deleting old token), indicating the community’s attention is heavily diverted to token concerns. --- ### 2. Technical Functionality — Eliza Cloud deployment failures & missing Discord plugin module (High severity) **What users reported:** - **GUI deploy failed**, forcing CLI usage (CLI v1.7.2) (3/19 💬-coders). - Docker image build/upload took “significant wait time” with poor progress clarity. - Critical runtime failure: `Cannot find module '@elizaos/plugin-discord'` after configuring Discord plugin via GUI; container became “stuck” with no clear recovery path. - Suspected packaging/monorepo artifact issue: plugin folder possibly missing in `packages` in the deployed container (Odilitime hypothesis). **Impact:** - Blocks a core use case (Discord agents) and creates a “dead-end state” in paid cloud (billing shown ~$1.17/day). --- ### 3. UX/UI — Missing recovery controls & operational visibility in Cloud UI (High frequency within Cloud users) **What users reported:** - No apparent **“reload/restart”** mechanism in the GUI after a bad configuration or stuck container (explicitly asked; unanswered). - Users had to context-switch between GUI and CLI to diagnose issues. - Cost/runway surfaced in CLI output (credits, daily billing, runway ~7 days), but not clearly framed as part of a guided UX flow. --- ### 4. Documentation — Migration clarity, chain/version ambiguity, and “what is supported” questions (Medium–high frequency) **What users reported:** - “Make migration information easier to find” to reduce confusion with old token (3/19). - Repeated unanswered question: **Which Milady version is officially supported (SOL or BSC)?** (3/17; unresolved). - Launch timeline ambiguity for Milady app (“tonight” vs “next week or another week”) created expectation mismatch (3/18–3/19). --- ### 5. Integration — Plugin ecosystem organization & discoverability gaps (Medium frequency, growing) **What users reported:** - Developers building new plugins (moltraffle, Ensoul persistence, unbrowse) want a clearer integration/distribution path. - Proposal for a **Clawhub-style directory** that combines **skills + plugins** in one place (3/17); indicates current registry feels incomplete for discovery. --- ### 6. Technical Functionality / Community Ops — Onboarding automation failures (Low frequency, high friction for new users) **What users reported:** - Google Form role assignment produced **“Invalid Dynamic Link”** errors (3/17). This blocks community access/roles and creates immediate onboarding drop-off risk. - Request for a “ticket channel to talk to an admin” (3/17; unanswered). --- ## 2) Usage Pattern Analysis (Actual vs Intended) ### Observed real-world usage (from feedback) 1. **Agents as Web3 operators**: moltraffle plugin enables on-chain raffles (Base + USDC + Chainlink VRF) and commission-based agent actions (3/19). 2. **Agents as persistent identities**: Ensoul plugin focuses on encrypted decentralized persistence + identity proofs (“ensouled handshake”, “consciousness age”) (3/18). 3. **Agents deployed as always-on services via Eliza Cloud**, especially for Discord use cases; Discord appears to be a primary “first target” integration (3/19 deployment issue). 4. **Ecosystem-first development**: community members are actively shipping plugins and asking how to get them into the official registry (3/17–3/19). ### Mismatch vs intended/marketed usage - Intended: “we’re building (cloud, Babylon, Hyperscape, Milady)” - Actual user discussion: the token’s price action and migration confusion are dominating attention, reducing bandwidth for framework adoption and contributor momentum (3/19). ### Emerging / unexpected use cases - **High-speed agent browsing** (unbrowse: API traversal instead of DOM, claimed 100x speed) suggests demand for “agent-native” browsing primitives rather than human-web automation (3/17). - **Trust metrics for agents** (“consciousness age”) hints at future needs: reputation, identity continuity, verifiable uptime. ### Feature requests aligned with usage - Cloud recovery UX (restart/redeploy), better logs/progress for builds. - Unified discoverability layer for plugins + skills (directory/hub). - Clear integration templates for “browser tools”, persistence layers, and web3 action plugins. --- ## 3) Implementation Opportunities (Concrete fixes; prioritized by impact vs difficulty) ### Pain Point A: Cloud deploy reliability (Discord plugin missing, stuck containers) **Opportunity A1 (High impact / Medium difficulty): Ship a “plugin dependency integrity check” at build time** - Add a preflight step in Cloud build pipeline to verify declared plugins resolve (e.g., `require.resolve('@elizaos/plugin-discord')`) before container starts. - Fail fast with actionable message: “plugin not bundled / not in registry / version mismatch.” **Opportunity A2 (High impact / Low–Medium difficulty): Add GUI “Restart / Rebuild / Roll back to last good config”** - Provide one-click actions: - Restart container - Rebuild image - Revert plugin config to previous working snapshot - Similar patterns: Vercel/Render “Redeploy” and “Rollback”; Kubernetes dashboards expose restart controls. **Opportunity A3 (High impact / Medium difficulty): Standardize plugin packaging for Cloud** - Ensure the production image contains the correct `packages/` artifacts (monorepo workspace install step, lockfile integrity, deterministic build). - Add a “Cloud build manifest” showing included plugins and versions. --- ### Pain Point B: Migration confusion + chain/version ambiguity (Milady SOL vs BSC; old token confusion) **Opportunity B1 (High impact / Low difficulty): Publish a single canonical “Migration & Token FAQ” page and pin it everywhere** - Include: - What contract is current vs legacy - What users should do if they hold old assets - Common misconceptions (“can’t delete old tokens”) - Pin to Discord, link on docs homepage, and in Cloud dashboard. **Opportunity B2 (Medium–High impact / Low difficulty): Add a “Supported Chains / Products” compatibility matrix** - A simple table for Milady (SOL/BSC), Babylon, elizacloud, token utility status, and what’s live vs planned. - Similar patterns: Kubernetes “version skew policy” docs; LangChain provider compatibility tables. **Opportunity B3 (Medium impact / Medium difficulty): Create a “What we shipped this week” changelog with proof links** - Weekly Discord post with GitHub PR links, release tags, and demos. - Addresses “Twitter active, Discord absent” perception by moving progress reporting into the community’s primary venue. --- ### Pain Point C: Plugin ecosystem discoverability (skills + plugins fragmented) **Opportunity C1 (High impact / Medium difficulty): Build a unified registry UI (plugins + skills)** - Extend `elizaos-plugins/registry` into a browsable portal: - categories (Web3, persistence, comms, browsing) - install snippets - compatibility badges (Cloud-ready, version constraints) - Similar patterns: Home Assistant add-on store; VS Code marketplace metadata and categories. **Opportunity C2 (Medium impact / Low difficulty): Add “submission templates” and CI checks for registry PRs** - Enforce required metadata: - actions list, env vars, supported chains, example config - Reduces back-and-forth and improves quality for new submissions (e.g., moltraffle PR). --- ### Pain Point D: Onboarding/ops friction (role form broken; no admin ticket path) **Opportunity D1 (Medium impact / Low difficulty): Fix Google Dynamic Link configuration and add a backup role-claim flow** - Provide fallback: manual command (`/verify`) or OAuth-based verification if link fails. - Similar patterns: Discord servers commonly use dual flows (link + slash command). **Opportunity D2 (Medium impact / Low difficulty): Add a #support-tickets channel or GitHub Discussions intake** - Users explicitly asked for a ticket channel (3/17); unanswered requests compound frustration. --- ## 4) Communication Gaps (Expectation vs reality) ### Repeating expectation mismatches - **Launch timing ambiguity**: “Milady launching tonight” vs “next week or another week” created confusion (3/18–3/19). - **Buyback/tokenomics uncertainty**: “that’s the plan, idk yet” read as non-committal during a crisis (3/18). - **Cloud UX expectations**: users expect GUI deploy to work and to include basic recovery controls (restart/reload); instead they had to switch to CLI and still got stuck (3/19). ### Recurring questions indicating doc/onboarding gaps (unanswered or repeatedly asked) - “Which Milady version is supported (SOL or BSC)?” (3/17; unresolved) - “When will Milady app be online?” (3/19; unresolved in that thread) - “Is there a way to reload the container through GUI?” (3/19; unanswered) - “Why is role assignment link invalid?” (3/17; unresolved) ### Specific improvements - Add a **“Known Issues”** section for Eliza Cloud (Discord plugin packaging, build times, troubleshooting). - Add a **“Release readiness”** checklist post before launches (what’s shipping, what might slip, where updates will be posted). - Provide a **single escalation path** (support tickets) for deployment blockers. --- ## 5) Community Engagement Insights ### Power users / key contributors observed - **Odilitime**: primary responder; also implementing framework refactors (plugin naming standardization) and offering to reproduce Cloud issues. - **Stan ⚡**: plugin ecosystem guide; directed moltraffle to PR into registry. - **Moltraffle**: shipped a full-featured on-chain raffle plugin with clear action surface area. - **DiamondRock (JD)**: shipped Ensoul persistence plugin with docs/explorer/GitHub; offering free tier for first 100 agents. - **lekt9**: building unbrowse (agent browser), seeking integration guidance—potential strategic integration partner. ### Newcomer friction signals - Role assignment failing (“Invalid Dynamic Link”). - Users asking for a ticket/admin channel. - Confusion about what is “official” (Milady chain support, migration status, where Babylon resources are). ### Converting passive users to contributors - Create “Good first plugin” templates (skeleton repo + CI) and highlight weekly “community plugin of the week.” - Run a monthly “Registry Review Day” where maintainers live-review PRs and help with packaging/testing. - Incentivize with recognition (release notes credits) rather than token promises, given current trust climate. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness (from provided data) - Discord produces high-volume sentiment but becomes dominated by token panic during volatility, reducing signal for product UX. - Some critical issues remain unanswered in-thread (reload via GUI, Milady chain support, role form error), suggesting insufficient triage/ownership. ### Improvements for more structured, actionable feedback 1. **Weekly structured check-in (as Jin proposed) with tags** - Deployment (Cloud), Plugin Dev, Docs, Token/Migration, Onboarding - Require: repro steps + screenshots/logs for Cloud issues. 2. **GitHub issue templates for Eliza Cloud** - Include CLI version, plugin list, build logs, expected vs actual, account quota/credits snapshot. 3. **Discord “/bug” command that creates a pre-filled GitHub issue** - Similar to how some open-source projects bridge Discord → GitHub to prevent loss of technical details. ### Underrepresented segments - **Non-crypto builders** (using WhatsApp/Gmail/N8N from prior weekly summary) are absent in the latest Discord snapshots—likely not engaging due to token noise. - **Production Cloud users** beyond a single deployment story (Jin) are missing; need broader telemetry and surveys. --- ## Prioritized High-Impact Actions (Next 2–4 weeks) 1. **Fix Eliza Cloud’s Discord plugin packaging/import failure + add preflight dependency checks** (unblocks core deployment path; highest product impact). 2. **Add Cloud GUI recovery controls (Restart/Rebuild/Rollback) + clearer build progress/log streaming** (prevents “stuck and paying” situations; reduces support burden). 3. **Publish and pin a canonical Migration/Token FAQ + Milady chain support matrix** (reduces repeated confusion; restores baseline trust). 4. **Stand up a unified support intake (ticket channel + GitHub templates) and enforce triage ownership** (reduces unanswered questions and community frustration). 5. **Improve plugin ecosystem discoverability (registry metadata + early directory UI plan)** to match how developers are actually adopting elizaOS (plugins first, then platform).