## User Feedback Analysis — 2026-01-20 ### Data sources reviewed - Discord daily summaries: 2026-01-17, 2026-01-18, 2026-01-19 - GitHub daily/project summaries (notably: Issue #6382; PR review concerns around #6286) - Ecosystem maintenance notes (v1.7.2 release; stability fixes; dependency updates) --- ## 1) Pain Point Categorization (Top recurring 5–7) > Quant note: Across the last 3 Discord summaries, **23 distinct questions** were captured in “Key Questions / Unanswered Questions”; **14 were explicitly left unanswered (~61%)**, indicating a recurring “stuck on basics / unclear status” problem more than isolated troubleshooting. ### 1. Documentation — Missing “how it actually works” guides (high frequency, high severity) **What users hit:** - **Token migration clarity gaps**: “What happens if someone doesn't migrate… lost/redistributed/burned?” (unanswered) - **Roadmap/status ambiguity**: “Where is the Rust port mentioned?” (unanswered on Discord despite active Rust/WASM work elsewhere) - **Integration architecture docs missing**: - Polymarket **Safe proxy wallet** behavior vs exported private key mismatch (needed explanation and a canonical guide) - **“Is X endorsed?” questions**: “Is youtoy an elizaos-backed project?” (unanswered) **Who it affects most:** newcomers and evaluators trying to decide whether to build or integrate. --- ### 2. Integration — Real-world deployments failing at the edges (high severity) **What users hit:** - **Discord plugin ↔ ElizaCloud compatibility** reported as a blocker (unresolved in discussion). - **Polymarket CLOB API blocked by Cloudflare (403)** when called from **Supabase Edge Functions**; proxy/cert limitations (UnknownIssuer) and inability to set HTTP_PROXY/custom CAs in that environment. - Confusion around wallet architecture (EOA vs Safe multisig proxy) impacting plugin usability. **Who it affects most:** builders trying to ship “production-ish” agents (trading, prediction, automation). --- ### 3. Technical Functionality — Correctness + architecture concerns in core flows (medium frequency, high severity when hit) **What users hit:** - Core-dev review concern: PR #6286 implementation “feels wrong,” recommendation to refactor to **`ensureEntities` accepting a list** (batch semantics) rather than per-entity handling. - Practical reliability concerns show up as “it works in one group but not another” (Telegram moderation false positives variability). **Who it affects most:** contributors, plugin authors, and anyone running multi-step workflows at scale. --- ### 4. UX/UI — Dashboard interaction bug blocks repeated creation (lower frequency, medium severity) **What users hit:** - GitHub Issue **#6382**: “Clicking outside an input box does not return the user to the original window when attempting to create an item again.” **Who it affects most:** users in the app/dashboard creation loop (onboarding + iteration). --- ### 5. Performance & Reliability — Stability improving, but still a user-visible theme (medium frequency, high severity historically) **What users hit (and what improved):** - Infinite rebuild loops in dev-watch mode (fixed in v1.7.2 line of work). - Race condition in credit deduction for streaming endpoints (TOCTOU; fixed with deduct-before/reconcile-after). - Builders pushing beyond TypeScript limits for high-frequency trading; requests leaning toward **Rust plugin rewrites** and robust messaging (NATS Jetstream). **Who it affects most:** advanced / high-throughput users (trading, multi-agent orchestration). --- ### 6. Community — Channel organization + unanswered questions create “project inactivity” perception (high frequency, medium severity) **What users hit:** - Request to separate **job/skill postings** to reduce clutter; concern that clutter makes the project “look dead.” - Multiple “anyone need a dev?” posts went unanswered, suggesting missed opportunities to onboard contributors. **Who it affects most:** newcomers and potential contributors evaluating community health. --- ### 7. Product/Platform Expectations — “Network” launch timing and capabilities unclear (medium frequency, high severity for planners) **What users hit:** - Strong desire to “run nodes” / “launch the network” (DorianD), with physical infrastructure plans. - Questions about provisioning agents on ICP/enclaves, protocols (8004/402), oracle-like agent behavior—discussion exists, but no clear official positioning/timeline surfaced in user-facing channels. **Who it affects most:** infra operators, serious builders planning deployments. --- ## 2) Usage Pattern Analysis (Actual vs intended usage) ### How users are actually using elizaOS 1. **Moderation operations (Telegram)**: “Solimp” bot with exponential mute timeouts and admin review workflows—this is a concrete, operational deployment pattern (not just demos). 2. **Trading/prediction market automation**: - Polymarket integration (wallet proxy + CLOB API + serverless hosting realities) - High-throughput token monitoring and multi-DEX execution concepts (1M tokens) with messaging backbones (NATS). 3. **Infrastructure/network aspirations**: - Interest in running nodes, secure container provisioning, agent registration, and protocols for economically-active agents. 4. **Docs as machine-consumable knowledge**: - Intent to optimize docs for LLM consumption (kapa.ai style), and to use the knowledge repo for RAG pipelines. ### Where this diverges from “intended” expectations - Users expect “plugin + cloud” integrations to work in serverless environments by default; reality: Cloudflare blocks, cert restrictions, and wallet proxy architectures require specialized handling. - Users treat Discord as a support desk; response rates suggest it behaves more like a discussion forum without triage/ownership. ### Emerging / unexpected use cases - **Educational moderation with muting-only escalation** (instead of bans) + acceptance of occasional false positives. - **Agentic finance stack**: wallets, proxy accounts (Safe), micropayments (x402), and exchange listing speculation—users mix product usage with token/investment narratives. ### Feature requests aligning with actual usage - Built-in community features inside apps (reduce dependence on external platforms). - Robust integration “recipes” for: Cloudflare-safe networking, serverless constraints, proxy wallet flows. - Better dev workflow stability (already trending positively with v1.7.2 fixes). --- ## 3) Implementation Opportunities (2–3 per major pain point) ### A) Documentation gaps (migration, Rust/WASM status, wallet architecture) **High impact / Low–Medium difficulty** 1. **Create a “Known Answers” FAQ pinned in Discord + mirrored in docs**: - Token migration outcomes (authoritative) - Rust/WASM runtime status and where to find it - “Is project X affiliated?” policy (what can/can’t be claimed) 2. **Add “Architecture Notes” docs for high-confusion integrations**: - Polymarket: Safe proxy wallet model, signer vs builder address, how exported keys relate (and don’t) 3. **Publish “Support boundaries” guidance**: - What ElizaCloud supports vs self-host; expected limitations in Edge/serverless **Comparable patterns in other projects** - Kubernetes, Supabase, and Stripe maintain “Concepts” + “How-to” separation; the missing piece here is “Concepts” for wallet/proxy/network architecture. --- ### B) Integration failures (Discord↔Cloud, Polymarket↔serverless, Cloudflare) **High impact / Medium difficulty** 1. **Provide “reference deployments”** (repo templates): - Self-hosted minimal node (Docker Compose) with stable egress + cert store - A “serverless-safe” example only where feasible (and explicitly list limitations) 2. **Add an “Egress & Anti-bot constraints” integration guide**: - Dedicated/static IP recommendations - Browser-mimic headers where legally acceptable - When to stop and move to self-host (decision tree) 3. **Improve plugin diagnostics**: - Structured errors for: “Cloudflare blocked,” “proxy wallet required,” “wrong address type” - Preflight checks in plugin-polymarket to detect Safe proxy requirement early **Comparable patterns** - Many Web3 SDKs (e.g., wallet providers) add “preflight network checks” and “capability detection” to fail fast with actionable errors. --- ### C) Technical correctness/maintainability (ensureEntities batching, multi-step retry/refactor) **Medium–High impact / Medium difficulty** 1. **Refactor entity ensuring to support batch semantics** (as suggested): - Introduce `ensureEntities(entityRefs[])` and update call sites 2. **Add performance + correctness tests around entity operations**: - Verify no N+1 patterns under multi-step flows 3. **Adopt “design note required” for core behavior changes**: - Lightweight ADR (Architecture Decision Record) for PRs like #6286 **Comparable patterns** - Rust and Go ecosystems commonly require small ADRs for runtime semantics changes; React uses RFCs for cross-cutting changes. --- ### D) UX/UI dashboard bug (#6382) **High impact / Low difficulty** 1. **Fix focus/blur handling** for create flows: - Clicking outside should cancel/close modal or restore prior state predictably 2. **Add an E2E regression test**: - Cypress/Playwright test: create → click outside → create again should work 3. **Add inline guidance**: - If modal dismissed, show toast or restore “draft” state **Comparable patterns** - Notion/Linear modal flows preserve drafts and make dismissal explicit to avoid “lost context” confusion. --- ### E) Community organization + unanswered questions **High impact / Low–Medium difficulty** 1. **Create dedicated Discord channels + routing**: - `#jobs-and-collab`, `#help`, `#integrations`, `#token-and-migration` 2. **Introduce a lightweight triage rotation**: - Weekly “on-call” maintainer/community helper to mark answered/unanswered and link to docs/issues 3. **Convert repeated questions into docs automatically**: - Bot that detects repeated phrases (“Rust port”, “migration”, “youtoy”) and suggests canonical links **Comparable patterns** - Rust, Next.js, and many OSS Discords use forum channels + “solved” threads + maintainer rotations to keep support scalable. --- ## 4) Communication Gaps (Expectations vs reality) ### Recurring expectation mismatches - **“Where is the network?”** Users are planning physical infra, but there’s no visible “what exists now vs later” statement. - **“Cloud/serverless should work”** vs reality of anti-bot defenses, cert constraints, and proxy wallets. - **“Rust port exists”** vs discoverability: users asked in Discord and got no pointer, despite active Rust/WASM efforts. ### Recurring questions indicating onboarding gaps - Token migration consequences (unanswered) - Project affiliations/endorsements (youtoy) (unanswered) - Rust port location/status (unanswered) - Exchange listing rumor verification (Bithumb) (unanswered) - “Any dev work needed?” posts (unanswered; indicates missing contributor intake flow) ### Specific improvements to align expectations - Add a **single canonical “Project Status” page** updated weekly: - Network status (planned vs live), Rust/WASM status, supported deployment modes - Add an **“Affiliations & announcements policy”** page: - How listings/partnerships are communicated; how to verify claims --- ## 5) Community Engagement Insights ### Power users (and what they need) - **ElBru** (Telegram moderation): needs packaged, reusable moderation patterns; tooling for false-positive tuning and audit logs. - **sayonara** (wallet architecture support): needs integration docs standardized so answers aren’t repeated ad hoc. - **Chucknorris** (high-performance trading): needs Rust plugin patterns, high-throughput messaging guidance, and clear “TS vs Rust” boundaries. - **DorianD** (network/node ops): needs a network roadmap, node requirements, and an operator’s guide. - **Jin** (docs + data pipelines/jintern): needs structured knowledge repo interfaces and MCP-ready documentation conventions. - **Odilitime** (core review): needs maintainability guardrails (ADRs, batching patterns, perf tests). ### Newcomer friction signals - “Where do I post job/skills?” - “Is X official?” - “Where is Rust port?” - “Does plugin work with ElizaCloud?” ### Converting passive users into contributors - Add a **“Help Wanted: Integrations”** board (Discord + GitHub label) with clear acceptance criteria. - Provide a **1-hour/week onboarding call** for new devs (“pick a task, ship a PR”). - Create “first PR” kits: docs fixes, integration templates, E2E tests for known UX bugs. --- ## 6) Feedback Collection Improvements ### Effectiveness of current channels - **Discord captures lots of questions but has low closure** (≈61% explicitly unanswered in captured summaries). - **GitHub issues capture actionable bugs** (e.g., #6382) but may miss broader “expectation gaps” unless prompted. ### Improvements for more structured, actionable feedback 1. **Discord → GitHub handoff workflow** - A bot/button: “Report as issue” that creates a prefilled GitHub issue (integration + logs + environment) 2. **Weekly “Top 5 unanswered” digest** - Auto-generated list posted and assigned to maintainers/community helpers 3. **Standard integration report template** - Hosting environment (serverless vs self-host), egress IP, region, headers, plugin version, error IDs ### Underrepresented segments - **Non-Web3 builders** (most visible usage is finance/moderation; fewer signals from typical SaaS/internal-tool users) - **ElizaCloud-only users** (compatibility question surfaced, but limited detail—suggest a Cloud feedback form) - **UI-first users** (only one dashboard UX issue captured; likely underreported vs actual impact) --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Publish a canonical “Project Status + FAQ” (docs + pinned Discord)** - Cover: token migration outcomes, Rust/WASM status/link, network roadmap snapshot, affiliation policy, exchange-listing rumor policy. 2. **Ship “Reference Deployments” for integrations** - At minimum: Polymarket (self-hosted egress) + Discord (ElizaCloud compatibility matrix). - Include decision tree: serverless vs self-host, and why. 3. **Fix and regression-test dashboard create-flow bug (#6382)** - Add E2E test to prevent recurrence. 4. **Reduce unanswered Discord questions with lightweight triage** - New `#help` forum + solved tagging + weekly rotation + auto-digest of unanswered items. 5. **Implement/standardize batch entity operations (`ensureEntities(list)`) + add perf tests** - Addresses maintainability concerns raised in core-dev review and reduces future runtime friction.