## User Feedback Analysis — 2026-05-07 (based on 2026-05-04 to 2026-05-06 signals) ### Data snapshot (what we actually saw) - **Discord (2026-05-06)**: 3 distinct user inquiries captured; **2/3 (67%) went unanswered** (cloud cost/Mac mini viability; Hyperfy connectivity). 1/3 was answered (where ElizaCloud lives after consolidation). - **GitHub (May-to-date summary provided)**: 14 new issues, 13 closed (high closure rate). “Top issues” skew toward **auth/config drift, connector reliability, and DB/schema/migration gaps**. --- ## 1) Pain Point Categorization (top recurring 5–7) ### 1) Documentation — Cloud/self-hosting clarity gaps (High frequency, Medium severity) **What users struggle with** - **“Where is ElizaCloud now?”** and whether there is a dedicated update stream/changelog (asked by *avant_lakshman*, answered by *shawmakesmagic*: consolidated into `github.com/elizaOS/eliza`). - **Deployment cost / hardware feasibility** questions (e.g., *guru0*: “expected costs… twitter bot… Mac mini?”) remained unanswered, indicating missing “quick answers” docs. - Confusion amplified by infrastructure changes (migration away from Vercel, “cheaper container solutions”) without a user-facing migration note. **Examples** - Discord: request for an “ElizaCloud-specific chat/news stream/update log”. - Discord: “expected costs… Mac mini?” (unanswered). --- ### 2) Integration — Connector/integration status uncertainty (Medium frequency, Medium severity) **What users struggle with** - Users ask whether specific integrations still work / are still supported (e.g., *binarycookies*: “Does elizaos still connect to Hyperfy?” — unanswered). - This mirrors broader connector reliability themes in GitHub issues (e.g., Telegram polling races causing message loss; Slack handler error paths flagged by automated review). **Examples** - Discord: Hyperfy connectivity question unanswered. - GitHub: Telegram “dual poller” race causing **silent message loss** (#7245, closed), Slack plugin merge review flags potential silent drops if Slack API errors aren’t handled defensively (PR review notes on #7375). --- ### 3) Technical Functionality — Auth/config format drift breaks onboarding (Medium frequency, High severity) **What users struggle with** - Real-world auth files change shape (e.g., Codex CLI, Anthropic subscription flows), but detection/import paths lag behind → UI shows “install required” / 401s / misrouting. - The failure modes are often **non-obvious** (silent filtering of missing preload; “invalid credentials” even with valid tokens). **Examples** - GitHub issue: Anthropic “stealth” preload file missing on fresh clone → OAuth subscription users get 401s (#7210, closed). - GitHub issue: Codex CLI auth detection misses modern `tokens.access_token` shape (#7243, closed). --- ### 4) Technical Functionality — Schema/migrations drift breaks core chat state (Lower frequency, Very high severity) **What users struggle with** - Missing DB tables in plugin-sql runtime migrator caused cascading provider failures, empty state composition, and “parsing error” user-facing failures on fresh DBs. **Example** - GitHub issue: drizzle `pgTable` defs missing for `entity_identities`, etc. causing chat unusable on fresh PGLite (#7222, closed). --- ### 5) UX/UI — Failure states surface as generic errors; users can’t self-diagnose (Medium frequency, Medium severity) **What users struggle with** - Several technical failures present as generic UI freezes or parsing errors, not “actionable next steps”. - Discord demonstrates “question asked → no response” patterns, which increases perceived product opacity. **Example** - GitHub issue: duplicate client class meant dozens of UI calls become “is not a function”, freezing chat input (#7244, closed). --- ### 6) Community — Unanswered questions + expectation management friction (Medium frequency, Medium severity) **What users struggle with** - Newcomers ask basic deployment/integration questions in *#coders* and get no reply (2/2 unanswered in that snippet). - Project-structure discussion indicates expectation mismatch around founder responsibilities (token price vs product), with warnings about bans (can discourage “honest confusion” questions if tone isn’t carefully handled). **Examples** - Discord: multiple unanswered technical questions. - Discord: governance clarification by *Shaw* (“fair launch, builders, founder focuses on product, not token price”). --- ### 7) Community/Security — Persistent scam warnings (Low frequency in provided slice, High severity) **What users struggle with** - Recurrent need for scam warnings suggests ongoing impersonation/DM scams risk; newcomers are likely most vulnerable. **Example** - Discord (2026-05-05): multiple scam warnings issued. --- ## 2) Usage Pattern Analysis (actual vs intended) ### Observed “actual usage” - **Agent deployment as social bots**: users explicitly want Twitter-bot style deployments (*guru0*), and ask about low-cost hosting + consumer hardware (Mac mini). - **Ecosystem-as-infrastructure**: discussion frames elizaOS as something builders deploy and monetize (Cloud domains, x402 payments, “build and monetize your own apps”). - **Connector-first adoption**: questions cluster around “does it connect to X?” (Hyperfy, Telegram reliability), suggesting connectors are a primary decision driver. ### Intended usage (implied by project direction) - Build/monetize apps on top of Eliza infrastructure (Cloud, monetized container apps/domains). - Scale to many agents; focus on architecture, payments, and a general-purpose model (eliza-1 training). ### Emerging / unexpected use cases - **Payment rails as a first-class feature**: excitement around x402 default payment methods (elizaOS + DegenAI) implies users want “agent monetization primitives” baked in, not bolted on. - **“Cloud vs self-host” ambiguity**: users want Cloud-like convenience but self-host economics; they ask for cost clarity and minimal-hardware paths. ### Feature requests that align with real usage - “How much will this cost to run?” → needs a cost estimator + recommended deploy presets. - “Does it connect to Hyperfy?” → needs an integration status matrix + tested versions. --- ## 3) Implementation Opportunities (2–3 concrete solutions per major pain point) ### A) Cloud/self-hosting documentation clarity **High impact / Low–Medium effort** 1. **Create a single “Where is ElizaCloud?” landing doc** in `elizaOS/eliza` that includes: - repo path(s), what moved, what’s deprecated, and “what to use now” - a short changelog section for infra moves (Vercel → containers) 2. **Add a “Deployment Quickstarts” matrix**: Twitter bot, Discord bot, Telegram bot, web app; each with: - supported providers, estimated monthly cost ranges, and minimal hardware 3. **Add a pinned Discord “Deployment FAQ”** and route repetitive questions there via an auto-responder. *Comparable approach*: Home Assistant and Ollama communities maintain “hardware guidance” pages and “known-good setups” tables; Kubernetes projects maintain “getting started” guides with environment prerequisites. --- ### B) Integration/connector status uncertainty (Hyperfy, Telegram, Slack, etc.) **High impact / Medium effort** 1. **Publish a “Connector Compatibility & Status” page**: - “supported / experimental / deprecated” - last tested commit/version - known issues (e.g., Telegram polling constraints) 2. **Add lightweight health checks + diagnostics**: - at runtime boot, detect conflicting connector ownership (e.g., “two pollers for same Telegram token”) and error loudly (not silently). 3. **Close the loop in Discord**: weekly “Integration status roundup” message in a dedicated channel. *Comparable approach*: LangChain and OpenTelemetry ecosystems maintain integration/compatibility matrices and “known issues” sections; many OSS projects use “status dashboards” even if minimal. --- ### C) Auth/config drift (Codex/Anthropic subscription formats, etc.) **High impact / Medium effort** 1. **Schema versioning + migration for credential imports** - Store `authSchemaVersion` alongside imported credentials; migrate on read. 2. **Fail-loud preflight checks** - If a feature depends on a file/preload, log a clear warning/error (e.g., missing `claude-code-stealth.mjs` should be prominent). 3. **Add “Credential Doctor” UI panel** - Show “detected: codex tokens found / provider enabled? / last test call status” - Provide one-click “re-import” from detected sources. *Comparable approach*: Docker Desktop and VS Code extensions often include “doctor” commands; Terraform providers frequently include “validate credentials” checks and actionable errors. --- ### D) DB/schema/migration drift (plugin-sql missing tables) **Very high impact / Medium effort** 1. **Add a boot-time schema sanity check** in plugin-sql: - compare abstract schema barrel vs drizzle tables; error with explicit missing list. 2. **CI guardrail** - test that runtime-migrator creates all referenced tables on fresh PGLite. 3. **Improve user-facing error mapping** - translate “Failed query: SELECT … entity_identities” into “Your DB schema is missing tables; run migration X / update plugin-sql to version Y”. *Comparable approach*: Prisma and Rails ecosystems fail fast on missing migrations; many projects add CI “migrate from empty DB” tests. --- ### E) Unanswered community help requests (Discord support throughput) **High impact / Low–Medium effort** 1. **Introduce a “triage rotation” for #coders** - even 1–2 named people per day with a lightweight SLA (“ack within 12h”). 2. **Add a “Solved” workflow** - threads + tags; unanswered questions get auto-bumped. 3. **Convert repeated questions into docs automatically** - use a bot to suggest existing docs; if none, create a stub issue “Docs: answer X”. *Comparable approach*: Kubernetes SIG triage and Rust community “help channels” use rotations + structured tagging; many Discord OSS communities use “forum-style” channels for Q&A to reduce loss. --- ## 4) Communication Gaps (expectations vs reality) ### Gap 1: “Cloud has its own product surface” vs “Cloud is now just part of the monorepo” - User expectation: separate update stream, separate channels. - Reality: consolidated repo; infra changes ongoing. **Fix**: a clear “Cloud release notes” section (even weekly) and a dedicated Discord channel for Cloud updates. ### Gap 2: “Connectors work if enabled” vs real-world constraints (polling exclusivity, message loss) - Users assume turning on Telegram/Slack “just works”. - Reality: subtle concurrency/ownership rules can break delivery. **Fix**: docs + runtime assertions (“only one poller per token”) + clearer UI warnings. ### Gap 3: “If credentials exist, the app should detect them” - Users expect Codex/Anthropic subscriptions to be auto-recognized. - Reality: auth file formats drift; detection lags. **Fix**: credential doctor + robust multi-shape detection + actionable errors. Recurring questions indicating onboarding gaps (from this slice) - “Where is ElizaCloud?” / “Is there an update log?” - “How much does it cost to run X?” - “Does it integrate with Y (Hyperfy)?” --- ## 5) Community Engagement Insights ### Power users (and what they need) - **Sw4pIO (GitHub)**: repeatedly reports high-quality, deeply diagnostic issues (auth drift, schema drift, connector races). Needs: - faster maintainer feedback loops - a clear “best place to report” and “what logs to include” - recognition pathways (triage role, label permissions, invited reviewer group) - **odilitime / Shaw (Discord ops + core)**: shipping infra/payment milestones; needs: - structured inbound questions to avoid repeated support load - a safer expectation-management cadence (reduce reactive conflict) ### Newcomer friction signals - Questions asked in #coders with no response (hosting cost, hardware, integration status). - Confusion around governance/focus (product vs token price discussions). ### Converting passive users into contributors 1. **“Good first docs PR” pipeline**: when a question is asked twice, open a docs issue with a template and assign to volunteers. 2. **Integration champions**: appoint maintainers per connector (Telegram/Slack/Discord) to own status page updates. 3. **Hackathon/project showcase**: leverage announcements like *elizaOK Top 20* to create a “Community Builds” directory with starter templates and postmortems. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord**: high velocity, but Q&A is getting lost (67% unanswered in captured inquiries; #coders snippet shows 100% unanswered). - **GitHub**: high-quality technical reports get resolved quickly, but likely under-represents non-technical users (who won’t file issues). ### Improvements (structured, actionable) 1. **Weekly “Support Intake” form** (short): - deployment target, provider, connector, logs, expected behavior - auto-creates GitHub Discussion/Issue with labels 2. **Discord → GitHub bridge bot** - allow helpers to press a button to convert a Discord question into a tracked item 3. **Underrepresented segments to target** - non-dev builders trying Cloud monetization flows - self-hosters on consumer hardware (Mac mini, low-cost VPS) seeking “known-good” configs - integration-focused users (Hyperfy-like ecosystem connections) who need a status truth source --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Publish a “Deployment & Cost Quickstart” (Twitter bot + Mac mini + cheapest VPS)** with clear ranges and tested presets. 2. **Create and pin an “Integration Status Matrix”** (including Hyperfy status, Telegram polling rules, Slack known failure modes). 3. **Add a runtime “Doctor” for connectors + credentials** (fail-loud checks: duplicate pollers, missing auth files/preloads, schema mismatch hints). 4. **Implement Discord #coders triage + solved workflow** to cut unanswered questions materially (target: from 67% unanswered → <20%). 5. **Add plugin-sql schema drift guardrails** (boot-time sanity check + CI “fresh DB migration” test) to prevent “chat unusable on first run” regressions.