## User Feedback Analysis — 2025-12-21 (covering feedback observed 2025-12-18 to 2025-12-20 + Dec GitHub trends) ### Data Notes / Confidence - Discord daily logs available for **12-18, 12-19, 12-20**; **12-21 file missing**. - GitHub signal comes from December aggregated activity and several top issues/PRs. - Quantification below is based on **observable questions + repeated themes** in the provided excerpts (not full-server analytics). --- ## 1) Pain Point Categorization (Top recurring 5–7) ### 1. Token migration confusion & eligibility edge-cases (Category: **Documentation / Community / Integration**) **Frequency/Severity:** Very high / High (blocks users, fuels distrust). - In Discord FAQs, **~80–83% of user questions** were token/migration-related (e.g., “0 eligible”, post-snapshot purchases, chain liquidity differences, where the “new contract” is). - GitHub issue **#6211** highlights a critical edge case: **Tangem wallet snapshot eligibility + inability to connect via WalletConnect**, plus fear of impersonators in Discord support. - Repeated confusion about: - Snapshot rules (“only tokens bought before Nov 11” / “0 eligible”) - Where to find official contract addresses across chains - Liquidity differences when selling (e.g., “40% price difference on Solana” → bridge to BSC) **Most affected users:** Token holders trying to migrate; newcomers relying on Discord support; users with nonstandard wallets (Tangem / hardware / keycard-only). --- ### 2. Trust & safety: scams/impersonation in support flows (Category: **Community / UX/UI**) **Frequency/Severity:** High / Critical (risk of asset loss). - Multiple warnings about **scammers sending suspicious links**, moderators actively intervening. - GitHub #6211 explicitly states: “Discord support compromised due to impersonators… directing users to send tokens manually.” - Users are moving support to GitHub because **Discord is perceived as unsafe** for migration resolution. **Most affected users:** Newcomers + token migrators + anyone opening “tickets” or clicking links. --- ### 3. Perceived lack of shipped product / unclear roadmap timing (Category: **Community / Documentation**) **Frequency/Severity:** High / High (drives negative sentiment, churn). - Repeated frustration: token price down while market up; comments questioning whether “a single tangible product” shipped. - Team shared updates (Cloud MVP Monday; Q1/Q2 2026 roadmap upcoming), but users still describe delivery as slow or unclear. - This is less a “feature bug” and more an **expectation management gap**. **Most affected users:** Token holders, community investors, and builders deciding whether to commit time. --- ### 4. Plugin / TypeScript friction during integration (Category: **Technical Functionality / Integration**) **Frequency/Severity:** Medium / Medium–High (blocks builders). - Starknet plugin work ran into: - Type mismatch: `AgentRuntime` vs `IAgentRuntime` - “Missing handler” errors for specific actions (deploy “unruggable meme token” action) - “Type conversion issues in all action files” → suggests churn in types/APIs - Guidance in Discord (“use specific versions, not `latest`”) indicates version skew is a known hazard. **Most affected users:** Plugin authors and integrators, especially in Web3 ecosystems (Starknet/EVM). --- ### 5. Performance concerns around provider execution pipeline (Category: **Performance / Technical Functionality**) **Frequency/Severity:** Medium / Medium (visible to power users, affects responsiveness). - Active debate and PR activity around provider execution: - Proposal: **parallel provider execution with timeout (default 1s)** and abort behavior (PR #6263 mentioned in Discord) - Need to codify provider best practices (avoid uncached API calls) **Most affected users:** Advanced builders composing multiple providers; cloud/hosted deployments where latency is costly. --- ### 6. Release/packaging friction (npm token changes, version pinning) (Category: **Technical Functionality / Integration**) **Frequency/Severity:** Medium / Medium (impacts shipping velocity). - NPM “classic token deleted” caused release friction; v1.7.0 notes “npm fixes”. - Explicit guidance: pin `@elizaos/*` versions rather than relying on `latest`. **Most affected users:** Maintainers, plugin ecosystem contributors, CI/CD pipelines. --- ### 7. Community inclusion concerns (Korean community feels marginalized) (Category: **Community**) **Frequency/Severity:** Low–Medium frequency / High severity (community health). - Korean users expressed they feel marginalized by leadership. - Not many data points provided, but severity is high because it can fracture the community. **Most affected users:** Korean-speaking community members; global users who depend on localized support. --- ## 2) Usage Pattern Analysis (actual vs intended) ### What users are actually using elizaOS for (from observed feedback) 1. **Token migration + ecosystem participation** is currently dominating attention (Discord discussion traffic is heavily token-centric). 2. **Cloud MVP + streaming** is a key expected “product proof” milestone (multiple mentions; v1.7.0 released with streaming). 3. **Plugin-building for Web3 networks** (Starknet/EVM, “knowledge repo” for onchain reasoning, DeFi plugins, Farcaster local hub). 4. **Automation/embedded tooling comparisons**: users compare capabilities to **Playwright/Puppeteer MCP**; desire clarity on what’s unique. ### Misalignment vs intended usage - Intended: open-source AI agent framework + plugins + cloud. - Actual (this week): community energy is being diverted into **migration mechanics, liquidity, and price**, reducing bandwidth for builder onboarding and developer support. ### Emerging / unexpected use cases & feature requests aligned to usage - **TradingView integration** request (chart functionality) suggests active use in trading/market contexts. - “Pocket-sized Eliza companion” indicates a shift toward **consumer companion UX**, not just developer framework. - “AI agents for internet support/customer service” mentioned as a goal: aligns with agent runtime + integrations, but needs templates/examples. --- ## 3) Implementation Opportunities (solutions per major pain point) ### Pain Point A: Token migration confusion & edge cases **High impact / Low–Medium difficulty** 1. **Single canonical “Migration Hub” page (web + docs)** with: - Snapshot rules in plain language (pre/post Nov 11, deadlines like Feb 4 2026) - “0 eligible” troubleshooting decision tree - Official contract addresses (multi-chain) and official links - “Never send tokens to anyone” banner - *Comparable approach:* Uniswap and Arbitrum migrations publish a single canonical page + pinned social posts; Ethereum L2 airdrops use decision trees and “common scams” sections. 2. **Wallet compatibility matrix + official workaround policy** - Explicitly list supported wallets (WalletConnect, Phantom, etc.) and **unsupported** (e.g., Tangem keycard-only) with the official next steps. - For Tangem-like cases, publish an **official support path** (e.g., signed message verification + manual backend attestation process). - *Comparable approach:* Hardware wallet ecosystems (Ledger/Trezor) publish “supported connection methods” and formal “unsupported wallet” escalation. 3. **Migration verifier CLI tool** - A small CLI that checks snapshot eligibility and prints next steps without requiring Discord. - *Comparable approach:* Cosmos/Polkadot ecosystems often ship “claim checkers” and CLI verification tools for airdrops/migrations. --- ### Pain Point B: Scams/impersonation and unsafe support flows **High impact / Medium difficulty** 1. **Verified Support Workflow** - Move migration support intake to GitHub (issue forms) or a dedicated portal with login + signed messages. - Add Discord automod that blocks all non-whitelisted domains and enforces “no DMs from staff” policy. - *Comparable approach:* Solana and major NFT projects use strict domain allowlists + “support never DMs first” enforcement bots. 2. **Cryptographic verification of official links** - Publish official links and contract addresses in a **signed GitHub release / signed gist** (or DNS TXT record) and reference it everywhere. - *Comparable approach:* Many security-forward projects publish checksums/signatures and link verification steps. 3. **In-Discord “/verify” bot command** - Users paste a URL/contract; bot responds whether it matches the official allowlist. - Reduces moderator burden and prevents panic-driven clicks. --- ### Pain Point C: Roadmap/product delivery expectations unclear **High impact / Low difficulty** 1. **Weekly “Shipped / Shipping / Blocked” changelog** - Tie Cloud MVP, streaming rollout, and next milestones to dates and acceptance criteria. - *Comparable approach:* Vercel, Supabase, and OpenAI-style release notes emphasize “what changed” and “how to use it.” 2. **Roadmap with “confidence levels”** - Mark items as Committed / Likely / Exploratory (and what must be true to ship). 3. **Demo-first communication** - For Cloud MVP + streaming: 2–3 minute screen recordings showing end-to-end: create → run → stream → deploy. --- ### Pain Point D: Plugin/TypeScript integration churn (AgentRuntime types, handlers) **High impact / Medium difficulty** 1. **Stable plugin interface package + semver contract** - Publish a “plugin API stability” document and a dedicated `@elizaos/plugin-api` (or formal interfaces) that changes less frequently. - *Comparable approach:* VS Code extension API and Kubernetes client libraries separate stable interfaces from internal churn. 2. **Codemod + migration guide for plugin authors** - Provide a scripted codemod for common type renames (`AgentRuntime`/`IAgentRuntime`, action signature changes). - *Comparable approach:* Next.js and React ecosystems ship codemods for breaking changes. 3. **Golden plugin templates per network** - Official, continuously-tested reference plugins (EVM, Starknet) with CI against `develop` and last 2 stable versions. --- ### Pain Point E: Provider pipeline performance + best practices ambiguity **Medium–High impact / Medium difficulty** 1. **Adopt parallel provider execution with timeouts + observability** - Proceed with the configurable timeout approach; add structured logs: provider name, duration, cache hit/miss. 2. **Provider design guidelines + lint rule** - Document “no external API calls without caching” and add a lint/checklist in PR templates for providers. - *Comparable approach:* LangChain/LlamaIndex emphasize caching + tool latency constraints; many frameworks include “observability first” instrumentation. 3. **User-facing performance panel** - In client/cloud UI: show last-run timings per provider/action to help builders self-diagnose. --- ### Pain Point F: Release/packaging friction (npm tokens, version pinning) **Medium impact / Low difficulty** 1. **Release runbook** - Document npm token requirements, rotation policy, and CI secrets management. 2. **Ecosystem-wide dependency alignment checks** - Expand the registry’s “version/core dependency mismatch” detection (already being addressed in registry PRs) to warn plugin authors earlier. 3. **“Supported versions” badge** - Each plugin declares compatibility ranges; CI enforces. --- ### Pain Point G: Community inclusion (Korean community concerns) **High impact / Medium difficulty** 1. **Designate language/community stewards** - Empower bilingual mods; publish escalation path; rotate “community office hours.” 2. **Localized critical announcements** - Migration, security warnings, and roadmap summaries translated and pinned. 3. **Community pulse surveys by region** - Monthly lightweight survey to detect dissatisfaction early. --- ## 4) Communication Gaps (expectations vs reality) ### Gap 1: “Migration should be simple” vs reality of snapshot rules + wallet limitations - Recurring questions indicate users don’t understand: - Why “0 eligible” happens - Why post-snapshot purchases can’t migrate - What to do if their snapshot wallet can’t connect (Tangem) **Fix:** publish a decision tree and wallet compatibility matrix; add “why” explanations (not just rules). ### Gap 2: “elizaOS Cloud is shipping” vs uncertainty on what Cloud MVP actually enables - Users heard “Cloud MVP Monday” but lack clarity on features and how it changes developer workflow. **Fix:** a Cloud MVP “What you can do on day 1” page + sample repo. ### Gap 3: “Streaming is supported” vs unclear rollout surface area - v1.7.0 mentions streaming; Discord Q “1.7.0 w/ streaming?” went unanswered. **Fix:** explicit docs: which providers support streaming, how to enable (`stream: true`), known limitations. ### Gap 4: “Embedded Playwright/Puppeteer MCP” confusion - Users ask “difference vs playwright/puppeteer?” indicating unclear product positioning for embedded tooling. **Fix:** a comparison doc: elizaOS tool embedding vs external browser automation, with examples and boundaries. --- ## 5) Community Engagement Insights ### Power users / high-leverage contributors (observed) - **Stan ⚡**: driving provider performance direction and release sequencing; needs clear decision-making process and fast review cycles. - **Odilitime**: active in plugin guidance and PRs (Discord/Telegram refactors); needs stable interfaces and migration tooling. - **jin / jintern**: summarization, security guidance, knowledge repo endpoints; needs official channels to publish “verified” summaries. - **standujar** (GitHub): large technical contributions (JWT auth, provider optimizations); needs product requirements clarity + docs follow-through. - **borisudovicic** (GitHub): heavy UX issue creation; needs prioritization alignment and feedback loop (“accepted/declined/queued”). ### Newcomer questions signaling onboarding friction - “What model does the agent use?” → need a model/provider overview page (model-agnostic but how to choose). - “Where can I see the new contract?” → need canonical link + pinned message. - “How do I migrate if 0 eligible?” → needs troubleshooting steps outside Discord. - “Docs moved কোথায়?” (packages/docs missing) → discoverability issues in docs repo structure. ### Converting passive users into contributors - Create “Good first issue” tracks tied to current pain: - Migration hub page (docs PRs) - Anti-scam bot allowlist maintenance - Plugin template CI improvements - Offer contributor recognition for non-code contributions (translations, docs, triage), especially for underrepresented language groups. --- ## 6) Feedback Collection Improvements ### Effectiveness of current channels - **Discord**: high volume, fast responses, but currently **high-risk** for scams and hard to convert into actionable tickets. - **GitHub**: higher quality for technical issues (e.g., Tangem case), but not all community members use it; token/migration questions often stay in Discord. ### Improvements for more structured, actionable feedback 1. **GitHub Issue Forms for Migration & Security** - Required fields: wallet type, snapshot date holdings, chain, “0 eligible” screenshot, links encountered. 2. **Discord → GitHub bridge** - A bot command that creates a draft GitHub issue from a Discord thread (with user consent). 3. **In-product feedback widget (Cloud/client)** - Capture: task intent (“what were you trying to do”), success/failure, logs, version, provider config. ### Underrepresented segments missing from feedback - **Non-English communities** (explicit Korean concern suggests gaps). - **Non-Discord users** (people avoiding Discord due to scams). - **Enterprise/self-host operators** (performance, auth, data isolation needs exist in PRs, but not much user narrative feedback). --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Publish a canonical Migration Hub + Security page** (rules, wallet matrix, contract addresses, “never send tokens,” official links) and pin it everywhere. 2. **Harden support against scams**: domain allowlist + “verify link/contract” bot + move sensitive migration support to a verifiable portal/GitHub forms. 3. **Ship Cloud MVP onboarding artifacts**: “Day-1 capabilities” doc + 2–3 minute demo + quickstart repo; include streaming enablement guide for v1.7.0+. 4. **Stabilize plugin developer experience**: document version pinning, publish a plugin API compatibility policy, and add a codemod/migration guide for recent type/interface churn. 5. **Implement performance observability for providers** (even minimal logging + timing) alongside parallel execution/timeouts, so builders can diagnose latency without guesswork.