## User Feedback Analysis — 2026-05-11 (elizaOS)

**Data sources & sample size:** 9 distinct feedback signals from Discord (May 8–10) and GitHub issues/PR reviews (May 1–11). Percentages below use **n=9**.

---

### 1) Pain Point Categorization (Top recurring 5–7)

#### A) **Technical Functionality** (5/9 = **56%**, highest severity)
Most impactful failures are “looks installed/configured but doesn’t work” defects that break core flows.
- **Fresh install/runtime broken due to missing DB tables (plugin-sql migrator drift)**: missing `entity_identities`, `entity_merge_candidates`, `fact_candidates` leads to cascading provider failures and “parsing error” user-visible breakage (GitHub #7222).
- **Auth detection/import mismatches** (GitHub #7243, #7210):
  - Codex CLI subscription auth not detected due to modern `tokens.access_token` shape → UI says “install required.”
  - Anthropic subscription OAuth path fails because expected preload file `claude-code-stealth.mjs` isn’t generated/checked in → `401 Invalid authentication credentials`.
- **Client API methods undefined due to duplicate class / prototype augmentation not applied**: breaks dashboard pages and can freeze chat UI (GitHub #7244).

#### B) **Integration** (2/9 = **22%**, high severity)
Integration issues primarily affect reliability of messaging connectors.
- **Telegram silent message loss due to dual pollers**: wrapper + `@elizaos/plugin-telegram` both poll same token → ~50% message drop with no clear error (GitHub #7245).
- **Slack integration risk (from PR review)**: missing try/catch around `users.info` can drop inbound messages on API errors (PR #7375 review notes).

#### C) **Security** (Community + Technical) (2/9 = **22%**, medium-to-high severity)
Signals indicate concern, but channels don’t capture enough detail to respond effectively.
- Discord: “was something compromised?” (gokumaster64) received no visible follow-up.
- Discord: “scam” warning posted without details (dieantwoord1337), limiting moderator response and user protection.

#### D) **Documentation / Onboarding** (2/9 = **22%**, medium severity)
Recurring questions show missing “quick answers” for practical setup and operational planning.
- **Operational cost uncertainty**: “How much does it cost to run an Eliza as a Twitter bot every day?” → answered ad hoc with rough numbers ($100/mo historical → ~$10/mo now; reply volume is main driver).
- **Unanswered build/how-to questions**: user struggling to implement “movement” in a chat app UI received no help (binarycookies).

#### E) **Community / Support Responsiveness** (2/9 = **22%**, medium severity)
- Help requests frequently go unresolved in public channels (movement issue; compromise question).
- Many interactions are greetings/introductions rather than problem-solving, suggesting a gap in routing newcomers to the right support surface.

---

### 2) Usage Pattern Analysis (Actual vs intended)

**Observed actual usage:**
- **Running agents as social bots** (Twitter/X) with cost sensitivity and reply-volume tuning (Discord: guru0 + odilitime).
- **Connector-heavy deployments** (Telegram/Slack/Discord) where reliability and “no dropped messages” matters more than advanced features (GitHub issues around Telegram pollers; PR review around Slack message drops).
- **Production-minded builders joining the community**: multiple intros emphasize “production-ready systems,” full-stack stacks, and agent orchestration (Discord intros; project showcase using LangGraph/CrewAI + RAG).

**Mismatch vs intended/assumed usage:**
- Users expect “enable connector → it works reliably.” In practice, edge cases (double polling, auth shape drift, missing migrations) break first-run experiences.
- Users treat the dashboard/UI as a stable control plane; issues like missing client methods (#7244) turn into “the whole app is frozen,” not a minor bug.

**Emerging/feature requests implied by usage:**
- A **cost calculator / budgeting guardrails** for social bots (estimate by reply volume + model/provider).
- A **connector health checklist** (single poller enforcement, message delivery confirmation, structured logs).
- **Schema sanity checks** during boot to prevent “half-working chat” (state composition failures hidden behind generic parsing errors).

---

### 3) Implementation Opportunities (Solutions per major pain point)

#### Pain Point 1: Fresh install breakage from schema/migration drift (GitHub #7222)
**High impact / Medium difficulty**
1) **Add a boot-time schema validation gate** in `@elizaos/plugin-sql`:
   - Compare expected table list (from abstract schemas barrel) vs drizzle pgTables used by migrator.
   - Fail fast with a single actionable error (“Missing tables: entity_identities, … Run migration / update plugin-sql schema.”).
   - *Similar approach:* Prisma and Rails both provide “pending migrations” checks that stop app boot with clear instructions.
2) **Generate drizzle pgTable definitions from the abstract schema source** (single source of truth), or invert ownership so migrator reads abstract schemas.
   - *Similar approach:* OpenAPI-first codegen prevents drift between types and runtime.
3) **Improve user-facing error surfacing**:
   - When providers fail during state composition, surface a banner: “Database schema incomplete—memory features disabled,” instead of cascading into structured-output parsing retries.

#### Pain Point 2: Auth “installed but not detected” (Codex/Anthropic) (GitHub #7243, #7210)
**High impact / Low-to-medium difficulty**
1) **Support multiple credential file shapes** (legacy + modern) with unit fixtures:
   - For Codex: detect `tokens.access_token` and import/translate.
   - For Anthropic: ensure the stealth preload artifact exists or is built in dev.
   - *Similar approach:* GitHub CLI and AWS SDKs maintain backward-compatible config parsing with versioned schemas.
2) **Fail loud on missing critical runtime artifacts**:
   - If stealth mode is enabled but preload file missing, log a warning/error with remediation steps.
3) **Add an “Auth Diagnostics” panel in Settings**:
   - Show detected sources (env, vault, CLI files), parsed shape version, and last validation result (401 vs OK), so users don’t infer “milady is lying” when it’s a parser mismatch.

