## User Feedback Analysis — 2025-12-29 (covering feedback observed 2025-12-26 to 2025-12-28) **Data basis & quantification method:** This analysis is derived primarily from Discord discussions (💬-discussion, core-devs) plus referenced GitHub context (notably the open migration-related issue #6211). Percentages below are calculated from **12 distinct user-reported problem threads/questions** identifiable in the provided dataset (some threads include multiple users reporting the same problem). --- ## 1) Pain Point Categorization (Top recurring 5–7) ### 1) Token migration eligibility + wallet support failures (Category: **Integration / Technical Functionality**) — **6/12 threads (~50%)** **What users reported (examples):** - “**max amount reached**” error (Emma; also asked by yikesawjeez). In Discord, staff clarified it often means **wallet not in snapshot** (Odilitime). - Tokens visible but **not exchangeable** after connecting **Phantom** (Fataliti; similar wallet-connection confusion from Tengev). - Migration UI appears “**Ledger-only**” / unclear how to proceed for other wallets (Бизнес Гусь). - GitHub issue **#6211**: Snapshot-eligible tokens held in **Tangem** can’t be migrated because portal connection method doesn’t support Tangem; user also reports **impersonators** in Discord support. **Impact:** High severity (users blocked from completing migration; high financial/emotional stakes). --- ### 2) Identity/affiliation confusion: “by elizaOS” vs official projects (Category: **Community / Documentation**) — **2/12 threads (~17%)** **Examples:** - “Is **Zora** officially from elizaOS like Spartan?” → clarified as **not official** (Diamondhandwhiteboy). - Ongoing confusion around projects labeled “**by elizaOS**” and what that implies (dududon1). **Impact:** Medium-to-high (trust/brand risk; increases support burden; fuels scam surface area). --- ### 3) Agent creation edge cases causing client exceptions (Category: **UX/UI + Technical Functionality**) — **1/12 threads (~8%)** **Example:** - Agent names like **"null"** or numeric strings (**"1", "69", "666"**) don’t save or cause client-side exceptions; “$” works (DorianD). **Impact:** Medium (blocks some users; signals missing validation/sanitization, potential security concerns). --- ### 4) Cloud marketplace expectations: SLA, reliability, and positioning (Category: **Documentation / Integration**) — **1/12 threads (~8%)** **Example:** - “Do you offer **SLAs**?” → Shaw: “I do not, but providers can.” - Users are hearing a strong value proposition (e.g., “**40% reduction in cloud bills**”) but have unclear guarantees. **Impact:** Medium (enterprise/pro users need clarity; risk of misaligned expectations). --- ### 5) Onboarding friction: “Where are the API endpoints?” / “How do I deploy?” (Category: **Documentation / UX**) — **1/12 threads (~8%)** **Example:** - Request for clearer access to **Eliza Cloud API endpoints** (“They’re there on the site” — Odilitime, but discoverability is low). **Impact:** Medium (slows builder adoption; increases repeated questions). --- ### 6) Streaming/multistep chat UX inconsistencies (Category: **UX/UI / Performance**) — **1/12 threads (~8%)** **Example:** - Streaming added to a component, but multistep interaction UI looks worse than “**otaku**” (sayonara; Stan ⚡ to investigate). **Impact:** Medium (core interaction quality; affects perceived responsiveness). --- ## 2) Usage Pattern Analysis (actual vs intended) ### How users are actually using elizaOS (observed) 1. **As a deployment platform (ElizaOS Cloud) for agents**, sharing projects and experimenting with themed agents (e.g., marijuana-themed agent mentioned in discussion highlights). 2. **As a Web3-adjacent ecosystem** where token migration, staking, liquidity, and wallet tooling are daily concerns—often overshadowing framework usage. 3. **As an emerging decentralized compute marketplace concept (“Jeju/Babylon”)**—users are evaluating it like a Vercel alternative, asking about SLAs and infra guarantees. 4. **As a builder surface in the dashboard**—users encounter real-world naming/validation edge cases, streaming UX limitations, and login/deploy errors. ### Mismatches vs intended usage (signals) - Intended: “Build agents quickly.” Actual: Many users are stuck at **identity/migration gating**, unable to proceed. - Intended: “Cloud endpoints exist.” Actual: Users ask where endpoints are—**discoverability gap**. - Intended: “Streaming improves responsiveness.” Actual: Streaming exists but **multistep UX** degrades, creating confusion vs baseline experiences. ### Emerging / unexpected use cases - **Trading bots** discussed in partners channel (though details were intentionally obfuscated). - Requests to plug agents into **desktop creative tools** (DaVinci Resolve) indicate appetite for **agent-as-coach / agent-as-copilot** beyond chat. ### Feature requests aligned with observed usage - Better **migration/wallet compatibility** and clearer eligibility checks. - A **project identity system** (“built on elizaos cloud”) for ecosystem distribution and trust. - Streaming UX parity with known-good experiences (“otaku”-like multistep rendering). --- ## 3) Implementation Opportunities (solutions per major pain point) ### A) Migration eligibility + wallet support failures (Integration / Technical Functionality) **High impact / Medium difficulty** 1. **Preflight eligibility checker + explicit error taxonomy** - Replace/augment “max amount reached” with structured reasons: - `NOT_IN_SNAPSHOT`, `AMOUNT_EXCEEDS_SNAPSHOT_BALANCE`, `UNSUPPORTED_WALLET`, `NETWORK_MISMATCH`, `CONTRACT_BLOCKED`. - Show snapshot balance and eligible amount in UI. - Similar pattern: Many airdrop/migration tools (e.g., common “claim” UIs) provide **address status** and **reason codes** before prompting wallet actions. 2. **Wallet-agnostic claim flow** - Add **WalletConnect v2** improvements and/or a **manual signature-based proof** path: - User signs a message with the snapshot wallet (even if it can’t connect natively), submits signature to claim. - Similar approaches are common in “sign to prove ownership” flows used by decentralized identity and airdrop claim systems. **High impact / Higher difficulty** 3. **Support “custody/non-exportable” wallets (Tangem-like) via an official assisted process** - Provide an official GitHub-logged process: user posts address + proof artifacts; maintainers validate and add to a queue. - Crucially: publish a canonical “We will never ask you to send tokens” policy + verification steps. --- ### B) “by elizaOS” vs official affiliation confusion (Community / Documentation) **High impact / Low-to-medium difficulty** 1. **Standardize labels and verification** - Introduce clear public tags: - **Official (elizaOS)**, **Partner**, **Built on elizaOS**, **Community project (unverified)**. - Provide a simple verification badge process (DNS TXT record, GitHub org membership, or signed attestation). 2. **Pinned “Affiliations & Branding” page** - One authoritative doc linked from Discord and the site: - “What does ‘by elizaOS’ mean?” - List official projects (e.g., Spartan) and explicitly list “not affiliated” examples when confusion spikes (e.g., Zora). **Comparable solutions:** Ecosystems like Kubernetes/CNCF and many OSS foundations separate **official**, **sandbox**, **community** projects with standardized registries and badges to reduce brand confusion. --- ### C) Agent naming bug (“null”, numeric strings) causing crashes (UX/UI + Technical Functionality) **Medium impact / Low difficulty** 1. **Server-side validation + reserved words list** - Enforce allowed pattern and reserved list (`null`, `undefined`, empty, purely numeric, etc.). - Return actionable validation errors. 2. **Client-side inline validation** - Real-time feedback in agent creation form; prevent save when invalid; provide suggestions. 3. **Regression tests** - Add tests for edge-case names to prevent reintroduction. **Comparable solutions:** Most developer tools (Vercel, GitHub repo naming, Slack workspace naming) use **client validation + server enforcement + clear error messages**. --- ### D) Cloud marketplace SLA expectations (Documentation / Integration) **Medium impact / Medium difficulty** 1. **Publish an SLA model and capability matrix** - If platform doesn’t offer SLA, document: - What *is* guaranteed (best-effort routing, provider selection logic, etc.) - What is *not* guaranteed (uptime, latency) - How providers can attach SLAs, and how claims/disputes work. 2. **Provider SLA metadata + UI surfacing** - Providers specify uptime %, regions, incident policy; UI shows SLA tier during deployment. 3. **Status page and incident comms** - Even without SLA, a public status page reduces uncertainty and support load. **Comparable solutions:** Cloud marketplaces and PaaS products commonly separate “platform SLA” vs “provider SLA” and surface them at purchase/deploy time. --- ### E) API endpoints discoverability + onboarding friction (Documentation / UX) **Medium impact / Low difficulty** 1. **Single “Start Here” onboarding page** - “Create → Get API key → Find endpoints → Deploy → Monitor.” - Include copy-pastable curl examples and SDK snippets. 2. **In-product “API” panel** - A dashboard tab showing: - Base URL, endpoints list, auth method, example requests, and current key. **Comparable solutions:** Stripe/PostHog-style dashboards embed “quickstart” panels with live keys and examples. --- ## 4) Communication Gaps (expectations vs reality) ### Repeated expectation mismatches 1. **Migration UI language vs actual rules** - Users interpret “max amount reached” as a numeric cap or bug; reality: often “wallet not in snapshot” or “post-snapshot purchases not eligible.” - Fix: rename errors and display eligibility context *before* users attempt migration. 2. **Official vs ecosystem projects** - Users assume “by elizaOS” implies endorsement; reality: many are unaffiliated/community. - Fix: verification/badges + pinned explainer + consistent staff phrasing. 3. **Cloud marketplace reliability** - Users hear “Vercel alternative” and cost reduction claims, then ask for SLAs; reality: SLA is provider-dependent (currently). - Fix: publish explicit reliability model and roadmap. ### Recurring questions indicating onboarding gaps - “Where can I find **API endpoints**?” - “How do I migrate if I’m not using **Ledger** / if my wallet isn’t supported?” - “What does this migration error **actually mean**?” ### Specific improvements to align expectations - Add a **Migration FAQ** with: - snapshot date, eligibility, post-snapshot purchases policy, supported wallets, and safe-support policy. - Add an **Affiliations registry** page and a Discord command (e.g., `/affiliation zora`) returning authoritative status. --- ## 5) Community Engagement Insights ### Power users / key contributors observed (needs & leverage) - **Shaw (core-devs):** driving Jeju/Babylon cloud marketplace vision; needs structured community input on infra requirements (SLA, provider onboarding). - **sayonara / Stan ⚡:** iterating on streaming + chat UX; needs reproducible UX test cases (“otaku” parity criteria). - **Odilitime / Omid Sa / Borko / The Light:** acting as frontline support; needs better tooling (macros, KB articles, escalation runbooks). - **DorianD:** reports concrete product bugs (agent naming, deployment/ECR credentials, login errors) and asks tokenomics/infra integration questions; valuable as “builder+critic.” ### Common newcomer questions (onboarding friction) - Wallet migration and eligibility confusion dominates newcomer flow. - Basic “where is X on the site?” (API endpoints) indicates navigation and docs need tightening. ### Converting passive users into contributors 1. Create a **“good first issue: docs”** track specifically for migration FAQ, affiliation registry, and onboarding pages. 2. Establish a **#cloud-projects (or #eliza-cloud-showcase)** channel (already requested) with a template: - What you built, endpoints used, deployment method, issues encountered. 3. Offer a “Support Ranger” program: - Train volunteers with official macros and scam-avoidance scripts; give a visible role badge. --- ## 6) Feedback Collection Improvements ### Effectiveness of current channels - **Discord** is high-volume and fast, but support is noisy and (per GitHub #6211) exposed to **impersonation/scam risk**. - **GitHub** provides durable tracking but saw **minimal daily activity** in the 12/28–12/29 window, suggesting many user problems never become actionable issues. ### Improvements for more structured feedback 1. **Add an in-product “Report a problem / Send feedback” button** - Auto-captures: environment, agent ID, request ID, error codes, wallet type (if relevant). - This is already aligned with prior ecosystem interest (a “user feedback button” was referenced in broader project summaries). 2. **Migration issue intake form (official)** - Standard fields: snapshot wallet, current wallet, error code, screenshots, transaction hashes (optional), “I did not send tokens” checkbox. - Output directly into a GitHub issue template or a moderated queue. 3. **Monthly UX survey for builders** - Focus on: onboarding time-to-first-agent, deployment success rate, docs clarity. ### Underrepresented segments (missing feedback) - **Non-crypto builders** evaluating ElizaOS Cloud purely as infra (they are referenced as a target: “web2 developers” with 40% cost savings), but we have little direct feedback from them. - **Enterprise/teams** who care about SLA, compliance, and incident management—only one explicit SLA question so far, likely due to lack of clear channel for them. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Fix migration UX and eligibility clarity (highest urgency)** - Implement preflight eligibility check + replace ambiguous errors (“max amount reached”) with explicit reason codes and snapshot context. - Publish a canonical Migration FAQ + “we will never ask you to send tokens” policy. 2. **Add a safe, wallet-agnostic migration path** - Signature-based proof-of-ownership claim flow for unsupported wallets (Tangem-class), plus a documented assisted process if needed. 3. **Ship an official affiliations/verification system** - Public registry + Discord pinned explainer to stop “by elizaOS” confusion and reduce scam surface. 4. **Patch agent naming validation (quick win)** - Server-side enforcement + client-side validation + regression tests for reserved/edge-case names. 5. **Improve onboarding discoverability for Eliza Cloud (docs + UI)** - Add an in-dashboard API panel and a single “Start Here” guide that answers “where are endpoints?” with examples.