## User Feedback Analysis — 2026-05-12 (based on available data through 2026-05-11)

### Data coverage note
- Discord data available: 2026-05-09 to 2026-05-11.
- GitHub data available: May 2026 rollup + top issues/PRs (not all created on 2026-05-12).
- Some observations are qualitative due to low sample size in Discord threads (few discrete questions, many greetings/introductions).

---

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

### 1) Integration — OAuth/whitelist & “how do I connect my agent safely?”
**Signals (high severity, moderate frequency):**
- Discord: rma_bot asked who to contact for “OAuth invite/whitelist” to test a read-only research agent in a sandbox channel; unclear process until a moderator stepped in (odilitime).
- Pattern: integration attempts are happening “community-first” (Discord testing) before upstream contribution.

**Problem affecting users most:**
- No self-serve/standardized pathway for third-party agent integrations to be trialed in Discord (permissions, sandboxing, OAuth, whitelisting, review).

---

### 2) Technical Functionality — Connector reliability (Telegram), silent message loss
**Signals (high severity, recurring in GitHub):**
- GitHub issue #7245: two Telegram pollers (plugin + wrapper) cause “roughly every other message” to be dropped silently.
- This is a “looks like it works” failure mode—users can’t reliably confirm correct configuration.

**Problem affecting users most:**
- Default/auto-enable behaviors can create duplicate ownership of a bot token, producing nondeterministic behavior without clear UI warnings.

---

### 3) Technical Functionality — Auth detection & credential shape drift (Codex CLI / Anthropic OAuth)
**Signals (high severity, recurring in GitHub):**
- GitHub #7243: Codex CLI modern `tokens.access_token` file format not recognized → UI shows “install required” incorrectly.
- GitHub #7210: Anthropic subscription OAuth path fails because an expected preload file isn’t generated/checked in; failure is silent until runtime 401s.

**Problem affecting users most:**
- Credential import/detection is brittle to upstream vendor changes; errors surface downstream as confusing provider failures.

---

### 4) Technical Functionality — Schema/migrations drift causing “chat unusable on fresh DB”
**Signals (high severity, recurring in GitHub):**
- GitHub #7222: plugin-sql runtime migrator missing 3 pgTable definitions; fresh PGLite boot lacks tables → cascading provider/evaluator failures → user-facing parsing errors; chat effectively unusable.

**Problem affecting users most:**
- Two “sources of truth” (abstract schemas vs drizzle tables) can drift without build/boot sanity checks, breaking first-run experiences.

---

### 5) UX/UI — UI breakage when client methods undefined; errors freeze chat surface
**Signals (high severity):**
- GitHub #7244: duplicate `MiladyClient` class causes ~155 augmented methods not to attach → “is not a function” errors → React error boundary → chat input becomes unresponsive.

**Problem affecting users most:**
- Runtime UI failures cascade into “can’t chat” rather than gracefully degrading; missing method wiring not detected at build time.

---

### 6) Documentation / Community — Unanswered “project status/token support” questions
**Signals (moderate severity, recurring socially):**
- Discord: .chomppp asked if ElizaOS token is abandoned and noted a founder removed ElizaOS from X bio; received no response.

**Problem affecting users most:**
- Governance/status questions linger publicly without an official pointer (FAQ, statement, or “who to ask”), which can reduce trust and participation.

---

### 7) Community — Help requests go unanswered; low “support throughput”
**Signals (moderate severity, recurring in Discord):**
- Discord 2026-05-09: binarycookies asked for help implementing movement functionality; no replies.
- Discord 2026-05-10: a security compromise question was raised and not resolved in visible thread.

**Problem affecting users most:**
- Newcomers or mid-level builders don’t reliably get help unless a core moderator notices (contrast: OAuth question got help quickly because it was operational/admin and tagged the right person).

---

### Frequency snapshot (from provided “top issues” + Discord threads)
- **5/5 (100%) of the listed top GitHub issues** are core reliability/auth/integration breakages (Telegram polling, auth file formats, schema/migrator drift, missing build artifact, duplicated client class).
- Discord questions with clear “blocked” outcomes: **~3 distinct unresolved concerns** (token support, potential compromise, app movement help) vs **1 resolved** (OAuth contact).

---

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

### How users are actually using elizaOS
1. **As an integration hub for multi-agent orchestration** (even when built outside elizaOS):
   - rma_bot built an orchestrator in Python (claude-agent-sdk) and wants to test inside the elizaOS Discord. This suggests elizaOS is being treated as a *community deployment environment*, not only a framework.
2. **As a connector-first platform (Discord/Telegram/Slack) where “message delivery correctness” is the product**:
   - GitHub issues show that when connectors fail, users perceive elizaOS as broken even if the agent core is fine.