#### Pain Point 3: Connector message loss (Telegram dual polling; Slack unguarded API) (GitHub #7245; PR #7375 review)
**High impact / Medium difficulty**
1) **Single-owner enforcement per connector token**:
   - At runtime init, detect multiple pollers for same token; block one and log a high-priority warning.
   - *Similar approach:* Home Assistant integrations prevent duplicate device polling via unique config entry IDs.
2) **Add connector-level delivery acknowledgements**:
   - Maintain counters: received updates, processed, replied, dropped; display in a connector “Health” section.
3) **Harden inbound event handlers** (Slack/Telegram):
   - Wrap external API calls (`users.info`) with try/catch and fallback identity creation to avoid dropping messages.

#### Pain Point 4: UI hard failures from client method augmentation bug (GitHub #7244)
**High impact / Low difficulty**
1) **Eliminate duplicate class definitions** and enforce a single export:
   - Re-export shim (`export { MiladyClient } from "./client"`) + required side-effect imports.
2) **Add a runtime assertion on startup**:
   - Verify presence of a minimum method set (e.g., `listAppRuns`, `sendMessage`) and throw a clear error if missing.
   - *Similar approach:* VS Code extensions validate API compatibility via activation checks and fail with explicit logs.

#### Pain Point 5: Unstructured security concerns + scam reports (Discord)
**Medium impact / Low difficulty**
1) **Add a “Report Security Issue” Discord workflow** (bot form):
   - Required fields: link/message ID, screenshot, what was compromised, wallet/app context.
2) **Publish a short security runbook** pinned in Discord:
   - What to do if “compromised?”, where to post, what logs to include, how mods respond.
3) **Introduce standardized scam-tagging**:
   - Quick reactions that trigger an auto-thread template and alert moderators.

#### Pain Point 6: Cost uncertainty for social bots (Discord)
**Medium impact / Low difficulty**
1) **Add a cost estimator doc + UI widget**:
   - Inputs: model/provider, avg tokens per reply, replies/day, image/tts usage.
