## User Feedback Analysis — 2026-01-24 ### Data sources reviewed - Discord: **#discussion**, **#coders**, **#partners** (2026-01-21 to 2026-01-23) - GitHub: recent issues/PR activity referenced in summaries (notably migration eligibility + plugin stability signals) --- ## 1) Pain Point Categorization (Top recurring 5–7) ### 1. Technical Functionality — **Plugin breakages & runtime errors (high severity, recurring)** **What users hit most** - **Discord plugin regressions across versions**: agents failing to respond; errors like `Cannot access invalid private field (evaluating 'this.#conversationLength')`. - Evidence: DigitalDiva reported failures after upgrading (1.7.2 / plugin-discord 1.7.2 context); resolved for servers by upgrading to **plugin-discord 1.3.8**, but not fully for DMs. - **DM path still broken after update**: role provider error: **“User has no name or username, skipping.”** - Evidence: persists post-1.3.8 for DigitalDiva. - **Database migration confusion between PGLite vs Postgres** leading to `CREATE SCHEMA IF NOT EXISTS migrations` failures. - Evidence: DigitalDiva repeatedly hit this; workaround was switching to **Neon** DB in later troubleshooting. **Frequency signal (within provided data)** - 2–3 consecutive days of Discord-plugin and DB-related troubleshooting threads (same user, multiple attempts) → indicates “sticky” failures that block progress once encountered. --- ### 2. Integration — **External platform constraints & migration edge cases (high severity, recurring)** **What users hit most** - **Token migration eligibility mismatches** after moving assets from wallets lacking dapp browsers (e.g., Robinhood) or hardware wallets (Tangem on GitHub). - Evidence: ryanb.btc (Robinhood transfer → “not eligible” until support intervention), GitHub issue #6369 (Tangem snapshot mismatch). - **Scam vectors exploiting migration confusion** (“support” asking users to send tokens). - Evidence: Jeburek12 report; Kenk confirmed scam. **Frequency signal** - At least **2 real eligibility incidents + 1 scam incident** in a ~48–72 hour window. --- ### 3. Documentation — **Unclear “what’s official” and “how it benefits me” (high severity, very frequent)** **What users hit most** - **Official vs unofficial token confusion** (GOLD / CJFT / BAGS) + missing timely announcements. - Evidence: repeated questions: “Is GOLD real?”, “Is CJFT official?”, “What is BAGS?”; CA confirmed only after price movement (community complaint). - **Value proposition ambiguity**: how multiple projects/tokens map to **ElizaOS holder value**, monetization, and customer acquisition plans. - Evidence: V33 + Scrapy Coco feedback; one user cited losses ($28k → $800) and questioned strategy. - **Airdrop eligibility uncertainty** (especially CEX vs self-custody). - Evidence: repeated questions; official answer: “no details announced,” leaving users to infer best practices. **Frequency signal** - These were the dominant topics in #discussion on 2026-01-23 and also present on 2026-01-21–22. --- ### 4. Community — **Trust erosion from token-launch controversies (very high severity, frequent)** **What users hit most** - **Perceived insider advantage / poor launch execution**: reported red flags like **40% dev wallet**, wallets funded shortly before launch, and claims of **~$150k extracted** via coordinated early entries. - Evidence: multiple community members flagging; shaw acknowledged LP management mistakes that damaged supply. - **“Too many tokens, not enough platform focus”**: “scatterbrained decision-making,” dilution of attention away from core infra (ElizaCloud). - Evidence: DannyNOR NoFapArc, Jayzen, The Three Words, Scrapy Coco. **Frequency signal** - Multiple unique users escalated trust concerns; this topic dominated the day’s discussion. --- ### 5. Performance / Reliability — **ElizaCloud stability and access issues (high severity, moderate frequency)** **What users hit most** - **Intermittent server-side exception blocking login**: “Application error: a server-side exception has occurred.” - Evidence: at least **3 users** (untitled, xyz, ElizaBAO). Temporary workaround: hard refresh. --- ### 6. UX/UI — **Configuration mental model gaps (moderate severity, recurring among builders)** **What users hit most** - Confusion around **CHANNEL_IDS vs DISCORD_LISTEN_CHANNEL_IDS** behavior and filtering expectations. - Evidence: implicit asked; Odilitime clarified: channel IDs filter; listen channels bypass filtering and emit events for custom logic. --- ## 2) Usage Pattern Analysis (Actual vs intended) ### How users are actually using elizaOS 1. **Discord-first deployment** is the practical default: - Most “it’s broken” urgency is tied to Discord agents (responding in channels/DMs, permissions, audit log access). 2. **Agents as product operators**, not just chatbots: - Marketing/sales automation (LinkedIn/email outreach) planned by Thirtieth. - Support agent (“Hank”) already handling real support tasks. 3. **Prediction-market and real-time data agents** emerging quickly: - Polymarket-style competition agent requests (ElizaBAO). - Sportradar plugin shipped (NBA live data) and validated as useful. 4. **Token/migration workflows are treated like core product UX**: - Users come to Discord expecting authoritative support, safety guarantees, and deterministic eligibility outcomes. ### Emerging / unexpected use cases - **Tax-optimized token distribution mechanics** (DorianD’s buy/burn contract idea) indicates users see elizaOS ecosystem design as “programmable economics,” not just software. ### Feature requests that align with real usage - “Polymarket-like” competition agent + multi-model tournaments (aligns with prediction agent + data plugins). - Better guardrails/approvals for autonomous transactions on Safe (aligns with agents becoming operators). - Hosted/community projects (Eliza Town) demand a clearer release path and ownership model. --- ## 3) Implementation Opportunities (Concrete solutions, prioritized) Below, each major pain point includes **2–3 implementable solutions** with **Impact / Difficulty** and comparable patterns from other projects. ### A) Discord plugin regressions + DM failures 1. **Add an automated compatibility matrix + canary tests** (Impact: High, Difficulty: Medium) - CI runs minimal e2e flows: “respond in channel,” “respond in DM,” “role provider resolves user identity,” across supported Discord.js versions. - Similar approach: Discord.js ecosystem relies heavily on version-pinned integration tests; many bot frameworks maintain “smoke test bots” in CI. 2. **Introduce runtime “Doctor” diagnostics command** (Impact: High, Difficulty: Low–Medium) - `elizaos doctor discord` outputs: plugin version, required intents, permissions, audit log permission status, channel filter config, and DM capability checks. - Comparable: Homebrew “doctor”, Kubernetes “kubectl cluster-info” style debugging. 3. **Harden identity handling in DM contexts** (Impact: Medium–High, Difficulty: Medium) - Fix/guard for “User has no name or username” by falling back to user ID, fetching user object, or storing per-user metadata once seen. --- ### B) Database adapter confusion (PGLite vs Postgres/Neon) and migration failures 1. **Make DB adapter selection explicit and visible at startup** (Impact: High, Difficulty: Low) - Log a single clear line: `DB_ADAPTER=postgres (DATABASE_URL=...)` or `DB_ADAPTER=pglite (path=...)`, plus “why” if fallback occurred. 2. **Ship a “known-good” Postgres recipe** (Impact: High, Difficulty: Medium) - Provide Docker Compose + Neon quickstart, including pgvector notes and required privileges to create schemas. - Similar: Supabase and Prisma provide opinionated quickstarts that eliminate “works on my machine” DB traps. 3. **Migration preflight check** (Impact: Medium, Difficulty: Medium) - Before running migrations, check `CREATE SCHEMA` permission and extension availability; show actionable remediation. --- ### C) ElizaCloud reliability (“server-side exception” during login) 1. **Add status page + incident banner in-app** (Impact: High, Difficulty: Medium) - Reduces support load and repeated “is it down?” questions. - Similar: Vercel/Netlify style incident comms. 2. **Capture and surface a request ID + error code to users** (Impact: High, Difficulty: Low) - UI shows “Error ELC-LOGIN-500, RequestId=…” to make Discord reports actionable. 3. **Stabilize with synthetic monitoring for auth/login flows** (Impact: Medium–High, Difficulty: Medium) - Run periodic login checks; alert before users report. --- ### D) Migration eligibility mismatches + scam risk 1. **Publish an authoritative “Never send tokens to migrate” banner everywhere** (Impact: Very High, Difficulty: Low) - Pin in Discord, portal UI, docs; add a “Report scam” shortcut. 2. **Add self-serve eligibility audit UI** (Impact: High, Difficulty: Medium) - Show: snapshot block/time, addresses included, detected balances, and why an address is excluded. - Comparable: many airdrops (e.g., Optimism, Arbitrum) provide transparency pages to reduce tickets. 3. **Standardize a support intake form** (Impact: Medium–High, Difficulty: Low–Medium) - Required fields: wallet address, snapshot evidence, CEX/hardware constraints, transaction hashes (as in GitHub issue #6369). Reduces back-and-forth. --- ### E) Token/project communication + trust issues 1. **Single “Official tokens & contracts” registry page** (Impact: Very High, Difficulty: Low) - Include: token purpose, relationship to ElizaOS, contract addresses, launch method, and risk notes. 2. **Pre-announce token mechanics and timelines** (Impact: High, Difficulty: Medium) - “No CA until time X,” “tokenomics locked,” “LP procedure,” “dev wallet policy.” - Similar: reputable launches publish a “launch checklist” and enforce it. 3. **Translate ecosystem work into holder/user value narrative** (Impact: High, Difficulty: Medium) - A recurring “How this helps ElizaOS” section in updates: revenue pathways (cloud fees, plugin marketplace), user growth targets, and milestones. --- ## 4) Communication Gaps (Expectations vs reality) ### Gaps observed - **Expectation:** “If it’s mentioned by team members, it must be official and safe.” **Reality:** Users had to ask repeatedly if tokens (GOLD/CJFT/BAGS) were official; CA confirmation timing amplified mistrust. - **Expectation:** “Migration support is deterministic and secure.” **Reality:** Edge cases (Robinhood/Tangem) required manual support; scams exploit ambiguity. - **Expectation:** “elizacloud uses GPT-4 (or a known model).” **Reality:** Users asked what models are used; answers were partial (Migration Agent uses Claude Sonnet; ElizaCloud model question unanswered). ### Recurring questions that indicate onboarding/doc gaps - “Which Discord plugin/core versions are compatible?” - “CHANNEL_IDS vs LISTEN_CHANNEL_IDS—what actually happens?” - “Do you offer grants?” / “How do I apply?” - “Will CEX holdings qualify for airdrops?” - “Which tokens are official and how do they relate to ElizaOS?” ### Documentation improvements to align expectations - A pinned “Start here” for builders: **version matrix + doctor command + minimal working Discord agent**. - A pinned “Start here” for holders: **official tokens registry + migration safety + airdrop policy (even if ‘TBD’, explain process/timing)**. - Add “Model transparency” to product pages: “default model,” “configurable providers,” “what Migration Agent uses.” --- ## 5) Community Engagement Insights ### Power users & their needs - **0xbbjoker**: repeatedly unblocked users on Discord plugin/DB issues → needs better tooling (diagnostics, reproducible bug reports). - **Odilitime**: key explainer for configs, tokens, agent internals → needs canonical docs to point to instead of repeating answers. - **DigitalDiva**: high-signal “real world” integrator hitting sharp edges → ideal for a “builder beta” feedback loop (structured bug intake). - **DorianD**: advanced mechanism design proposals (distributed compute, tax-optimized airdrops) → needs a place for RFCs with technical review. - **sedano.npc**: shipping plugins (Sportradar) → needs clearer plugin publishing guidelines + discovery. ### Newcomer friction signals - Grants process unclear (“write a pitch, no promises”). - Migration safety and eligibility unclear. - Confusion around hosting/community projects (Eliza Town “user-facing version coming soon” with no timeline). ### Converting passive users into contributors - Create “Good first plugin” templates + “plugin of the week” spotlight (Sportradar as example). - Turn recurring Discord answers into doc PR bounties (“$X for documenting CHANNEL_IDS vs LISTEN_CHANNEL_IDS with examples”). - Run small “repro bounty” program: reward minimal repro repos for Discord/DB issues. --- ## 6) Feedback Collection Improvements ### Current effectiveness - **Discord is effective for rapid triage**, but: - Issues repeat because solutions are not centralized (version fixes, migration safety). - High-noise topics (token speculation) drown technical support threads. - **GitHub issues capture detailed technical cases well** (e.g., Tangem eligibility report with hashes), but many users won’t file them. ### Improvements for more structured, actionable feedback 1. **Add issue templates for top failure modes** - Discord plugin bug template (versions, intents, DM vs channel, logs). - DB/migrations template (adapter, URL, provider, permissions, error snippet). - Migration eligibility template (wallet, snapshot proof, tx hashes). 2. **Weekly “Known Issues & Fixes” post** linking to canonical docs and patched versions. 3. **In-product feedback hook (ElizaCloud)** - “Report a problem” that auto-attaches request ID + browser + agent ID. ### Underrepresented segments - **Non-Discord deployers** (Telegram, web embed, API-first) are scarcely represented in this slice. - **Teams using elizaOS for non-crypto enterprise workflows** (despite hints like support/marketing agents) aren’t providing structured feedback—likely due to lacking onboarding paths and showcases. --- ## Prioritized High-Impact Actions (Next 2–4 weeks) 1. **Ship a canonical “Official Tokens / Contracts / Relationships” registry page + pin it in Discord** (trust + support load reduction). 2. **Implement `elizaos doctor` (Discord + DB) and publish a version compatibility matrix** (cuts repeated plugin/setup failures). 3. **Fix Discord DM identity/role-provider path (“User has no name or username”) and add DM canary tests in CI** (unblocks a primary real-world usage mode). 4. **Add ElizaCloud reliability basics: request ID surfaced to users + status/incident banner** (turns “it’s down” into actionable reports). 5. **Migration safety + transparency pack: “never send tokens” banner + self-serve eligibility audit view** (reduces scams and escalations; increases perceived professionalism).