## User Feedback Analysis — 2026-02-01 (based on 2026-01-29 to 2026-01-31 data) ### Data snapshot (what we analyzed) - Sources present: Discord (💬-discussion, 💬-coders, core-devs) across **3 daily logs** (Jan 29–31), plus weekly/monthly GitHub summaries. - High-signal threads: token migration + scams, ElizaCloud/A2A integration failures, plugin/dev workflow breakages, strategic product direction (Babylon/TEE), and token utility/transparency debates. --- ## 1) Pain Point Categorization (Top recurring issues) ### 1) Technical Functionality — **Integration breakages & correctness bugs** (high frequency, high severity) Observed in **2/3 days (≈67%)** with concrete stack traces + in GitHub summaries (setup stability work). - **ElizaCloud MCP integration fails despite “auth success”** due to: - `isomorphic-dompurify` module loading error (CommonJS/ESM mismatch) when connecting OpenClaw agent → ElizaCloud MCP app (reported by **DorianD**, Jan 31). - `contentModerationService` function errors in `A2A message/send` endpoint (Jan 31). - **Core framework behavior bug**: Eliza **1.7.2** action callbacks execute in reverse order and omit structured return text, breaking custom plugin flows (reported by **Victor Creed**, Jan 29). - **Provider selection bug** in develop branch for one-shot mode (reported by **Odilitime**, Jan 30). - **Plugin install/module resolution issues** (e.g., “Cannot find module `@elizaos/plugin-web-search`”) requiring manual `package.json` edits (Jan 29). **Most affected users** - Builders integrating external agents/services (OpenClaw ↔ ElizaCloud; plugin developers; anyone on develop branch). --- ### 2) Integration — **Auth + cross-platform interoperability friction** (medium-high frequency, high severity) Observed in **2/3 days (≈67%)**. - **CLI login requires browser flow**; request for **API-token-only CLI auth** (DorianD, Jan 31). - Push to interoperate with **Moltbook/ClawHub/OpenClaw skills**: - Users want to “download any skill from clawhub and integrate it into elizaos” (DigitalDiva, Jan 31). - Team building `plugin-cskills` and exploring **Composio** for social authentication / connection page redirect flow (Jan 29). **Most affected users** - Power users running agents headlessly (VMs, servers), and teams wanting OAuth/social integrations without bespoke work. --- ### 3) Documentation — **Migration, A2A, and “what is the product” clarity gaps** (high frequency, medium-high severity) Observed in **3/3 days (100%)** as recurring questions. - **A2A docs are discoverable only via direct link** (shared: https://www.dev.elizacloud.ai/docs/a2a), implying discoverability/onboarding issues (Jan 31). - **Token migration confusion**: - “0 eligible” despite holding tokens since 2024 (Jan 30). - Bridging/migrating from ETH chain when liquidity is near-zero / conversion causes massive loss (98% loss report, Jan 29). - Rate limiting errors (“429 Too many requests”) on migration portal page load (Jan 30). - Repeated requests to “break down” the value proposition more simply (Odilitime noted communication challenge, Jan 30). **Most affected users** - Newcomers and token holders trying to migrate; developers trying to adopt A2A/ElizaCloud without tribal knowledge. --- ### 4) Community + Security — **Scams impersonating support; unsafe support surface area** (high frequency, very high severity) Observed in **2/3 days (≈67%)**, with multiple incidents. - Users reported **fake support DMs**, friend requests, and seed phrase requests tied to migration (Jan 30–31). - One user reported being hacked after generating a support ticket (coolart, Jan 30). - Community moderation prevented at least one seed-phrase compromise (Maff || Hourglass ⌛ intervened for Risto, Jan 31). **Most affected users** - Newcomers, token migrators, and anyone seeking support via tickets/DMs. --- ### 5) UX/UI — **ElizaCloud perceived as “unfit beta”; trust erosion from product polish gaps** (medium frequency, high severity) Observed in **1/3 days (≈33%)**, but strong sentiment. - Users criticized **elizacloud.ai** for launching in an “unfit beta state” and pointed to “half-completed code releases” and missing end-to-end utility (averma, yojo, Jan 31). **Most affected users** - Evaluators and prospective adopters deciding whether to build on ElizaCloud vs alternatives. --- ### 6) Community / Product Economics — **Token utility + transparency concerns** (high frequency, high severity) Observed in **3/3 days (100%)**. - Repeated questions about: - **40% team allocation**, vesting, wallet disclosure, sales/dumps (Jayzen, averma, Jan 29–31). - Why ElizaCloud accepts **cash/crypto payments but no token use case** (Jan 31). - Runway concerns: **6–8 months** mentioned (Jan 30–31), plus questions whether runway is in stables. **Most affected users** - Token holders, community investors, and builders whose willingness to contribute depends on trust and clarity. --- ### 7) Performance / Reliability — **Release stability + testing deficits** (medium frequency, medium-high severity) Observed in **1/3 days (≈33%)**, plus reinforced by weekly GitHub focus on onboarding stability. - “Recurring breakages” in monorepo versions; need better integration tests (Odilitime, Jan 30). - Plugin-n8n test framework effort proposed as pattern (Stan ⚡, Jan 30). **Most affected users** - Plugin developers, contributors working across multiple packages, and anyone upgrading versions. --- ## 2) Usage Pattern Analysis (actual vs intended use) ### How users are actually using ElizaOS - **As an extensible agent runtime + plugin ecosystem**, often in headless/VM environments: - Confirmed assumption that agents run on **VMs/old computers** (Jan 31). - High interest in pulling “skills” from external ecosystems (ClawHub/OpenClaw) into ElizaOS. - **As infrastructure for multi-agent + routing experimentation**: - “ElizaRouter” concept to route prompts/models across nodes with QoS/time decay (Jan 29). - **As a bridge across agent social platforms**: - Strong pull toward **Moltbook exposure** and Babylon as an “agent social media” surface (Jan 30–31). ### Intended usage (implicit from team discussions) - Move toward a consumer-ready “Eliza App” footprint (“on your phone and secure”) and **TEE-hosted** agent experiences (core-devs, Jan 31). - ElizaCloud as a smoother onramp to hosted agent execution + A2A messaging. ### Emerging / unexpected use cases - **Cross-framework skill portability** (OpenClaw skills ↔ ElizaOS via plugin-cskills) is becoming a primary adoption vector, not just a nice-to-have. - **Agent shell access + personal API keys** is viewed as a normal capability now (Jan 31), increasing demand for security posture, permissioning, and auditing. ### Feature requests aligned to real usage - **API-token-only CLI authentication** (fits headless usage and CI). - **First-class “connection page” / OAuth account linking** and composable integrations (Composio). - **Voice + mobile footprint** requests surfaced via competitor comparison (Clawdbot) (Jan 30). --- ## 3) Implementation Opportunities (solutions per major pain point) ### A) ElizaCloud integration failures (CJS/ESM + A2A endpoint errors) **Highest impact / moderate difficulty** 1) **Standardize module format in ElizaCloud deployment** - Add a build-step to externalize or bundle problematic deps (e.g., `isomorphic-dompurify`) and pin compatible versions. - Add CI checks that run Node in the same module mode as production (ESM) and execute a minimal MCP smoke test. - *Comparable approach*: Next.js/Vite ecosystems commonly resolve this by dependency pre-bundling and explicit `exports`/interop configuration. 2) **Contract-test A2A endpoints** - Create a small “A2A conformance suite” that posts `message/send` and asserts expected response schema + moderation hooks. - Run nightly against staging. - *Comparable approach*: Slack/Discord bot SDKs often ship “API schema + fixture tests” to prevent silent breakages. 3) **Improve error surfaces** - Return structured error codes for MCP app connection failures (“MODULE_LOAD_ERROR”, “MODERATION_SERVICE_MISSING”) with remediation links. - Reduce Discord support load by making failures self-diagnosable. --- ### B) Core framework correctness bug (Eliza 1.7.2 callback ordering + missing structured return) **Highest impact / moderate difficulty** 1) **Add a regression test that asserts message ordering** - Given an action callback that emits 3 messages, assert the final transcript ordering + presence of structured return. - Gate releases on this test. 2) **Publish an official “callback contract”** - Define guaranteed ordering semantics and what “structured return” means for downstream plugins. - *Comparable approach*: LangChain/LlamaIndex document callback lifecycles and add versioned behavioral guarantees to reduce plugin breakage. 3) **Ship a hotfix + migration note** - Provide a short workaround snippet for plugin authors until patch lands (e.g., “buffer then flush in order”). --- ### C) Migration UX + portal reliability (“0 eligible”, 429 errors, ETH liquidity traps) **Highest impact / moderate difficulty** 1) **Add deterministic eligibility diagnostics** - On the portal, show *why* a wallet is ineligible (snapshot block, wallet mismatch, LP position, acquired after snapshot). - Provide a “check another address” flow and a “how to prove ownership” flow for Ledger users. 2) **Rate-limit gracefully** - Fix the “429 on page load” by adding caching/CDN, exponential backoff, and moving expensive eligibility checks behind a user action. - Provide a status page for migration services. 3) **Publish “don’t swap, migrate” warnings** - Prominent banner: swapping on low-liquidity pools can cause catastrophic loss; use official migration/bridge path. - *Comparable approach*: Many token migrations (e.g., major L2/token bridges) add in-app warnings when users are about to interact with unsupported liquidity routes. --- ### D) Scam pressure + unsafe support expectations **Highest impact / low-to-moderate difficulty** 1) **Make “support never DMs” unavoidable** - Auto-post warning in all migration-related channels every N minutes during peak periods. - Add it to the ticket creation flow and portal UI. 2) **Verified-support workflow** - Use a single official support bot account; all staff responses originate from that bot (case comments relayed). - Require signed, verifiable links (e.g., Discord server-signed shortlinks) rather than raw URLs. 3) **Security playbook + incident reporting** - Publish a one-page “If you were scammed” guide and a “report impersonation” button. - *Comparable approach*: Crypto wallets/exchanges prominently use signed domains, in-product warnings, and a “verified accounts” directory. --- ### E) Release stability + testing gaps (monorepo + plugins) **High impact / moderate difficulty** 1) **Adopt a standard monorepo release discipline** - Use Changesets (or equivalent) + automated canary releases for develop branch. - Run integration tests across top plugins (twitter, sql, n8n, openai, bootstrap). 2) **Template test harness for plugins** - Productize Stan ⚡’s plugin-n8n-workflow testing pattern into `@elizaos/plugin-testkit`. - *Comparable approach*: VS Code extensions and popular SDK ecosystems provide official test scaffolds to reduce ecosystem breakage. --- ### F) Token utility + transparency trust gap **High impact / moderate difficulty (coordination-heavy)** 1) **Publish a transparency page** - Team wallet addresses, vesting schedule, unlock timeline, and periodic attestations. 2) **Clarify token utility by product surface** - Table: “Where token is used today” (Jeju gas placeholder vs real), “planned”, “not planned.” 3) **Close the loop on ElizaCloud payments** - If token utility is planned: publish scope + timeline. - If not: clearly say so and explain why. - *Comparable approach*: Successful open-source/crypto hybrids often maintain a living “token policy + treasury reporting” page to reduce rumor-driven churn. --- ## 4) Communication Gaps (expectations vs reality) ### Recurring expectation mismatches - **“Auth success” but integration still fails** → users interpret as misconfigured credentials; actually a server-side module/runtime issue (ElizaCloud MCP). - **“ElizaCloud is usable” vs “beta is unfit”** → mismatch between launch messaging and actual reliability. - **Token utility expectations**: - Users expect token to be usable in ElizaCloud today; reality: payments are cash/crypto via third parties (Jan 31). - **Migration safety**: - Some users attempt swaps/bridges via public liquidity and suffer extreme losses; they expected a safe off-ramp. ### Recurring questions indicating doc/onboarding gaps - “Where is the documentation for the A2A protocol?” (Jan 31) - “Why does my wallet show 0 eligible?” (Jan 30) - “How do I migrate across networks?” (Jan 31) - “Is support DMing me real?” (Jan 30–31) - “Why isn’t Eliza doing what Clawd is doing?” (Jan 31; positioning clarity) ### Suggested documentation improvements - Create a single “Start Here” map for: - **ElizaOS (framework)** vs **ElizaCloud** vs **Jeju** vs **Babylon/Hyperscape** - Add “Known Issues” pages: - ElizaCloud MCP/A2A known errors + fixes - Migration portal troubleshooting decision tree - Add “Security & Support” page linked everywhere migration is mentioned. --- ## 5) Community Engagement Insights ### Power users (and what they need) - **DorianD**: deep integrator (OpenClaw ↔ ElizaCloud), product strategist (Moltbook), wants API-token CLI auth, mobile/voice parity. - **Odilitime**: builder across plugins + token/product messaging; wants stability (tests), clearer comms, and ecosystem integrations. - **Stan ⚡**: working on plugin testing frameworks and Composio integration artifacts (plugin + RFC). - **averma**: represents investor/community trust concerns; asks for wallet/vesting disclosure and token utility integration. - **Agent Joshua ₱ | TEE / puncar / s**: shipping-oriented focus on Babylon in TEE with parallel workstreams. **What would unlock more contribution** - A clear list of “high-leverage, well-scoped” issues (e.g., A2A conformance tests, CLI token auth, plugin testkit). - Faster maintainer feedback loops on PRs affecting onboarding and integration reliability. ### Newcomer friction signals - Migration portal confusion (“0 eligible”, 429s). - Support scam exposure (friend requests, fake tickets). - Plugin installation/module resolution errors requiring manual edits. ### Converting passive users into active contributors - Create a “Migration helpers” program (scripted responses + badge/role), since migration support is currently high volume. - Offer a monthly “Integration Jam” focused on: Composio/social connections, Moltbook/ClawHub skill import, and ElizaCloud MCP hardening. - Reward doc contributions explicitly (bounties or recognition), since many issues are doc-discoverability rather than deep code changes. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** is effective for rapid troubleshooting and scam interception, but issues are noisy and solutions are not durable (answers get buried). - **GitHub** shows strong engineering throughput (onboarding fixes, security protocol, plugin development), but user-impact metrics are not consistently captured (e.g., how many affected by each bug). ### Improvements for more structured, actionable feedback 1) **Add a “Report a bug” form that generates a GitHub issue** - Required fields: version, environment (Node/bun, ESM/CJS), logs, reproduction, expected vs actual. 2) **Create a weekly “Top Support Issues” rollup** - Convert Discord FAQs (migration/scams/A2A) into a single pinned digest + docs updates. 3) **Add lightweight in-product telemetry (opt-in) for ElizaCloud** - Count MCP connect failures by error code (module load, moderation service, auth). - This enables real quantification instead of anecdotal severity. ### Underrepresented segments (missing feedback) - **Non-crypto mainstream users** (explicitly referenced as competitor advantage): little direct feedback from this segment. - **Mobile-first users**: discussed as a strategic need, but minimal direct user testing evidence. - **Enterprise/teams**: interest implied via broker auth and n8n workflows, but feedback is mostly from individual builders. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1) **Stabilize ElizaCloud MCP + A2A reliability**: fix `isomorphic-dompurify` ESM/CJS issue, patch `contentModerationService` errors, and add an A2A conformance smoke test in CI. 2) **Ship a security-first support posture for migration**: portal + Discord banners, verified-support workflow, and a single canonical “Support never DMs” + “safe migration path” page. 3) **Fix and regression-test the Eliza 1.7.2 callback ordering/structured return bug** (high downstream impact on plugin authors). 4) **Reduce migration confusion with eligibility diagnostics + portal hardening** (429 mitigation, explicit reasons for “0 eligible”, and warnings against low-liquidity swaps). 5) **Publish a transparency + token utility status page** (team wallets/vesting, runway clarity at a high level, and explicit ElizaCloud token utility plan or non-plan) to reduce trust churn and repeated debate.