## User Feedback Analysis — 2026-03-21 ### Data sources covered - Discord discussions and coder support threads (2026-03-18 to 2026-03-20) - Referenced GitHub repos/issues/PRs mentioned in chat (e.g., milady-ai/milady; elizaOS plugin registry submission guidance) --- ## 1) Pain Point Categorization (Top recurring 5–7) ### 1) **Community — Trust/communication + token utility anxiety (highest frequency & severity)** **What users are reporting** - Strong frustration with **token performance and perceived lack of utility**, often framed as an existential risk to the project. - Perceived **leadership absence in Discord** and “defensive” posture toward investor concerns. - Confusion about **what partnerships (e.g., Babylon) concretely do** for ElizaOS tokenomics beyond announcements. **Evidence / volume (from provided feedback)** - At least **6+ distinct users** raised concerns about token performance/utility/leadership comms across Mar 18–20 (e.g., gby, VirginVanDijk, elizasib, Taco, Alexei, Matthib123). This was the dominant theme in 💬-discussion. --- ### 2) **Technical Functionality — ElizaCloud deployment failures & missing modules** **What users are reporting** - Deployment via GUI failing; forced to use CLI. - Post-config deployment failing with: **“Cannot find module '@elizaos/plugin-discord'”** (container gets stuck). - Missing operational controls in cloud UI (e.g., **no visible “reload container”**). **Evidence** - Repeated troubleshooting around ElizaCloud + CLI **v1.7.2** deployment failure and plugin resolution problems (jin ↔ Odilitime, Mar 19). --- ### 3) **Integration — Plugin packaging/registry consistency issues (naming + availability)** **What users are reporting** - Plugin resolution issues (Discord plugin not found) suggest **packaging/monorepo publish or bundling gaps**. - Recent plugin renames (plugin-form vs plugin-forms) reduce confusion long-term, but increase short-term mismatch risk between docs, registry, and user projects. **Evidence** - Framework refactor: plugin naming standardization (Mar 18). - Production symptom: `@elizaos/plugin-discord` missing at runtime (Mar 19). --- ### 4) **Technical Functionality — Artifact integrity & release verification friction (GPG/SHA256)** **What users are reporting** - **GPG key and SHA256 checksum problems** in Milady repo releases, blocking trust in downloads and “marketing-ready” distribution. **Evidence** - Jin created/flagged issues in milady-ai/milady; called out GPG/SHA256 problems (Mar 20). --- ### 5) **UX/UI — Cloud UX gaps (progress visibility, failure states, recoverability)** **What users are reporting** - Users can’t tell whether long build/upload stages are normal vs broken. - When deployments fail, users lack **self-serve recovery** (restart/reload/rollback) in UI. **Evidence** - “Docker image build taking so long” confusion; container stuck; no reload in GUI (Mar 19). --- ### 6) **Documentation — Migration + “where do I start” confusion (especially for investors/newcomers)** **What users are reporting** - Migration execution described as confusing; request to make migration info “easier to find.” - Recurring questions about timelines (Milady, Hyperscape), and basic how-to questions (coin faucet). **Evidence** - Migration info request (Matthib123, Mar 19). - Multiple “when launch?” questions with uncertain answers (Mar 18–20). - Coin faucet question left unanswered (Mar 19). --- ### 7) **Performance/Operations — Large image uploads failing (disk image not received server-side)** **What users are reporting** - Disk image upload sent but **never arrives** at server; root cause unknown. **Evidence** - Odilitime ↔ jin investigation; “no image received,” stack is elizaos 1.x CLI + elizacloud (Mar 20). --- ## 2) Usage Pattern Analysis (Actual vs intended usage) ### Observed real-world usage (from feedback) - **Trading/market agents**: users explicitly ask if others build trading agents; Babylon positions itself as a market simulation with agent-driven research/trades/predictions. - **On-chain automation & Web3 primitives as “actions”**: Moltraffle plugin (Base) exposes concrete action set (LIST/GET/JOIN/CREATE/DRAW), using USDC + Chainlink VRF. - **Agent identity & persistence** emerging as a major theme: - Ensoul persistence plugin: encrypted decentralized storage + identity handshake + “consciousness age.” - Community-proposed “agentic identity protocol” (Z1N). ### Mismatch vs intended/expected usage - Users are treating ElizaCloud as a **productized PaaS** (with expected reliability, debugging tools, and rollback controls), not as an early-stage dev platform. - Community expects token utility to be **immediately legible and measurable** (buybacks, revenue linkage, clear mechanisms), not “planned.” ### Feature requests aligned with usage - **Cloud operational controls**: restart/reload/rollback, logs, status, plugin dependency verification. - **Standardized plugin action schemas** (as seen in Moltraffle) to accelerate “agent as API client” patterns. - **Identity + persistence primitives** (Ensoul, SAID-like concepts, Z1N proposal) packaged as first-class patterns/templates. --- ## 3) Implementation Opportunities (2–3 concrete solutions per major pain point) ### A) Trust/communication + token utility anxiety (Community) 1) **Publish a “Token Utility & Flows” living document** (high impact, low–medium difficulty) - One page showing: ElizaCloud revenue → treasury routing → buyback triggers → reporting cadence; Babylon airdrop mechanics; what is live vs planned. - Include “known unknowns” to reduce speculation. 2) **Set a fixed comms cadence with named owners** (high impact, low difficulty) - Weekly Discord post + monthly roadmap review; “what shipped / what broke / what’s next.” - Ensure more than one team voice (reduce single-point-of-failure perception around Odilitime). 3) **Introduce measurable on-chain/off-chain reporting** (medium impact, medium difficulty) - Public dashboard: buyback events, cloud revenue aggregates (even bucketed), airdrop status, deployment uptime. - Comparable approach: many infra projects use lightweight “status + metrics” pages to reduce rumor-driven support load. --- ### B) ElizaCloud deployment failures & missing modules (Technical Functionality / Integration) 1) **Preflight dependency check before deploy** (high impact, medium difficulty) - Validate plugin imports (`@elizaos/plugin-discord`, etc.) against the build context and registry before container build. - Fail fast with actionable remediation (“plugin not included in image; add to packages or enable plugin bundle”). 2) **Make plugin bundling explicit and deterministic** (high impact, medium–high difficulty) - Pin plugin versions; generate a lockfile manifest for deployed images. - Ensure monorepo packaging publishes all required artifacts and that the runtime image contains them. - Comparable approach: frameworks like Next.js/Vercel ecosystems emphasize reproducible builds + lockfile determinism for deploy parity. 3) **Cloud UI “recoverability” controls** (high impact, medium difficulty) - Add: Restart container, Rebuild, Rollback to previous image, “Redeploy last known good.” - Pair with prominent “View build logs / runtime logs.” --- ### C) Cloud UX gaps: progress visibility & failure states (UX/UI) 1) **Progress stages + expected durations** (medium–high impact, low difficulty) - UI states: “Building image (3–10 min typical) → Uploading (size-dependent) → Starting container → Health check.” 2) **Actionable error surfacing** (high impact, medium difficulty) - Parse common failures (module not found, registry auth, quota) into human-readable fixes. 3) **Self-serve diagnostics bundle** (medium impact, medium difficulty) - “Download debug report” (logs + manifest + config redactions) to attach to GitHub issues. --- ### D) Artifact integrity: GPG/SHA256 release verification (Technical Functionality) 1) **CI-enforced release signing + checksum generation** (high impact, medium difficulty) - GitHub Actions: generate SHA256SUMS; sign with maintained release key; attach artifacts to releases. 2) **Document “How to verify downloads” with copy/paste commands** (medium impact, low difficulty) - Provide OS-specific steps; clarify what “good” looks like. 3) **Key continuity policy** (medium impact, medium difficulty) - Publish key rotation policy + key provenance to avoid repeated trust breaks. --- ### E) Documentation gaps: migration, timelines, onboarding (Documentation / Communication) 1) **Migration “front door” doc** (high impact, low difficulty) - Single canonical page: what changed, which token/contracts are current, where to trade, how to verify, FAQs. 2) **Launch status pages for Milady/Babylon/Hyperscape** (high impact, low difficulty) - Replace “ready when ready” with: current phase, blocking issues, and what “done” means (even if no dates). 3) **Answer-bank for recurring questions** (medium impact, low difficulty) - Coin faucet, building trading agents, plugin submission steps, cloud deploy troubleshooting. --- ### F) Disk image upload not received (Performance/Operations) 1) **Add server-side upload receipt + correlation IDs** (high impact, medium difficulty) - Client prints upload ID; server confirms receipt + stores metadata; UI shows last-seen. 2) **Size limits + resumable uploads** (medium impact, medium–high difficulty) - Use chunked/resumable upload protocol; clearly state max size and supported formats. 3) **Automated canary uploads in CI/monitoring** (medium impact, medium difficulty) - Detect regressions early (upload path breaks become visible before users report). --- ## 4) Communication Gaps (Expectations vs reality) ### Gap: “Product-grade cloud” expectations vs “early infra” reality - Users expect GUI deploy to “just work,” plus operational controls (restart/reload/rollback). Current experience includes stuck containers and opaque failures. **Fix** - Set expectation tiers: “Preview / Beta / Stable,” per feature (deploy UI, plugin marketplace, registry sync). ### Gap: Token utility messaging vs concrete mechanisms - Users repeatedly ask “what benefit does Babylon bring” and “is there buyback,” indicating messaging isn’t landing or lacks specifics. **Fix** - Publish concrete mechanism diagrams + what is already implemented vs planned; include timelines as phases if dates aren’t possible. ### Gap: Release readiness and timelines - “Ready when ready” amplifies uncertainty; users interpret delays as stalled progress. **Fix** - Provide milestone-based progress (definition of done + current blockers), even without dates. ### Recurring questions that signal onboarding/documentation gaps - Milady status/timeline (asked multiple days) - How to deploy reliably (GUI vs CLI, logs, plugin availability) - Migration clarity for newcomers/investors - Basic web3 integration how-tos (coin faucet) --- ## 5) Community Engagement Insights ### Power users / high-leverage contributors observed - **jin**: actively deploying, reporting reproducible infra issues (module missing, GUI limitations); ideal for beta feedback loops. - **Moltraffle**: shipping concrete plugins with well-defined action surfaces; could become a “reference plugin” maintainer. - **DiamondRock (JD)**: advanced persistence/identity plugin; needs tight integration guidance and validation path. - **Z1N**: proposing new identity protocol concepts; could be channeled into an RFC process. - **Peace**: offers full-stack Web3/AI services; potential contributor if given scoped bounties. ### Newcomer friction patterns - “When launch?” and “does X benefit Y?” questions dominate, suggesting onboarding currently routes people into speculation rather than product experimentation. ### Converting passive users into active contributors - Create **small, labeled “good first issue”** tasks tied to current pain (cloud UI reload, better error messages, migration doc PRs). - Add a **plugin submission fast-lane**: template repo + checklist + automated validation. - Run **weekly office hours** focused on: Cloud deploy debugging, plugin publishing, and “agent trading examples.” --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - Discord is producing rapid sentiment signals but **low structure** (hard to turn into reproducible tickets). - Some issues do become actionable (e.g., plugin-discord missing, GPG/SHA issues), but often lack standardized repro data. ### Improvements to gather structured, actionable feedback 1) **Weekly “Deploy & Plugin” feedback form** (5–8 fields) - CLI version, cloud project ID, plugin list, error text, logs link, expected outcome. 2) **GitHub issue templates** for: - Cloud deployment failures (with manifest + logs checklist) - Plugin runtime resolution problems - Release artifact integrity problems (checksum/signature fields) 3) **In-product feedback hooks (ElizaCloud UI)** (where possible) - “Report this deployment failure” button that auto-attaches anonymized diagnostics. ### Underrepresented segments - **Non-crypto / non-token** users: feedback heavily dominated by token sentiment; needs more input from teams using ElizaOS for integrations (WhatsApp/Gmail/n8n patterns hinted in earlier weekly summary, but not present in this day’s feedback). - **Production deployers** beyond a few individuals: broaden by recruiting 10–20 “deployment testers” with a standard checklist. --- ## Prioritized High-Impact Actions (Next 2–4 weeks) 1) **Fix ElizaCloud deploy reliability loop**: preflight dependency checks + clear logs + UI restart/redeploy controls (addresses stuck containers and missing plugin modules). 2) **Publish a canonical “Token Utility & Babylon/Buyback Mechanism” page** with status (live vs planned) + update cadence (reduces highest-severity community anxiety). 3) **Ship CI-backed release integrity** for Milady artifacts (GPG + SHA256 automation) and document verification steps. 4) **Create a single migration “front door” doc + FAQ**, and pin it in Discord/GitHub (reduces repeated confusion for newcomers/investors). 5) **Stand up a lightweight RFC + plugin validation pipeline** (for identity/persistence proposals and new plugins like Moltraffle/Ensoul), turning community energy into mergeable contributions.