2) **Provide recommended “cost caps”**:
   - Rate limits, reply quotas, backoff behavior.
   - *Similar approach:* Vercel and Supabase provide usage dashboards + budget alerts to prevent surprise bills.

---

### 4) Communication Gaps (Expectations vs reality)

- **Expectation:** “Enabling a connector means it’s ready.”  
  **Reality:** Connector reliability can fail silently (Telegram dual pollers drop messages; Slack handler can drop on API error).  
  **Fix:** Add explicit “Connector Health” states and single-poller guarantees.

- **Expectation:** “If Settings says ‘installed/authenticated,’ it will work.”  
  **Reality:** Auth detection can be wrong due to evolving credential file formats (Codex `tokens.*`) or missing runtime artifacts (Anthropic stealth preload).  
  **Fix:** Make Settings reflect *validated* status (last successful call) vs *detected* status.

- **Recurring questions indicating doc gaps:**
  - Cost to run social bots and what drives cost (reply volume, model choice).
  - “Something compromised?” and “scam” warnings lacking a reporting mechanism.

---

### 5) Community Engagement Insights

**Power users / high-leverage contributors:**
- **Sw4pIO**: submitted multiple high-signal, deeply technical bug reports with repro steps and verified fixes (auth, migrations, Telegram, client augmentation). Needs:
  - Faster maintainer triage loop (labeling, owner assignment, “please PR” guidance).
  - A “known issues” page so they don’t rediscover already-tracked breakages.
- **odilitime**: provides operational guidance (cost estimates) and appears central in Discord support.
- **2-A-M / standujar / NubsCarson**: shipping key UX, cloud/auth, and stability work—good candidates to formalize as “area maintainers” (Automations, Cloud Auth, Runtime Stability).

**Newcomer friction patterns:**
- Users ask for help (movement in chat app UI) but don’t get responses—suggests either:
  - Questions are posted in the wrong channel, or
  - No on-call helpers / triage rotation.

**Converting passive users into contributors:**
- Create “Good First Debug” issues that mirror real failures (e.g., auth shape updates, missing schema checks).
- Add a Discord command like `/issue-template` that turns a question into a pre-filled GitHub issue with required diagnostics.

---

### 6) Feedback Collection Improvements

**Current channel effectiveness:**
- Discord captures questions quickly but loses actionable context (security/scam reports, help requests with no follow-up).
- GitHub issues are high quality when filed by power users, but likely underrepresents newcomers who bounce earlier.

**Improvements for structured, actionable feedback:**
1) **Introduce a standard “Support Intake” form** (GitHub Discussion or issue template) for:
   - Connector bugs (token type, polling mode, logs snippet, expected vs actual).
   - Auth/provider bugs (credential source, file shape, last error code).
2) **Add lightweight in-app “Export Diagnostics”**:
   - Redacts secrets, includes plugin list, connector states, migration statement count, last 200 lines of logs.
3) **Underrepresented segments missing from feedback:**
   - Non-dev operators running agents on VPS/headless Linux (only surfaced indirectly via prior segfault fixes).
   - Users building UI-heavy apps (movement/UI help request had no path to resolution).

---

## Prioritized High-Impact Actions (next 2–4 weeks)

1) **Fail-fast health checks for “fresh install” correctness** (DB schema + client API method availability) to prevent half-working experiences that degrade into generic parsing errors.  
2) **Connector reliability hardening**: enforce single poller per Telegram token; add try/catch + drop-proof inbound handling for Slack; surface connector health metrics.  
3) **Auth robustness + diagnostics**: support modern Codex CLI token shapes; ensure Anthropic stealth preload is generated or errors loudly; add Settings “validated vs detected” status.  
4) **Security reporting workflow in Discord**: structured scam/compromise report templates + moderator alerts to turn vague warnings into actionable incidents.  
5) **Publish a cost & rate-limit guide (and optional estimator)** for social bots, emphasizing the primary driver observed in community replies: **reply volume**.