# User Feedback Report — 2025-12-31 (Aggregated through 2025-12-30) ## 1) Pain Point Categorization (Top recurring friction areas) ### A. Documentation — Token, migration, and ecosystem clarity (High frequency, High severity) **What users struggle with** - **Finding canonical token info quickly** (contract addresses, exchanges, trackers). Team had to add tokenomics info to docs as a stopgap (docs.elizaos.ai/tokenomics), and users asked for a dedicated “token page” similar to other projects. - **Understanding ecosystem relationships** (ElizaOS vs DegenAI vs Ruby; “by elizaOS” labeling; Zora affiliation confusion). - **Migration instructions incomplete for edge cases** (beyond Ledger; Tangem/WalletConnect support gaps called out explicitly in GitHub issue #6211). **Evidence** - In Discord “discussion” FAQ list, **9 of 11 questions (82%) were unanswered**, and many were token/migration/relationship questions (“contract?”, “migration timeline?”, “DegenAI still official?”, “where to buy?”). - Repeated doc requests: “list of projects launching on Eliza Cloud,” “visual aids for Jeju/appcoin concepts,” “clarify ElizaOS/DegenAI/Ruby.” --- ### B. Integration — Social platform deployment constraints (High frequency, Medium–High severity) **What users struggle with** - **Twitter/X API cost barrier (~$200/month)** blocks intended “agents on X” use cases; users actively seek alternatives and ask about cookie-based auth (answer: no). - **Website embedding / API integration** is possible but not packaged as a first-class “embed widget” experience; users request guidance and code snippets. **Evidence** - Multiple threads in #coders about avoiding X API costs; explicit Q/A: “cookie-based authentication?” → “No.” - “How do I integrate an ElizaCloud agent into my website?” required manual API steps (fetch agent ID via API endpoint + API key). --- ### C. Technical Functionality — Migration portal and wallet-connection failures (Medium frequency, High severity) **What users struggle with** - Migration portal errors: **“max amount reached”** for large balances; “coins visible but not exchangeable” when connecting Phantom. - **Wallet support limitations**: Tangem not supported via WalletConnect, raising a blocking eligibility/migration path question (GitHub issue #6211). - Users being redirected across channels for step-by-step help indicates the flow is not self-serve. **Evidence** - Dec 28 Discord: multiple user reports (Emma “max amount reached”; Fataliti Phantom “visible but not exchangeable”; Бизнес Гусь needs non-Ledger instructions). - GitHub #6211: Tangem snapshot eligibility + portal connection constraints. --- ### D. UX/UI — Dashboard/layout inconsistencies (Medium frequency, Medium severity) **What users struggle with** - UI consistency issues and layout behavior (agent cards resizing inconsistently; “Unslop Apps” layout/positioning complaint). - These are often “papercut” issues that degrade perceived polish, especially as new users arrive via token attention. **Evidence** - GitHub issues opened Dec 30: **#6291 “agent cards resizing”**, **#6299 “Unslop Apps”**. - Earlier in month (monthly summary): many UI/UX issues were filed and resolved, suggesting continued churn in UI behavior. --- ### E. Developer Experience (DX) — Release/versioning and plugin workflow friction (Medium frequency, Medium severity) **What users struggle with** - Plugin maintainers unsure whether to bump versions on every PR; lack of automated release tooling. - Desire for stronger CI conventions (e.g., “release-please”) to reduce cognitive load and merge friction. **Evidence** - Q/A in core-devs: “Should I pump the version for every plugin PR?” → “That’s what I’m doing… we should have CI… release please…” --- ### F. Community & Trust — Support credibility and gating confusion (Medium frequency, High severity when it occurs) **What users struggle with** - **Impersonation/support trust issues** (reported in GitHub #6211: Discord support “compromised” by impersonators). - Confusion around gated groups (Spartan channel access requires token holding + verification); repeated “how do I join” questions. **Evidence** - GitHub #6211 explicitly requests resolving via GitHub to avoid Discord impersonation risk. - Discord: multiple “Spartan group” questions answered via “#verify-wallet.” --- ### G. Performance/Reliability — Event duplication + streaming/logging correctness (Lower frequency externally, High impact technically) **What users struggle with** - Duplicate events on message bus (fixed) and streaming LLM logging missing (fixed via PR #6296) point to reliability gaps that can surface as “agent behaved weirdly” or missing observability. **Evidence** - core-devs: duplicates fixed; PR #6296 “log streaming LLM calls to database” merged. --- ## 2) Usage Pattern Analysis (How users are actually using elizaOS) ### Observed real-world usage (vs intended) - **Builders are treating ElizaCloud as an embeddable agent backend**, integrating agents into websites via API endpoints (requesting agent ID and wiring chat UI themselves). This indicates demand for a “drop-in embed” product surface. - **Community is heavily token-information driven**, using Discord as a real-time support desk for contract addresses, bridging constraints, migration status, and gated access. - **Agent deployment is broader than X/Twitter**: users seek alternative social surfaces (“Sentient Space”), signaling that “social agent framework” is the core job-to-be-done, not “Twitter bot framework.” ### Emerging / unexpected use cases - **OpenSouls framework integration** via community plugin (MemeBroker’s repos), suggesting demand for interoperability with other agent frameworks. - **Programmatic media generation** (Remotion) proposed for skills (video creation, screenshots via Playwright MCP). - **IoT/action calls by embeddings** discussed as a potential control mechanism—agents acting as orchestrators beyond chat. ### Feature requests aligning with actual usage - “List of projects launching on Eliza Cloud” → supports discovery + validates Cloud marketplace momentum. - Website embedding guidance → repeated integration questions imply a missing “official embed kit.” - CI-based plugin versioning and release automation → aligns with increasing plugin contributions and maintenance load. --- ## 3) Implementation Opportunities (Concrete solutions per major pain point) ### 1) Token + ecosystem documentation gap (High impact, Low–Medium difficulty) **Solutions** 1. **Single canonical “Token & Contracts” page on the main website** (not only in docs): contract addresses per chain, bridges (directionality), exchanges, CoinGecko/CMC links, and “official channels.” - *Impact:* reduces repetitive Discord questions; improves trust. - *Comparable approach:* many open-source + token projects (e.g., Uniswap-style token pages) use a single canonical landing page + signed links. 2. **“What is official?” registry page**: clarify relationships (ElizaOS vs DegenAI vs Ruby; which projects are “by elizaOS” vs community). - *Impact:* prevents brand confusion like “Zora is official?” - *Comparable approach:* Kubernetes/CNCF project landscapes clearly label “graduated/incubating/sandbox/independent.” 3. **Jeju explainer with visuals** (one diagram: AWS → permissionless racks roadmap; what “appcoin” means; what users can do today). - *Impact:* aligns expectations and reduces speculation-driven confusion. **Priority:** High / Easy-to-medium. --- ### 2) Migration portal + wallet support failures (High impact, Medium difficulty) **Solutions** 1. **Add explicit migration error catalog + self-serve checklist** in the portal UI (“max amount reached,” “visible but not exchangeable,” WalletConnect limitations) with next steps and safe links. - *Impact:* reduces support load; improves conversion. - *Comparable approach:* major bridges/migration dApps (e.g., Arbitrum bridge UX patterns) show targeted error remediation steps inline. 2. **Fallback “manual eligibility claim” flow for unsupported wallets** (e.g., Tangem): signed message verification alternatives, or backend-assisted claim via GitHub ticket template. - *Impact:* unblocks high-stakes users; reduces scam vulnerability. - *Comparable approach:* airdrop claim systems often support manual proof paths when wallet connectors fail. 3. **Instrument and publish migration health metrics** (error rates, common blockers, status page). - *Impact:* rebuilds confidence during volatile periods; helps prioritize fixes. **Priority:** High / Medium. --- ### 3) X/Twitter integration constraints (Medium–High impact, Medium difficulty) **Solutions** 1. **First-class “multi-social adapter” strategy**: promote/ship official connectors for at least one low-cost social surface (e.g., Farcaster local hub plugin already suggests a path; expand and document). - *Impact:* preserves social agent use case without X API dependency. 2. **Provide a “no-X deployment guide”**: recommended platforms + patterns (web embed, Discord, Farcaster, Telegram) with cost comparisons. - *Impact:* reduces repeated “how do I deploy without X?” questions. 3. **Clear statement on authentication limitations** (no cookie auth) in plugin docs and README. - *Impact:* prevents wasted time. **Priority:** Medium–High / Medium. --- ### 4) Website embed / ElizaCloud integration friction (High impact, Medium difficulty) **Solutions** 1. **Official “Embed SDK” (JS/React) + minimal widget**: one command install, set API key/agent ID, render chat component. - *Impact:* converts interest into deployments; reduces bespoke support. - *Comparable approach:* Intercom/Stripe provide drop-in widgets + SDK docs; open-source analogs offer “quickstart embed.” 2. **“Agent share link” reliability improvements + diagnostics** (the share-link chat errors reported): include error IDs and a “copy direct URL” affordance in UI. - *Impact:* lowers confusion (users already discovered “copy URL from browser” workaround). 3. **Publish example repos** for common integrations (Next.js, static site, Shopify/WordPress snippet). - *Impact:* scales adoption. **Priority:** High / Medium. --- ### 5) DX release/versioning automation for plugins (Medium impact, Low difficulty) **Solutions** 1. **Adopt automated release tooling** (e.g., Changesets or Google “release-please”) across plugin repos. - *Impact:* eliminates recurring version-bump uncertainty; faster merges. 2. **Define contribution rule-of-thumb**: when to bump major/minor/patch; tie to conventional commits. - *Impact:* reduces maintainer back-and-forth. 3. **CI checks for version alignment** (fail PR if package changed without changeset). - *Comparable approach:* many TS monorepos enforce changesets in CI. **Priority:** Medium / Easy. --- ### 6) Community trust + anti-impersonation posture (High impact, Medium difficulty) **Solutions** 1. **“Never DM first” + “Official links only” security banner** pinned in Discord + migration portal + GitHub issue templates. - *Impact:* immediate risk reduction. 2. **Verified support workflow**: require signed staff messages or a single ticketing portal domain linked from the website; lock down impersonation vectors. - *Comparable approach:* many crypto projects use Zendesk/HelpScout portals and aggressively warn against Discord DMs. 3. **Escalation path for high-risk cases on GitHub** (like #6211): a standardized label + response SLA target for migration-blocking issues. - *Impact:* rebuilds trust for security-conscious users. **Priority:** High / Medium. --- ## 4) Communication Gaps (Expectation vs reality) ### Where expectations don’t match reality - **“Official project” ambiguity:** Users assume anything discussed or labeled “by elizaOS” is official (e.g., Zora confusion). This is a branding/communications gap, not just a doc gap. - **Migration smoothness expectation:** Users expect wallet compatibility “just works.” Reality: WalletConnect gaps (Tangem), portal errors for large balances, and chain-bridge directionality constraints (Solana → others only, not vice versa). - **ElizaCloud “beta” support expectations:** Open beta with “light support” is available, but users ask for production-like features (SLAs, embed-ready flows). ### Recurring questions indicating onboarding gaps - “What’s the contract address?” / “Where to buy?” / “How to bridge?” - “How do I join Spartan / verify wallet?” - “How do I integrate an agent into my website?” (agent ID retrieval required) - “Share link chat errors / correct character URL?” ### Improvements to align expectations - Add a **Quick Answers** section inside the app/website: contracts, bridging rules, migration status, official links, and “how gating works.” - Add **“Beta limitations”** callouts for ElizaCloud (support level, SLA availability, roadmap). --- ## 5) Community Engagement Insights ### Power users & what they need - **Stan**: focused on core transport/hooks, streaming correctness, and CI automation (“release please”). Needs predictable release processes and clean architecture boundaries. - **Odilitime**: plugin maintenance (OpenAI plugin fixes, caching), infra interest (offering data center coverage). Needs contributor-friendly release/versioning and clearer infrastructure roadmap touchpoints. - **MemeBroker**: ecosystem builder shipping public repos (Skills_elizaos, OpenSouls plugin). Needs visibility, a plugin registry path, and integration documentation to avoid duplicating effort. ### Newcomer questions signaling friction - Token basics (contracts, buying, bridging) and migration steps dominate “first contact” interactions. - Confusion about share links/URLs indicates UX affordances are not obvious. ### Converting passive users into contributors - Create “good first issues” specifically for: docs diagrams (Jeju/appcoin), website token page, embed examples, and migration FAQ. - Spotlight community-built integrations (OpenSouls plugin, skills repo) in a monthly “Community Ship List,” with a clear path to become “officially listed.” --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** is high-volume but produces many **unanswered** and **repeated** questions (notably token/migration), making it inefficient for durable knowledge capture. - **GitHub issues** capture high-severity problems well (e.g., #6211) but are underused for “how-to” feedback and UX papercuts unless prompted. - In-product feedback is minimal (a “user feedback button” was requested earlier in the month via plugin-openai issue #6280, indicating demand). ### Recommendations for more structured, actionable feedback 1. **Add an in-app “Send Feedback” button** (category + screenshot + logs opt-in). Route UX issues to GitHub with templates. 2. **Discord → GitHub capture bot**: allow helpers to convert a resolved Discord thread into a short FAQ/doc PR suggestion. 3. **Migration portal embedded form**: “Report a blocker” with wallet type + error code + anonymized diagnostics. ### Underrepresented segments - **Security-conscious users avoiding Discord** (explicit in #6211) need a trusted support path. - **Non-technical token holders**: repeated contract/bridge questions suggest they aren’t being served by developer-centric docs. - **Web integrators**: asking for embed guidance indicates a segment building customer-facing sites, not just agents. --- ## Prioritized High-Impact Actions (Next 2–4 weeks) 1. **Ship a canonical “Token & Official Links” webpage** (contracts per chain, exchanges/trackers, bridging rules, migration status, security warnings). 2. **Improve migration portal UX for known blockers**: inline error explanations + Tangem/unsupported-wallet fallback path + “max amount reached” fix. 3. **Release an official ElizaCloud Embed SDK + example repos** (Next.js + vanilla JS), reducing repeated integration support. 4. **Publish an “Official vs Community” ecosystem registry page** (clarify DegenAI/Ruby/Spartan, and labeling rules for “by elizaOS”). 5. **Adopt release automation for plugins (Changesets or release-please)** and document versioning guidelines to unblock maintainers.