3. **As a “self-host + UI” product** where onboarding and Settings detection must be correct:
   - Codex/Anthropic credential detection issues manifest in UI (“install required”) and runtime 401s.

### Emerging / unexpected use cases
- **Read-only research agents in community spaces** with strict permissions (respond only to @mentions, no DMs, sandboxed channel). This is closer to “community tool governance” than typical self-hosting.

### Feature requests that align with usage
- A standardized “**Discord sandbox agent onboarding**” flow: permission template, OAuth/whitelist form, and an approval checklist (ties directly to the orchestrator testing request).
- “**Connector ownership**” controls: ensuring only one component is polling/consuming updates for a given token.

---

## 3) Implementation Opportunities (2–3 concrete solutions per major pain point)

### A) Standardize third-party agent testing in Discord (Integration)
**Opportunity solutions:**
1. **Self-serve intake + automated provisioning**
   - Add a short form (GitHub Issue template or Discord bot command) that captures: bot/app ID, scopes, requested channels, data retention, safety constraints, and rollback plan.
   - Auto-create a sandbox channel + role with least-privilege permissions.
   - Similar pattern: Kubernetes communities often use “request access” issue templates + automated namespace provisioning.
2. **Publish a “Discord Agent Safety Profile” spec**
   - Define allowed behaviors (no DMs, respond only to mentions, rate limits, logging policy).
   - Provide reference code snippets for common SDKs (discord.js, nextcord, etc.).
   - Similar pattern: Matrix/IRC bridge projects publish “bridge permission policies”.
3. **Whitelist/OAuth runbook**
   - Document who owns approvals (backup contacts), expected turnaround, and failure modes.
   - Reduce “who do I DM?” friction.

**Priority:** High impact, low–medium effort (mostly docs + lightweight automation).

---

### B) Prevent silent connector failures (Telegram dual pollers) (Technical Functionality)
**Opportunity solutions:**
1. **Single-owner enforcement at runtime**
   - On boot, detect multiple Telegram consumers configured for same token; hard error with remediation instructions.
   - Add a lock (file lock or DB advisory lock) keyed by token to ensure only one poller runs.
   - Similar pattern: many job runners (Sidekiq, BullMQ) use distributed locks to prevent double processing.
2. **Make wrapper vs plugin mutually exclusive by design**
   - If wrapper exists for Bun workaround, auto-disable plugin-telegram or require explicit opt-in.
   - Ensure Settings UI shows a single “Telegram connector owner” selection.
3. **Improve observability**
   - Add “Telegram updates received” counters and “last update timestamp” to UI; warn if updates are being consumed elsewhere.
   - Similar pattern: Home Assistant integrations expose last-seen timestamps and health indicators.

**Priority:** Very high impact, medium effort.

---

### C) Harden credential detection/import against format drift (Auth) (Technical Functionality + UX)
**Opportunity solutions:**
1. **Schema versioning + tolerant parsers**
   - For Codex/Anthropic, detect multiple known shapes; include unit fixtures for each.
   - Treat unknown shapes as “present but unreadable” with a clear UI error (“Found ~/.codex/auth.json but format is unsupported—click to upload/convert”).
   - Similar pattern: Terraform providers maintain backward-compatible config parsing with deprecation warnings.
2. **Fail loud on missing build artifacts**
   - If a feature flag expects a preload file (Anthropic stealth interceptor), warn prominently and link to fix.
   - Never silently filter required files out of preload lists when feature is enabled.
3. **Add a “Credential Health Check” screen**
   - One click runs: detect files, validate tokens (non-destructive), confirm plugin enabled, show next action.
   - Similar pattern: Netlify/Vercel provide integration health checks for tokens and scopes.

**Priority:** High impact, medium effort (tests + UI messaging).

---

### D) Stop schema/migration drift from breaking first-run chat (Technical Functionality)
**Opportunity solutions:**
1. **Boot-time schema sanity check**
   - Compare abstract schema registry vs drizzle tables; fail fast with explicit “missing tables: …” before user chats.
   - Similar pattern: Prisma migrations fail at startup if migrations drift from schema.
2. **Generate drizzle tables from abstract schemas (single source of truth)**
   - Add codegen that emits `pgTable` definitions from the shared schema definitions.
   - This reduces parallel maintenance.
3. **Add “fresh PGLite smoke test” in CI**
   - Start from empty DB, run migrator, run one chat turn with memory providers enabled; assert no missing-table errors.

**Priority:** Very high impact, medium–high effort (but CI smoke test is relatively straightforward).

---

### E) Reduce UI “hard freeze” when API client augmentation fails (UX/UI)
**Opportunity solutions:**
1. **Build-time guardrails**
   - Add a unit test that asserts expected client methods exist (e.g., `expect(typeof client.listAppRuns).toBe("function")`).
