## User Feedback Analysis — 2026-01-09 (covering Discord + GitHub signals from 2026-01-06 to 2026-01-08) ### Data note (for quantification) This analysis is based on **~20 distinct user-reported issues/questions** captured in the provided Discord summaries and the latest GitHub weekly/monthly rollups. Percentages below refer to share of these distinct items (not total messages). --- ## 1) Pain Point Categorization (Top recurring 5–7) ### 1) **Token migration & exchange handling confusion** (Category: **Integration / Documentation**) — **High severity, high frequency (~30–35%)** **What users reported (examples):** - Migration eligibility showing **“0 eligible tokens”** for pre-Nov holders (XXI_Rapax). - LP migration failing with **“max amount reached”** (Dabel). - Conflicting community answers about **whether exchanges auto-migrate** holdings (Bithumb/Coinone) (KARA; FoRever_BIG vs jessy). - Korean exchanges delisting (Bithumb/Coinone/Korbit) attributed to **“lack of transparency”** in rebrand/swap procedure (DAXA rationale shared in community). **Impact:** - Immediate trust + support load issue; also drives scam attempts (GUIDE BASE/guidebt targeted migrators). --- ### 2) **Unclear token utility / ecosystem value proposition** (Category: **Documentation / Community**) — **High severity, medium-high frequency (~15–20%)** **What users reported:** - Direct questioning of *why the token exists* if not used for payments/gas; concern token supply increased without utility (stoikol). - No definitive team answer surfaced in the discussion, creating perception of evasiveness. **Impact:** - Erodes confidence during migration + delisting news; amplifies “FUD vs confirmed” arguments and makes community helpers improvise answers. --- ### 3) **Discord plugin breakage in core v1.7.0 (serverId → messageServerId)** (Category: **Technical Functionality**) — **High severity, medium frequency (~10–15%)** **What users reported:** - Discord bot failing to detect server ID/usernames with error **“No server ID found 10”** (DigitalDiva). - Root cause identified as serverId→messageServerId migration; PR #6333 + odi-17 branch used as mitigation; advice to downgrade to **v1.6.5** until release stability returns (Odilitime). **Impact:** - Blocks a primary “hello world” integration path (Discord bot), harming onboarding and perceived stability. --- ### 4) **Docs availability + “missing quick answers” for common setup** (Category: **Documentation**) — **High severity, medium frequency (~10–15%)** **What users reported:** - **elizacloud.ai/docs down** (Amir). - Repeated “how do I…?” questions with sharp edges: - Model parameter format causing **“Model not found”** until provider prefix used (ElizaBAO → `openai/gpt-4o-mini`, etc., via cjft). - Dev/prod confusion around destructive migrations: **`ELIZA_ALLOW_DESTRUCTIVE_MIGRATIONS=true`** (Andrei Mitrea) and when to use `elizaos dev` vs `elizaos start` (Omid Sa). **Impact:** - Users hit preventable blockers early; helpers repeatedly answer the same configuration questions. --- ### 5) **Cloud/deployment configuration ambiguity (DB choice, container ops)** (Category: **Technical Functionality / Documentation**) — **Medium severity, medium frequency (~10%)** **What users reported:** - “Pglite or Postgres for ElizaCloud containers?” (answered: either works). - Underneath this is a missing decision guide: *when* each is appropriate (local dev vs production, concurrency, backups, latency, managed Postgres like Neon). **Impact:** - Causes hesitant adoption and inconsistent deployments, complicating support. --- ### 6) **Product UI polish & reliability issues (agent builder + web search)** (Category: **UX/UI / Technical Functionality**) — **Medium severity, lower frequency (~10%)** **What users reported (from daily report rollup):** - Inconsistent UI box sizes. - Web search intermittently non-functional. - Agent builder microcopy and mobile naming defaults (capitalize agent names). **Impact:** - Not as blocking as migration/Discord breakage, but harms perceived quality and day-to-day usability. --- ### 7) **Information discoverability + “official source of truth” problems (CA, listings, status)** (Category: **Community / Documentation**) — **Medium severity, medium frequency (~10%)** **What users reported:** - Difficulty finding the official **contract address** quickly on official accounts; request “find within 10 seconds” (Broccolex, degenwtf; shaw acknowledged). - Delisting facts debated as “confirmed vs FUD,” suggesting lack of a canonical incident/status post. **Impact:** - Encourages rumor propagation, increases scam risk, and forces community mods/helpers to act as human search engines. --- ## 2) Usage Pattern Analysis (Actual vs intended) ### How users are actually using elizaOS (observed) 1. **As an “agent runtime + connectors” framework**, with Discord as a primary entrypoint (DigitalDiva’s bot troubleshooting shows many start here). 2. **As a cloud-embedded agent for websites** via agent IDs + API endpoints (ElizaBAO), where *model/provider selection* is a recurring sharp edge. 3. **As an on-chain/crypto-adjacent agent ecosystem**, including: - Token migration and exchange custody flows (dominant community attention). - Plugin ecosystem for payments/escrow (KAMIYO AI plugin; Bazaar marketplace on Jeju). 4. **As a data/insight generation pipeline**: agentic workflows producing daily/weekly/monthly insights, but users/devs call out “last mile” delivery gaps (jin). ### Emerging / unexpected use cases - **Human data contribution marketplace** concepts (Eliza phone app, reputation points, IOU-based micro-incentives, motion capture royalties) proposed by DorianD—this is moving elizaOS toward a *data network / provenance / incentives* narrative, not just “agent framework.” ### Feature requests aligned with actual usage - “Last-mile” integrations for insights: **webhooks, apps, agent surfaces** (jin). - **Cheaper X/Twitter integration path** vs $200/month API cost (Discostu) — consistent with agents-as-researchers. - **Marketplace/appstore for agents** (Bazaar on Jeju) — consistent with plugin registry growth and discovery/forking roadmap. --- ## 3) Implementation Opportunities (2–3 concrete solutions per major pain point) ### A) Token migration & exchange handling confusion (High impact) 1. **Publish a canonical “Migration Status” page + API** (High impact / Medium effort) - Include: eligibility rules (snapshot), exchange custody handling per-exchange, LP edge cases (“max amount reached”), common error codes, current known incidents. - Similar pattern: **Arbitrum / Optimism airdrop claim pages** with live status + FAQ + “known issues” banners. 2. **Add an automated eligibility self-check + error explainer** in the migration UI (High impact / Medium effort) - When user sees “0 eligible” or “max amount reached,” show *specific reason* (e.g., post-snapshot purchase, LP position type unsupported, already claimed, wallet mismatch) and next action (“open ticket with these fields prefilled”). 3. **Harden anti-scam workflows** around migration support (High impact / Low-medium effort) - Auto-DM warnings, pinned “we will never DM first,” verified support bot, and a “report scam” one-click flow. - Similar pattern: **Uniswap/MetaMask** community anti-scam pinned messages + automated moderation triggers. --- ### B) Unclear token utility / value proposition (High impact) 1. **Ship a “Token Utility RFC” + living roadmap** (High impact / Low-medium effort) - Even if utility is phased, state what is *not* planned vs *planned*, timelines, dependencies (Jeju/Bazaar/payments). - Similar pattern: **Ethereum Improvement Proposal (EIP)-style** public RFCs; **GitBook “Tokenomics & Utility”** pages used by many open networks. 2. **Tie token utility to concrete product surfaces** (High impact / Medium-high effort) - Examples: Bazaar listing fees, agent marketplace revenue share, reputation multipliers, staking for rate limits, escrow dispute fees (aligns with KAMIYO’s escrow/dispute narrative). 3. **Create a “Utility today vs tomorrow” one-pager** (Medium impact / Low effort) - Clarify current reality (e.g., rewards) and explicitly address why it’s not gas/payments yet. --- ### C) Discord plugin breakage in v1.7.0 (High impact) 1. **Add compatibility gates + upgrade assistant** (High impact / Medium effort) - On startup, detect mismatched core/plugin versions and provide actionable output: “core 1.7.0 + plugin-discord 1.3.3 incompatible; upgrade/downgrade suggestions.” - Similar pattern: **Home Assistant** integration version checks; **Kubernetes kubectl version skew** warnings. 2. **Enforce migration completeness with CI checks** (High impact / Medium effort) - Add a repo-wide test ensuring no remaining `serverId` references where `messageServerId` is required; fail PRs that introduce old field usage. 3. **Publish a “Discord quickstart known-good matrix”** (Medium impact / Low effort) - Simple table: core version ↔ plugin-discord version ↔ bootstrap version. --- ### D) Docs availability + missing quick answers (High impact) 1. **Failover docs hosting + uptime monitoring** (High impact / Medium effort) - Mirror docs to GitHub Pages (or equivalent) with redirects; add status page + alerts. - Similar pattern: **Stripe** status + multi-region docs/CDN; **Next.js** docs on Vercel with redundancy. 2. **Create “Golden Path” install/run guides with copy-paste configs** (High impact / Low-medium effort) - Cover: model parameter prefixes, `elizaos dev` vs `start`, destructive migrations flag (dev-only), DB selection. 3. **Convert repeated Discord answers into a searchable FAQ bot** (Medium impact / Medium effort) - Feed from HackMD/book + docs repo; propose answers with citations; reduces cjft/Omid Sa repeated support burden. --- ### E) Deployment ambiguity (DB choice, containers) (Medium-high impact) 1. **Decision tree: PGlite vs Postgres vs Neon** (Medium-high impact / Low effort) - Include: concurrency expectations, persistence needs, backups, edge/serverless constraints. 2. **Provide reference docker-compose templates** (High impact / Medium effort) - “local dev (PGlite)” and “production (Postgres/Neon + RLS)” templates. 3. **Surface recommended defaults in CLI** (Medium impact / Medium effort) - `elizaos init --target=dev|prod` to generate correct config. --- ### F) UI polish + web search reliability (Medium impact) 1. **Add a lightweight UI consistency checklist + visual regression tests** (Medium impact / Medium effort) - Similar pattern: **Storybook + Chromatic** for component diffs. 2. **Instrument web search with health checks + clear user-facing errors** (Medium impact / Medium effort) - If intermittent, show provider status, retry/backoff, and logs. 3. **Batch small UX fixes into a “Quality sprint” cadence** (Medium impact / Low effort) - Capitalization defaults, copy updates, spacing consistency. --- ## 4) Communication Gaps (Expectations vs reality) ### Gaps observed - **Exchange auto-migration expectations**: users received conflicting answers (FoRever_BIG vs jessy). This indicates missing official stance per exchange and unclear custody responsibility. - **Token utility expectations**: users expect a token to be used for payments/gas; current reality appears closer to rewards, with no authoritative explanation in-thread. - **X integration expectations**: “Can Eliza do X research without paying for the X API?” remains unanswered, suggesting unclear boundaries/legality/approach (API vs scraping vs third-party providers). - **Version stability expectations**: v1.7.0 shipped while a critical Discord path was broken for some users; users expect “latest” to be safe. ### Specific improvements to align expectations - Add a pinned “Known Issues / Current Incidents” post in Discord updated daily during migrations/releases. - Add an explicit “Supported integrations and requirements” page (e.g., X requires API or third-party provider; scraping stance stated). - Adopt release channels: **stable vs latest**; recommend stable in docs and CLI. --- ## 5) Community Engagement Insights ### Power users and their needs (and why they matter) - **Odilitime**: deep debugging + patches (odi-17, PR #6333). Needs: faster release pipeline for plugins, version matrices, stronger CI migration checks. - **Stan**: cloud reliability/perf (TOCTOU fixes, runtime init optimizations). Needs: benchmarking harnesses, clearer perf targets, structured feedback on cloud incidents. - **jin**: product/data direction (context graphs, insight workflows). Needs: “last-mile” integration primitives and examples (webhooks/apps). - **cjft**: frontline technical support (model prefix fix, DB guidance). Needs: docs/FAQ automation to reduce repeat queries. - **Hexx 🌐 / sb**: community support + safety + explanations (scam response, Bazaar clarification). Needs: official source-of-truth links to avoid improvisation. ### Newcomer questions indicating onboarding friction - “Why is my Discord bot not seeing server ID?” → needs a current, tested quickstart + compatibility matrix. - “Model not found” → needs API docs to show exact `provider/model` format prominently with examples. - “Destructive migrations blocked” → needs dev/prod guidance and safer defaults. ### Converting passive users into contributors - Create “good first issue” bundles around: docs fixes (X integration page, migration FAQ), UI consistency, and integration tests for version skew. - Run weekly “office hours” focused on one area (Discord integration one week, cloud deploy next) and convert answers into merged docs PRs. --- ## 6) Feedback Collection Improvements ### Effectiveness of current channels - **Discord** is high-velocity but produces duplicated questions and inconsistent answers when no official reference exists (notably migration + exchange custody). - **GitHub** captures technical work well, but many user-impacting issues (migration UX, docs downtime, exchange comms) don’t land as structured issues. ### Improvements for more structured, actionable feedback 1. **Add guided issue forms** (GitHub + in-app) for: - Migration problems (wallet type, exchange, LP, error code, screenshot, tx hash). - Integration problems (core/plugin versions, logs, minimal repro). 2. **Create a public status/incident log** for: - docs downtime, migration incidents, exchange announcements, release regressions. 3. **Tag + triage pipeline** that maps Discord threads → GitHub issues automatically (even a simple mod workflow: “/issue create” bot). ### Underrepresented segments whose feedback is missing - **Non-Discord users** affected by migration/exchange delistings (especially region-specific users) who may never join Discord. - **Production deployers** (ops teams) who need clearer guarantees around migrations, destructive changes, and DB/security posture (RLS, Neon support). --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Publish an official Migration & Exchange Custody “Source of Truth” (status page + FAQ + per-exchange policy)** *Why:* addresses the largest cluster of severe confusion, reduces scams, and prevents conflicting community answers. 2. **Stabilize Discord onboarding with a compatibility matrix + automatic version mismatch detection** *Why:* Discord is a primary entry path; v1.7.0 breakage is a hard stop for newcomers. 3. **Restore and harden documentation availability (docs failover + “Golden Path” guides)** *Why:* docs downtime + missing quick answers creates repeated support load and churn. 4. **Publish a Token Utility RFC (clear “now vs later,” tie to Bazaar/Jeju surfaces)** *Why:* closes a major trust/expectation gap and reduces ongoing narrative drift. 5. **Add structured feedback capture for recurring support topics (migration + integrations) via issue forms and a Discord → GitHub bridge** *Why:* turns high-volume chat into actionable engineering work with measurable closure rates.