## User Feedback Analysis — 2026-01-31 (based on 2026-01-28 to 2026-01-30 community + Jan GitHub activity) ### Data Notes / Quantification Approach - Source mix: Discord (discussion/coders/core-devs/partners) + GitHub issues/PRs referenced in the Jan 2026 summary. - “%” figures below are based on **~22 distinct feedback items** extracted from the provided logs (questions, bug reports, incidents, repeated confusions). They should be treated as directional rather than statistically rigorous. --- ## 1) Pain Point Categorization (Top recurring issues) ### 1. Integration — Token migration portal eligibility & reliability (highest frequency, high severity) **Signal (≈32% of feedback items; multiple users across channels):** - Migration portal shows **“0 eligible”** despite long-held tokens (e.g., Arkanac, TonKLa; similar reports earlier). - Snapshot/eligibility mismatches with specific wallet setups (hardware wallets like Tangem; Phantom/Solflare). - **429 “Too many requests”** on page load before wallet connection (jaistklaas). - ETH-chain liquidity confusion causing perceived **98% losses** when swapping back (Sarthak), indicating users are attempting the “wrong path” due to unclear flow. **Most affected users:** - Token holders (especially non-standard wallet setups: LP positions, multiple wallets, hardware wallets, Solana wallets like Phantom/Solflare). --- ### 2. Community / Security — Active scams impersonating support + a reported wallet theft (critical severity) **Signal (≈14% of feedback items; very high severity):** - Users receiving **friend requests / DMs** from “ticket support” impersonators (FeRhaT_@). - **Reported hack/theft** after creating a support ticket (coolart), with funds stolen from Phantom and Metamask. - Repeated moderator guidance: “official support never DMs.” **Most affected users:** - Newcomers and token migrators under time pressure. --- ### 3. Technical Functionality — Regressions and correctness bugs in core runtime / plugins **Signal (≈18% of feedback items; high severity for builders):** - **Eliza 1.7.2 action callback ordering bug**: messages arrive reversed and structured return text omitted (Victor Creed). Breaks plugin behaviors relying on ordered callback messaging (`plugin-sql`, `plugin-openai`, `plugin-bootstrap`). - **Provider selection fails in one-shot mode** on develop branch (core-devs). - Plugin install/module resolution errors (`Cannot find module '@elizaos/plugin-web-search'`) (DigitalDiva). - Embeddings/provider reliability issues (OpenRouter embeddings failing for knowledge plugin; users report only OpenAI works reliably). **Most affected users:** - Plugin developers, teams building production agents, and anyone on develop branch. --- ### 4. Performance / Reliability — Lack of integration testing + repeated breakages across versions **Signal (≈14% of feedback items; medium-high severity):** - Core dev frustration: recurring breakages in “1x,” strong need for **integration tests for 2x** monorepo. - Plugin testing gaps; Stan ⚡ building a test framework for plugin-n8n-workflow as a pattern. - Related reliability friction: SSE streaming MIME-type mismatch errors; users recommend socket.io. **Most affected users:** - Core maintainers, plugin authors, and users deploying agents with streaming / long-running workflows. --- ### 5. Documentation — Onboarding & “how it works” gaps (especially around token + Jeju) **Signal (≈14% of feedback items; medium severity but broad impact):** - Repeated “what is the value proposition / token utility?” questions (Taco, gby, others). - Jeju staking mechanism exists in repo *.md files, but users are still asking basic questions (gby) → docs are not discoverable/approachable. - Git workflow explanations needed in chat (commit vs PR); indicates onboarding assumes too much Git familiarity. - Migration flow ambiguity: users try to swap on ETH, encounter zero liquidity, and interpret as loss. **Most affected users:** - New developers, token holders, potential contributors, non-crypto-native builders. --- ### 6. UX/UI — Missing “consumer assistant” affordances vs competitors (mobile + voice) **Signal (≈9% of feedback items; strategic severity):** - Comparison to Clawdbot/Moltbot/OpenClaw: ElizaOS perceived as powerful multi-agent framework but lacks: - **Mobile footprint** - **Voice interface** - “Personal assistant” integration surface (calendar/socials) out-of-the-box **Most affected users:** - Users evaluating ElizaOS as a daily assistant rather than a framework. --- ### 7. Community / Communication — Trust and governance concerns (runway, decentralization, allocations) **Signal (≈9% of feedback items; medium severity, high reputational risk):** - Runway stated as **8 months**, but uncertainty whether held in stablecoins vs volatile assets. - Token allocation controversy (40% team vs community after 1:10 increase). - Privacy/decentralization tension: USA-based ops + privacy policy prompts skepticism. **Most affected users:** - Token holders, ecosystem partners, and builders deciding whether to commit. --- ## 2) Usage Pattern Analysis (actual vs intended use) ### How users are actually using ElizaOS 1. **As a plugin-driven agent runtime** where the community expects “it just works” across providers/plugins (e.g., callback ordering, provider selection, module resolution). 2. **As an automation hub** (strong pull toward N8N workflows, social integrations, OAuth) rather than only chat agents. 3. **As an ecosystem platform** (Jeju network + staking + “agents as service providers”), not just OSS framework. 4. **As a migration/token utility product** (significant user attention is on token mechanics and portal UX, even among non-builders). ### Emerging / unexpected use cases - **Agent social networks**: Moltbook (“Reddit for agents”) and interest in agents interacting with each other, possibly using private agent-only communication schemes. - **Model routing layer (“ElizaRouter”)**: routing to small/large models based on complexity/cost/load; interest in Rust/TS implementation. - **Persona-driven social presence**: desire for a more “alive” X/Twitter agent identity for @elizaos (marketed like successful AI personas). ### Feature requests aligning with real usage - OAuth + social account linking “connection page” (Sam; Composio integration; Stan’s existing plugin). - Voice + mobile presence (from competitor analysis, repeatedly cited as adoption driver). - Robust workflow automation (N8N integration as “primary automation layer for Eliza App”). --- ## 3) Implementation Opportunities (solutions per major pain point) ### A) Migration portal: “0 eligible”, snapshot mismatches, 429 errors **1) Add a self-serve “Eligibility Debug” panel (High impact / Medium difficulty)** - Show: snapshot wallet detected, snapshot balance, excluded reasons (LP, post-snapshot, wrong chain, different wallet), RPC source used. - Provide a “download diagnostics” JSON users can attach to tickets. - Similar pattern: many airdrop/migration apps (e.g., Uniswap airdrop claim tools) provide explicit eligibility reasons and links to on-chain proof. **2) Implement a rate-limit friendly frontend + backend caching (High impact / Medium difficulty)** - Fix 429-before-connect by: - deferring expensive calls until after wallet connect, - caching snapshot lookups by address, - using CDN edge caching for static snapshot proofs, - adding exponential backoff + user-friendly retry. - Similar pattern: Cloudflare-backed claim sites with cached proofs (Merkle proofs) reduce RPC calls. **3) Create a “manual verification lane” for hardware wallets & edge cases (Medium impact / Low-medium difficulty)** - Simple form: address, wallet type (Tangem/Phantom/Solflare), tx links, screenshot. - Output: tracked GitHub issue or ticket queue with SLA expectations. - Similar pattern: L2 airdrops and token migrations commonly run a manual exceptions queue. --- ### B) Scam / support impersonation and security incident handling **1) Harden support UX with in-product/portal warnings and signed support identity (High impact / Low difficulty)** - Prominent banner in migration portal and Discord ticket flow: - “Support will never DM you” - “Only trust replies inside this ticket system” - Add “copyable checklist” before users proceed. - Similar pattern: major wallets/exchanges pin anti-scam banners at every sensitive step. **2) Implement “Verified Support” automation in Discord (High impact / Medium difficulty)** - Auto-delete messages that mention “support DM me” patterns; auto-DM the user from a bot with safe guidance. - Create a `/report-scam` command that forwards metadata to mods. - Similar pattern: large Discord communities use AutoMod + custom bots for scam detection. **3) Publish an incident response mini-playbook (Medium impact / Low difficulty)** - What to do if you clicked a link / connected wallet / got drained (revoke approvals, rotate keys, move funds). - This reduces repeated panic threads and increases trust. --- ### C) Core correctness bugs: callback ordering + one-shot provider selection regression **1) Add deterministic message sequencing guarantees (High impact / Medium difficulty)** - Introduce an internal “message queue” or ordered event emitter for callback messages so plugins can rely on ordering. - Add tests that assert order: initial feedback → structured return → detailed callback. - Similar pattern: Bot frameworks (e.g., Hubot/Slack bots) treat outgoing messages as an ordered queue per interaction. **2) Expand regression test coverage for one-shot mode provider selection (High impact / Medium difficulty)** - Add minimal integration tests that run: - one-shot with each provider, - failure fallback behavior, - expected selection logic. - Gate merges to develop with these tests. **3) Improve plugin installation experience (Medium impact / Medium difficulty)** - Provide a CLI “doctor” command: - checks Node/bun versions, - validates package.json resolutions, - ensures plugin is installed and resolvable. - Similar pattern: Expo/Next.js “doctor” commands reduce environment debugging. --- ### D) Integration testing gaps across monorepo and plugins **1) Standardize a plugin test harness template (High impact / Medium difficulty)** - Adopt Stan ⚡’s plugin-n8n-workflow `__tests__` approach as a “golden template.” - Publish: minimal mocks, runtime harness, CI workflow snippet. - Similar pattern: VS Code extensions and Terraform providers often ship a standardized acceptance test harness. **2) Add “canary matrix” CI for core + top plugins (High impact / High difficulty)** - Nightly builds on: - core + plugin-bootstrap + plugin-sql + plugin-openai + plugin-discord - run minimal scenario scripts (create agent → run one-shot → run multi-step → run streaming) - Prevents silent breakage across repos. **3) Introduce version compatibility policy + badges (Medium impact / Low-medium difficulty)** - “Compatible with core v1.7.x / v2.x” badges and a simple compatibility table in docs. --- ### E) Documentation gaps: token utility, Jeju staking, migration instructions **1) Replace scattered explanations with 2 canonical pages (High impact / Low difficulty)** - “Token Utility & Economics (Plain English)”: - what token does today vs later, - buyback claims explained with examples, - what happens if you don’t migrate. - “Migration: The Only Correct Paths”: - step-by-step by chain/wallet type, - common failure modes (“0 eligible”, LP positions, hardware wallets). - Similar pattern: Ethereum L2 bridges have a single “bridge guide” page with troubleshooting. **2) Add “Jeju for operators” quickstart (Medium impact / Medium difficulty)** - A one-pager: what is staking, what services exist (compute/storage/cron), what’s placeholder ETH mean, what’s live vs planned. **3) Add onboarding for OSS contributors (Medium impact / Low difficulty)** - Short Git primer already being explained in chat—convert to docs: - fork vs PR vs commit, - how to submit docs PRs to elizaOS/docs (sayonara’s workflow). --- ### F) UX feature gap vs personal assistant competitors (mobile + voice) **1) Publish a “reference implementation” voice + mobile bridge (High impact / High difficulty)** - Even a minimal: - mobile push-to-talk, - voice input/output (ElevenLabs or OS TTS), - message relay to agent runtime. - Similar pattern: Home Assistant and OpenAI “realtime voice” demos win adoption via reference apps. **2) Provide “assistant starter kit” templates (High impact / Medium difficulty)** - Prewired: calendar + socials + voice + mobile notifications, even if limited. - Helps ElizaOS compete with assistant-first products while staying framework-first. --- ## 4) Communication Gaps (expectations vs reality) ### Repeated expectation mismatches - **“Why is migration broken?”** → reality: eligibility depends on snapshot timing, wallet location, LP status; portal doesn’t explain exclusions, leading users to assume bug/scam. - **“Token should have obvious utility now”** → reality: utility is partly forward-looking (Jeju gas, product currency, buybacks), but users can’t “touch” the product yet, increasing skepticism. - **“ElizaOS is an assistant like Clawdbot”** → reality: it’s a multi-agent framework; assistant surfaces (voice/mobile) are not first-class yet. ### Recurring questions that indicate onboarding gaps - Where to go when migration fails (portal vs ticket). - Why “0 eligible” happens and how to verify snapshot holdings. - Whether support will DM (scam confusion repeats). - Basic Git contribution workflow (commit vs PR). - SSE streaming setup errors (MIME_TYPE_MISMATCH) and recommended transport (socket.io). ### Specific improvements to align expectations - Add a **“What ElizaOS is / isn’t”** section on the homepage/docs: - “Framework-first today; assistant experiences are in progress.” - Pin a single, authoritative migration post in Discord + docs, and mirror it inside the migration portal UI. - Add an explicit “Current status of Jeju / what’s live now” checklist to reduce speculation. --- ## 5) Community Engagement Insights ### Power users and their needs (high leverage) - **DorianD**: strategy + ecosystem integration + competitive analysis (Moltbook/Jeju, router concept). Needs: clear product surface to integrate with, security primitives for networking agents, and roadmap clarity. - **Stan ⚡**: building testing frameworks + OAuth/workflow integration. Needs: standardized plugin CI patterns, clearer plugin APIs/contracts. - **jin**: infrastructure automation (MCP support, repo/channel tracking) + onboarding improvements. Needs: prioritized docs IA, bootstrapping skill integration points. - **Odilitime**: core maintainer triaging migration, plugins, and dev workflow pain. Needs: reduced support load via self-serve diagnostics and better regression tests. - **sayonara**: docs workflow maintainer. Needs: a steady pipeline of doc issues and clear ownership boundaries. ### Newcomer questions (onboarding friction indicators) - CLI/project creation failures (“front door” problems) and environment issues. - Plugin installation/module resolution confusion. - Migration safety/scam fears. - Streaming transport setup confusion. ### Converting passive users into contributors - Create “good first issue” tracks tied to current pain: - migration portal UX copy fixes, - docs improvements (migration/Jeju/token), - plugin test harness template adoption. - Host a monthly “Plugin Quality Day” where maintainers help contributors add tests to one plugin using the standardized harness. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** is effective for rapid triage but produces repeated Q&A and high scam risk; solutions don’t persist well. - **GitHub issues** capture actionable bugs (e.g., migration snapshot mismatch, runtime correctness issues) but many user problems never become well-formed issues (especially token holders). ### Improvements for more structured feedback 1. **Dedicated intake forms** (migration + security + runtime bugs) - Required fields: wallet type, chain, address, screenshot, error code, steps to reproduce. 2. **Portal-integrated telemetry (opt-in)** - Track: frequency of “0 eligible,” 429s, wallet types, RPC failures. 3. **Discord “Known Issues” bot panel** - When users type “0 eligible” or “429,” bot replies with the canonical checklist and links to the correct form. ### Underrepresented user segments - Non-Discord users attempting migration (likely many) — their failure modes aren’t visible unless they file GitHub issues. - Less technical builders who want “assistant features” but won’t engage in core-dev channels. - Operators who might run Jeju services (compute/storage) — very little direct operator feedback beyond conceptual discussion. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Ship migration portal “Eligibility Debug” + fix 429-on-load behavior** (highest immediate user pain + reduces support/scam vulnerability). 2. **Launch an anti-scam hardening package**: portal banner + Discord automation + short incident-response doc (critical severity, fast to implement). 3. **Fix/triage core correctness regressions**: one-shot provider selection + action callback ordering bug, with regression tests added (protects builders and ecosystem credibility). 4. **Publish two canonical docs pages**: “Migration (by wallet/chain)” + “Token utility & Jeju status (plain English)” (reduces repeated confusion and expectation gaps). 5. **Adopt a standardized plugin test harness template (based on plugin-n8n-workflow)** and require it for new/updated plugins (compounds quality over time).