2. **Runtime soft-fail + user-facing recovery**
   - If a method is missing, disable the affected panel and show “API client incomplete—reload / check build” instead of crashing the entire chat surface.
   - Similar pattern: VS Code extensions often degrade features with error toasts rather than disabling the editor.
3. **Consolidate augmentation mechanism**
   - Replace prototype augmentation side-effects with explicit composition (e.g., `createClient({ chat, apps, cloud })`) to avoid import-order/class duplication pitfalls.

**Priority:** High impact, low–medium effort for tests + soft-fail; higher for refactor.

---

## 4) Communication Gaps (expectations vs reality)

1. **“Token/project support” ambiguity**
   - Question was asked publicly and went unanswered, suggesting either lack of monitoring or lack of a canonical statement.
   - Improvement: add a pinned FAQ entry: “Project governance & token status” + where to ask + what the team commits to updating.

2. **“Security compromised?” questions don’t route to a process**
   - A compromise concern was raised without follow-up; scam warning posted without details.
   - Improvement: create a clear security reporting path (Discord pinned message + `security@` + GitHub Security Policy) and a template for reporting scams/compromises.

3. **OAuth/whitelist process is person-dependent**
   - rma_bot needed to find the right individual (odilitime).
   - Improvement: document the process and provide a role-based contact (“@Community Ops”) rather than a single person dependency.

4. **Cost expectations for bots**
   - Costs dropped from ~$100/mo to ~$10/mo, but variability depends on reply volume—users likely need a calculator or defaults.
   - Improvement: publish a simple cost model and recommended rate limits per connector.

---

## 5) Community Engagement Insights

### Power users / high-signal contributors (and needs)
- **odilitime (moderator/core ops):** acts as operational unblocker (OAuth setup). Need: scalable process so approvals don’t bottleneck on DMs.
- **Sw4pIO (high-signal issue reporter):** filed multiple deep, reproducible issues (auth, schema, Telegram, UI client). Need: fast triage loop, recognition, and a path to convert reports into PRs (they explicitly offered PRs/diffs).
- **Engineers introducing themselves (_ky0078, harry346165, fabio7311, trace.g):** indicate a talent pool, but introductions are not converting into concrete contributions yet. Need: “good first issue” routing + integration roadmap.

### Newcomer questions indicating onboarding friction
- “Who do I DM about OAuth/whitelist?”
- “Is something compromised?”
- “How do I implement X in my app?” (movement in chat app) with no response.

### Converting passive users into contributors
1. **Weekly “Help Desk” hour in Discord** with rotating maintainers + a queue format.
2. **Issue-to-PR mentorship**
   - Label high-quality reports as “mentor available”; offer pairing sessions to turn diffs into PRs.
3. **Recognition loops**
   - Highlight “Top bug reports of the week” in a community post; link to merged fixes.

---

## 6) Feedback Collection Improvements

### Channel effectiveness
- **Discord:** high social activity, but low structured problem resolution; questions can go unanswered unless they reach the right moderator.
- **GitHub issues:** extremely actionable (clear repro steps, diagnostics), but may reflect a smaller set of power users.

### Suggested improvements (more structured, actionable feedback)
1. **Discord → GitHub bridge**
   - Add a “/report-bug” command that collects logs + environment + reproduction steps and opens a GitHub issue draft.
2. **Standard templates**
   - For connectors (Telegram/Discord/Slack): token ownership, polling mode, hosting environment (bun/node), expected behavior, and “message loss” checks.
3. **First-run telemetry (opt-in for OSS)**
   - Capture anonymized boot health signals (missing tables, auth detection failures) to quantify which failures affect most new installs.

### Underrepresented segments
- **Non-core Discord users who are building apps** (e.g., binarycookies) aren’t represented in GitHub issue data; their needs are more “how-to” and UI guidance than deep runtime fixes.
- **Security-sensitive operators** (self-hosted) are hinted at (“compromised?”) but not providing actionable reports—likely due to lack of reporting guidance.

---

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

1. **Add boot-time sanity checks + CI smoke tests for fresh DB + connectors**
   - Prevent “chat unusable on fresh install” and catch missing tables/dual pollers early.

2. **Implement single-owner enforcement for Telegram polling (and add UI health indicators)**
   - Eliminates silent message loss and restores trust in connector reliability.

3. **Harden credential detection/import (Codex + Anthropic) with fail-loud messaging**
   - Support multiple credential file shapes; surface actionable UI errors instead of “install required” or 401 loops.

4. **Publish a standardized Discord agent testing / OAuth-whitelist runbook + intake form**
   - Reduce operational load on moderators and lower integration friction for external agent builders.

5. **Establish a visible security + project-status FAQ (token/support) with an escalation path**
   - Close the trust gap caused by unanswered governance/security questions and reduce rumor-driven churn.