## User Feedback Analysis — 2026-05-08 ### Data snapshot (sources & volume) - **Discord (2026-05-05 → 2026-05-07):** recurring Q&A and troubleshooting in `#discussion` and `#coders` (notably Twitter/X + Hyperfy + docs-site status). - **GitHub issues/PR context (May 2026, sampled from recent high-signal issues):** several **integration/auth/runtime correctness** defects with clear repro steps. - **Quantification note:** Percentages below are based on a **small sample of 10 distinct, user-reported friction points** surfaced in the provided data for this reporting window. --- ## 1) Pain Point Categorization (top recurring 5–7) ### 1) Integration — Connector auth requirements changed (X/Twitter) **Frequency/Severity:** Medium frequency, high confusion; **20% (2/10)** of sample signals mention Twitter auth/cost uncertainty. **Examples (Discord):** - **guru0** asked whether X API is now required vs previous “login method,” and flagged **posting cost concerns**. - **odilitime** confirmed: **X API is now required**, pricing “much cheaper than before.” **What’s affecting most users** - Users building **social bots** are blocked by unclear requirements, cost expectations, and legacy assumptions about auth methods. --- ### 2) Integration / Technical Functionality — Plugin availability & compatibility drift (Hyperfy) **Frequency/Severity:** High severity; **20% (2/10)** (missing plugin + Hyperfy connectivity status). **Examples (Discord):** - **binarycookies** found the Hyperfy starter/plugin link returning **404**, despite having seen it days earlier; also noted **version mismatch** with core. - Workaround required a **DM’d zip** from **odilitime**, implying the plugin is effectively “out of band.” **What’s affecting most users** - Builders depending on plugins for new environments (3D/Hyperfy) hit **broken discovery**, **broken installs**, and **unclear compatibility guarantees**. --- ### 3) Documentation / UX — “Where is it now?” repo consolidation and discoverability gaps **Frequency/Severity:** Medium; **10% (1/10)** explicitly, but likely underreported. **Examples (Discord):** - **ElizaCloud** consolidation into `github.com/elizaOS/eliza` was announced; users still asked operational questions (hosting cost/hardware) without a clear doc landing page. **What’s affecting most users** - After major structure changes, users struggle to locate the “current source of truth” for cloud/self-host guidance and templates. --- ### 4) Technical Functionality — Docs site reliability regression (daily summary stuck) **Frequency/Severity:** Medium; **10% (1/10)** but impacts community visibility and trust. **Examples (Discord):** - **stan0473** reported `elizaos.github.io/summary/day` stuck since **May 4**; speculation about GitHub account/config; no resolution recorded. **What’s affecting most users** - Public-facing status/reporting pages failing silently erode confidence and increase repeated support pings. --- ### 5) Documentation / Community — Unanswered “cost to run” and “hardware feasibility” questions **Frequency/Severity:** Medium frequency; **20% (2/10)** represent unanswered onboarding questions. **Examples (Discord):** - **guru0** asked about **cloud hosting costs** for a Twitter bot and whether a **Mac mini** is sufficient; these went unanswered in the captured summaries. **What’s affecting most users** - Newcomers evaluating feasibility can’t quickly answer: “What will this cost?” and “What can I run it on?” --- ### 6) Technical Functionality — Auth/runtime edge cases cause “works on my machine” failures (GitHub) **Frequency/Severity:** High severity; **30% (3/10)** of sampled friction points are auth/runtime correctness issues. **Examples (GitHub issues, recently closed but high learning value):** - Missing build artifact (`claude-code-stealth.mjs`) caused **Anthropic OAuth subscription** requests to 401 until fixed (#7210). - Codex CLI auth detection missed modern token shapes, falsely showing “install required” (#7243). - SQL migrator missed drizzle table defs leading to cascading provider failures and unusable chat on fresh DB (#7222). **What’s affecting most users** - Users doing “fresh clone → run dev” hit failures that look like misconfiguration but are actually **missing artifacts**, **schema drift**, or **credential-shape drift**. --- ### 7) Integration / Reliability — Connector duplication can cause silent message loss (Telegram) **Frequency/Severity:** High severity; **10% (1/10)** but critical impact (silent drops). **Example (GitHub):** - Dual Telegram pollers competing for `getUpdates` produced **~50% message loss** (#7245). **What’s affecting most users** - Messaging connectors must be **single-owner** per token; silent loss is particularly damaging because it appears intermittent/non-deterministic. --- ## 2) Usage Pattern Analysis (actual vs intended) ### Observed real-world usage 1. **Agents as social bots** (Twitter/X posting): users are cost-sensitive and want “simple auth that works,” indicating elizaOS is being evaluated as a **low-friction automation runtime**, not only a framework. 2. **Agents embedded into 3D/world platforms** (Hyperfy): community expects plugin starters to stay accessible and compatible—suggesting elizaOS is used as a **rapid prototyping layer** for experiential apps. 3. **Workflow automation + clarifications** (n8n): recent work (clarification loops + UI quick-picks) aligns with users treating agents as **operators** that must request missing inputs. 4. **Self-hosting & cost optimization**: repo migration off Vercel + cheaper containers indicates community focus on **running lean infra**; users ask for hardware sizing (Mac mini) and monthly cost estimates. ### Emerging / unexpected applications - **Monetized apps + payment rails (x402 routes)**: indicates elizaOS is being used as a foundation for **commercial agent apps**, increasing the need for stable integration contracts and “production-ready” connector guarantees. ### Feature requests that align with usage - **Clear Twitter/X integration guide** with cost tiers and minimal “posting bot” recipe. - **Versioned plugin compatibility & distribution** so builders can rely on starters (Hyperfy) without DM-based access. - **Self-host cost calculator / sizing guide** (e.g., Mac mini vs VPS vs containers). --- ## 3) Implementation Opportunities (solutions per major pain point) ### A) X/Twitter API requirement confusion (Integration + Documentation) **High impact / Low–Medium difficulty** 1. **Add a “Twitter/X Integration Requirements” doc page**: - Explicitly state: “X API required,” supported endpoints/features, and minimum viable plan for posting. - Include a “Cost expectation” section with example usage (e.g., N posts/day). 2. **Improve runtime error messaging** for missing/invalid X credentials: - Return actionable errors (“X API key required; login-cookie auth deprecated”) instead of generic failures. 3. **Provide an example template**: “Twitter bot starter” with env var checklist and rate-limit guidance. **Comparable patterns** - Home Assistant and Stripe publish “Requirements & limits” pages per integration, with “common errors” sections. --- ### B) Hyperfy plugin 404 + core/plugin mismatch (Integration + Technical Functionality) **High impact / Medium difficulty** 1. **Publish a compatibility matrix + pinning strategy**: - Add `peerDependencies` / engine constraints to plugins (core version range). - Enforce CI that tests plugin build against latest core (and maybe last minor). 2. **Restore discoverability via an official registry entry**: - Even if “experimental,” keep a canonical URL that never 404s; mark status. 3. **Add deprecation and migration policy**: - If a plugin must be removed, leave a tombstone README pointing to replacement or archived tag. **Comparable patterns** - VS Code extensions use `engines.vscode` to prevent incompatible installs; Kubernetes/Helm charts rely on version constraints and release channels (`stable` vs `incubator`). --- ### C) Docs site “summary/day” stuck (Technical Functionality + Documentation) **Medium impact / Low difficulty** 1. **Add monitoring + alerting for the GitHub Pages pipeline**: - A daily scheduled check that validates the date freshness and opens an issue/pings maintainers if stale. 2. **Show “last updated” + failure banner** on the page: - Avoid silent failure; tell users the pipeline is behind and where to track status. 3. **Add a fallback data source**: - If generation fails, serve the last successful JSON plus an explanation. **Comparable patterns** - Docusaurus/Next.js docs sites often include scheduled link-checkers and freshness checks that file GitHub issues automatically. --- ### D) Onboarding gaps: hosting costs + hardware sizing unanswered (Documentation + Community) **High impact / Low difficulty** 1. **Create a “Self-hosting quick guide”**: - Minimal hardware requirements, “works well on Mac mini?” section, and a few reference deployments (VPS, Docker, bare metal). 2. **Add a lightweight cost model**: - Separate compute vs LLM usage vs third-party APIs (X), with “starter / hobby / production” tiers. 3. **Add a “Common questions” pinned Discord post**: - Reduce repeated questions and support load. **Comparable patterns** - Supabase, n8n, and Nextcloud provide “deployment sizing” and “expected cost” guides that reduce pre-install dropoff. --- ### E) Auth/runtime edge cases (credential shapes, missing artifacts, schema drift) (Technical Functionality) **Very high impact / Medium difficulty** 1. **Boot-time diagnostics checklist**: - Validate presence of required generated artifacts (e.g., stealth preload file), credential file shapes (Codex), and required DB tables. - Fail loudly with a single actionable report rather than cascading runtime errors. 2. **Schema single source of truth**: - Ensure migrator consumes the same schema definitions used by runtime queries (or add a sanity check that all abstract schemas have concrete drizzle tables). 3. **Golden-path “fresh clone” CI**: - Run `bun install && bun run dev` (or equivalent headless test) on a clean environment to catch missing-file and fresh-db failures. **Comparable patterns** - Prisma and Django both prioritize “migrate + validate” workflows; many CLIs include `doctor` commands to catch misconfiguration early. --- ### F) Connector duplication causing silent message loss (Telegram) (Integration + Reliability) **High impact / Medium difficulty** 1. **Enforce single poller ownership per token**: - At runtime, detect multiple consumers and hard error with guidance. 2. **Unify connector enablement rules**: - If a wrapper exists for platform quirks, the upstream plugin should be explicitly disabled automatically. 3. **Add message-loss telemetry**: - Detect gaps in update offsets and warn. **Comparable patterns** - Many bot frameworks treat polling/webhook as mutually exclusive and enforce it at config validation time. --- ## 4) Communication Gaps (expectations vs reality) 1. **“Login method still works” vs “X API required now”** - Users expect legacy auth paths; reality changed. This needs prominent docs + changelog callout. 2. **Plugin availability assumptions** - Users assume “if it existed yesterday, it should exist today.” A 404 breaks trust; even an archive notice would reduce confusion. 3. **“It runs locally” vs “fresh clone is broken”** - Several GitHub issues show failures that only appear on clean environments (missing generated files, schema drift). Users interpret this as personal setup mistakes. 4. **Daily summaries as operational signal** - A stuck summary page looks like project inactivity or broken infra unless explicitly labeled. --- ## 5) Community Engagement Insights ### Power users & their needs - **odilitime**: active helper; currently bridging gaps via ad-hoc support (e.g., DM zip). Needs **repeatable, documented workflows** and official artifact hosting to avoid 1:1 distribution. - **stan0473**: monitoring community-facing infra (summary page) and escalating; would benefit from a **clear maintainer runbook** for docs-site pipelines. - **Sw4pIO (GitHub)**: high-signal bug reporter with strong repros; ideal candidate for a **“Bug Triage / Release QA”** workgroup or labeled maintainer-track contributor. - **Shaw**: provides governance/product positioning; could reduce repeated questions by publishing a short **“what elizaOS is / isn’t”** FAQ (esp. around cloud, costs, and org structure). ### Newcomer questions indicating onboarding friction - “How much does it cost to run this as a Twitter bot?” - “Can I run it on a Mac mini?” - “Where did ElizaCloud go?” - “Where is the Hyperfy starter/plugin?” ### Converting passive users into contributors 1. **Create “good first fix” tasks around docs + registry entries** (Twitter/X guide, Hyperfy tombstone page, summary freshness monitor). 2. **Add a structured support intake**: - A Discord `/bug` or `/help` form that captures version, plugin list, and logs; automatically opens a GitHub issue draft. 3. **Recognition path**: - Publicly credit helpers who convert repeated Discord answers into docs PRs. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord:** great for rapid Q&A, but issues get lost and some questions remain unanswered (e.g., hosting cost/hardware). Workarounds via DM (plugin zip) are not scalable. - **GitHub issues:** highest quality/most actionable (clear repros, root cause hypotheses), but not all Discord pain points are being captured as issues. ### Improvements (more structured, actionable) 1. **Introduce a “Support → Issue” bridge** - A pinned template: “If it’s broken, file an issue with: core version, plugin version, logs, repro steps.” 2. **Weekly “Top Discord FAQs” auto-digest** - Turn repeated Qs (X API, hosting costs, plugin locations) into a living FAQ page. 3. **Plugin registry telemetry** - Track 404s and broken links from docs/registry automatically and open issues. ### Underrepresented segments - **Non-coders evaluating cost/hosting** (they ask in Discord but don’t file issues). - **Builders integrating niche platforms (Hyperfy/3D)** who may churn after a single 404. - **Self-hosters on small hardware** (Mac mini/Raspberry Pi class) who need sizing guidance. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Publish an official “Twitter/X integration” page** (requirements, pricing expectations, env vars, minimal bot starter) and add a changelog note: “X API now required.” 2. **Fix plugin distribution & compatibility hygiene**: restore a non-404 canonical Hyperfy plugin location (even archived) + add a **core↔plugin compatibility matrix** and CI checks. 3. **Add a `doctor`/boot-time validation step** that catches: missing generated artifacts, incompatible credential file shapes, and missing DB tables—fail fast with actionable messages. 4. **Repair and monitor `elizaos.github.io/summary/day` freshness** with automated checks + visible “last updated” status to prevent silent regressions. 5. **Create a self-hosting cost & hardware sizing guide** (including “Mac mini viability” and example monthly costs) and pin it in Discord to reduce repeated onboarding friction.