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

### Data sources in this snapshot
- **Discord (May 6–8, 2026):** Integration questions (X/Twitter), plugin availability (Hyperfy), site/docs reliability (daily summary page), a few unanswered ops/cost questions, plus intros/showcases.
- **GitHub (May 2026 rollup + highlighted issues/PRs):** Multiple high-severity “fresh install” breakages (auth detection, missing DB tables, duplicate Telegram pollers, missing preload artifact), plus major platform work (vault/secrets UX, Slack plugin migration, Cloud monetized apps).

---

## 1) Pain Point Categorization (Top recurring friction areas)

> Because Discord for May 8 was mostly non-support chatter, the strongest “pain” signals in this dataset come from **May 6–7 Discord support questions** plus **high-severity GitHub issues**. Severity is assessed by whether it blocks “first successful run” or causes silent data/message loss.

### 1) Integration — **Twitter/X now requires paid API (cost + auth shift)**
- **What users report**
  - Confusion on whether **X API is required** vs older login methods; concern about **API cost** for posting (Discord May 7).
- **Why it’s severe**
  - Impacts a flagship use case (bots/agents posting to X). Users may abandon setup if they believe it’s paywalled unexpectedly.
- **Frequency signal (within dataset)**
  - Appears as a direct FAQ + help exchange; also ties to multiple “run Eliza as Twitter bot” questions (Discord May 6–7).

### 2) Integration / Technical Functionality — **Plugin availability & compatibility drift (Hyperfy plugin removed / 404)**
- **What users report**
  - Hyperfy plugin repo link returns **404**; plugin was visible days earlier; version mismatch with core; workaround required via DM zip (Discord May 7).
- **Why it’s severe**
  - Breaks discoverability and trust: users can’t tell whether a plugin is deprecated, moved, or temporarily broken.
- **Frequency signal**
  - One explicit incident, but it’s a classic “ecosystem reliability” pain point and aligns with other drift issues seen in GitHub (schema drift, API drift).

### 3) Documentation / UX — **Status visibility gaps (daily summary page stuck; unclear “what changed”)**
- **What users report**
  - `elizaos.github.io/summary/day` stuck since **May 4** (Discord May 7). Root cause unclear; speculated GitHub account config.
- **Why it’s severe**
  - Community relies on summaries to track changes; when it breaks, users lose situational awareness (especially in fast-moving repos).

### 4) Technical Functionality — **Fresh-install runtime breakages (auth/schema/tooling)**
High-severity GitHub issues indicate “first message” can fail or degrade badly:
- **Missing SQL tables on fresh PGLite boot** (Issue #7222): tables not created because drizzle pgTable defs missing → repeated query failures → chat becomes effectively unusable.
- **Auth detection mismatch for modern Codex CLI tokens shape** (Issue #7243): UI says “install required” though user is logged in → provider not auto-enabled.
- **Missing Anthropic “stealth” preload artifact** (Issue #7210): subscription OAuth path fails with 401 because expected `.mjs` preload isn’t generated/checked in.
- **Duplicate MiladyClient class / missing prototype augmenters** (Issue #7244): UI calls methods that don’t exist → pages crash, chat freezes.
- **Why it’s severe**
  - These are “**onboarding killers**”: users can’t get a first successful chat or stable UI without deep debugging.

**Quantification (from provided highlighted issues list):**
- **4/6 (≈67%)** of the highlighted issues explicitly describe **fresh clone / fresh boot** breakage or first-run failure modes (#7210, #7222, #7243, #7244).
- **1/6 (≈17%)** is **silent message loss** in a major connector (#7245).
- **1/6 (≈17%)** is connector reliability but manifests as silent drops (#7245).

### 5) Integration / Reliability — **Messaging connector correctness (Telegram double-poller message loss; Slack potential silent drops)**
- **What users report**
  - Telegram: two pollers consume the same bot updates; messages dropped silently (#7245). “Bot replies sometimes” is hard to diagnose.
- **Adjacent reliability risk flagged in PR review**
  - Slack migration PR review notes missing try/catch around Slack `users.info` call could drop messages silently (PR #7375 review notes).
- **Why it’s severe**
  - Silent loss undermines user trust more than loud failures.

### 6) Documentation / Community — **Unanswered ops questions (hosting costs, hardware feasibility)**
- **What users report**
  - Questions about **cloud hosting costs** for running as a Twitter bot and whether **Mac mini** is sufficient went unanswered in the captured segment (Discord May 6).
- **Why it matters**
  - These are “can I afford to try this?” blockers for new users evaluating self-hosting.

### 7) Community / Safety — **Off-platform solicitation & vague collaboration requests**
- **What users report**
  - A request for server-to-server endpoint + USDT receiver with a WhatsApp contact (May 8 coders channel).
- **Why it matters**
  - Creates community safety/moderation load; also indicates people are using elizaOS spaces for transactional networking rather than technical collaboration.

---

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

### Observed “actual usage” in this data
1. **Agent-as-a-bot on social platforms** is a primary driver  
   - X/Twitter bot costs/auth requirements; Telegram reliability; Slack connector migration suggests strong demand for workplace messaging bots.
2. **Full-stack product builds around agents** (not just toy agents)  
   - The showcased client project stack (Next.js 15/React 19 + RAG + multi-agent frameworks + k8s on AWS) implies builders treat elizaOS as an “agent layer” inside production web apps.
3. **Automation/workflow generation** is becoming core  
   - n8n workflow clarification loop work (weekly summary + PRs) indicates real usage is “describe automation in NL → refine via clarifications → generate workflow.”
4. **Monetization and payments are not edge-cases**  
   - Added payment methods for x402 routes; Cloud support for monetized container app domains → users are building apps they intend to charge for.

### Notable mismatches vs “intended” experience
- Intended: “plug-and-play connectors”  
  Observed: connectors require platform-specific paid APIs (X), and have subtle runtime pitfalls (Telegram polling races).
- Intended: “smooth onboarding”  
  Observed: several bugs are triggered only on **fresh clone/boot**, which is exactly the onboarding path.

### Feature requests implied by usage
- “**Cost & deployment guidance**” for running bots (X + hosting) is effectively a feature request in documentation form.
- “**Plugin compatibility guarantees**” (versioned plugin registry, compatibility matrix, archived/moved plugin notices).
- “**Connector health checks**” (detect multiple pollers, missing permissions, missing webhooks/long-poll collisions).

---

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

Below, each item includes **2–3 concrete solutions**, with **Impact** and **Difficulty**.

### A) X/Twitter integration: required API + pricing confusion
1) **Add a dedicated “X Integration” doc page with a decision tree**
- Include: posting vs read-only, required API tier, estimated monthly cost examples, and minimal env vars.
- Impact: High (reduces drop-off); Difficulty: Low.

2) **In-product connector card warning + “cost mode” toggle**
- In Settings → Connectors → X: show “Requires X API credentials” and link to pricing; optionally allow “disable posting” mode.
- Impact: High; Difficulty: Medium.

3) **Provide an alternative “bridge” integration pattern**
- Document using Zapier/n8n/webhook relay for posting if users can’t buy X API (with clear limitations).
- Similar approach: many OSS bot frameworks document webhook relays as fallback paths.
- Impact: Medium; Difficulty: Low–Medium (docs + example).

### B) Plugin availability/404 (Hyperfy) + ecosystem drift
1) **Create an official Plugin Registry entry lifecycle**
- States: active, deprecated, archived, temporarily disabled, moved. Show “last known compatible core version.”
- Impact: High; Difficulty: Medium.

2) **Automated CI check: “registry links must resolve”**
- Fail PR/cron if a plugin link returns 404 or repo moved without redirect.
- Impact: Medium; Difficulty: Low.

3) **Compatibility matrix + version pin recommendation**
- Provide a table: core `2.0.0-alpha.X` ↔ plugin versions; recommend lockstep via workspace or semver ranges.
- Similar approach: Home Assistant and Backstage plugins emphasize compatibility matrices.
- Impact: High; Difficulty: Medium.

### C) Daily summary/status page stuck (docs site reliability)
1) **Add monitoring + visible status banner**
- If summaries haven’t updated in >24h, show a banner: “Summaries delayed; see GitHub Actions run link.”
- Impact: Medium; Difficulty: Low.

2) **Harden the job with artifact fallback**
- Publish last generated JSON artifact; site reads latest available instead of “stuck”.
- Impact: Medium; Difficulty: Medium.

3) **Runbook + ownership**
- Document who owns the pipeline and how to rotate tokens/config.
- Impact: Medium; Difficulty: Low.

### D) Fresh-install runtime breakages (auth/schema/tooling)
1) **“Fresh install smoke test” CI gate**
- Script: fresh clone → bun install → run dev headless → send one message → assert response + no critical logs.
- Targets issues like missing tables (#7222), missing preload (#7210), client augmentation (#7244).
- Similar approach: Supabase and Next.js templates often maintain “create → start → ping” CI tests.
- Impact: Very High; Difficulty: Medium–High.

2) **Schema single source of truth validation**
- At plugin-sql init: compare abstract schema list vs drizzle pgTables; error loudly if missing.
- This was explicitly suggested in #7222 and would prevent drift.
- Impact: High; Difficulty: Medium.

3) **Fail-loud for missing optional artifacts (preloads/interceptors)**
- If a feature flag expects a preload file, log a warning/error instead of silently filtering (suggested in #7210).
- Impact: High; Difficulty: Low.

### E) Connector correctness: Telegram race + Slack silent drops risk
1) **Enforce “single owner per bot token”**
- At runtime boot: detect multiple Telegraf pollers / duplicate connector activation; refuse to start second instance and log remediation steps.
- Impact: High; Difficulty: Medium.

2) **Connector reliability test harness**
- Integration test that sends N messages and asserts N replies for Telegram/Slack connectors (can be mocked or sandbox-based).
- Impact: High; Difficulty: High (depends on test infra).

3) **Standardize connector error handling**
- Add try/catch wrappers around external API calls on message ingestion; persist a “failed to enrich user info” memory rather than dropping events.
- Similar approach: Slack Bolt apps commonly wrap user lookup and continue processing with partial context.
- Impact: Medium–High; Difficulty: Low–Medium.

### F) Unanswered hosting/hardware cost questions
1) **Publish a “Self-hosting cost & sizing” page**
- Profiles: hobby (Mac mini), small VPS, k8s; include rough RAM/CPU and estimated token/provider costs.
- Impact: Medium–High; Difficulty: Low.

2) **Add a “deployment presets” section**
- Docker compose minimal, Fly.io/Railway template, and “k8s reference”.
- Impact: Medium; Difficulty: Medium.

---

## 4) Communication Gaps (expectations vs reality)

### Key mismatches
- **Expectation:** “Twitter login works without X API.”  
  **Reality:** X API now required (Discord May 7). Users only find out after they try to set up posting.

- **Expectation:** “If a plugin exists, it’s stable and discoverable.”  
  **Reality:** Hyperfy plugin link 404 + version mismatch; workaround required via DM zip (Discord May 7).

- **Expectation:** “Onboarding flows detect my existing provider login.”  
  **Reality:** Codex CLI auth file shape changed; detection fails and UI reports “install required” (Issue #7243).

### Recurring questions that indicate onboarding/doc gaps
- “Is X API required / how much does it cost?”
- “Where did plugin X go / why is the link 404?”
- “What hardware/hosting do I need to run a bot?”

### Specific documentation/onboarding fixes
- Add “**Connector prerequisites**” section for each connector (X, Telegram, Slack): required credentials, paid tiers, common failure modes.
- Add “**First-run checklist**” with a single verification command (e.g., `eliza doctor`) that checks:
  - DB tables migrated
  - connector single-instance
  - auth credentials detected
  - required build artifacts present

---

## 5) Community Engagement Insights

### Power users & their needs (observed)
- **Sw4pIO (GitHub issues):** High-signal bug reporter providing repro steps, root cause, and verified fixes.  
  **Needs:** fast review/merge loop, a clear place to propose “guardrail” checks (schema validation, fail-loud policies).
- **odilitime (Discord helper):** Acts as frontline support; provided workaround zip via DM.  
  **Needs:** official tooling/registry so support doesn’t rely on DMs and ad-hoc file sharing.
- **Shaw (Discord):** Communicates repo consolidation and infra decisions; sets expectations on governance.  
  **Needs:** a stable “official announcements” surface so key changes aren’t buried in chat.

### Newcomer friction signals
- Multiple intros asking “who to contact” for collaboration; questions asked without resolution (hosting costs/hardware).
- Suggests newcomers don’t know: where to ask, what info to include, and how to get answers.

### Converting passive users into contributors
- Create “**Good First Issue: Docs**” around X API requirements, plugin compatibility matrix, and self-host sizing.
- Create “**Plugin Maintainer Needed**” labels (e.g., Hyperfy) with explicit ownership + compatibility target.
- Recognize high-quality triage (like Sw4pIO) with a “Triage Captain” rotation and faster maintainer feedback.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness (from this snapshot)
- **Discord discussion** has low actionable feedback density on May 8 (mostly showcases/introductions). Support questions appear but can go unanswered (May 6).
- **GitHub issues** are high quality for technical defects (clear repro steps, fixes), but likely under-captures beginner confusion (costs, prerequisites).

### Improvements for more structured, actionable feedback
1) **Add an “eliza doctor” diagnostic output template**
- Encourage users to paste a standardized snippet (OS, bun/node version, enabled plugins, connector states).
2) **Discord intake forms / pinned “How to get help”**
- Required fields: goal, connector, logs, version, what changed recently.
3) **Weekly “Top 5 friction” poll**
- Lightweight checkboxes: onboarding, connectors, docs, performance, plugins. Produces trend data.

### Underrepresented segments whose feedback is missing
- **Non-developer end-users** of agent-built apps (most feedback is builders).
- **Windows self-hosters** (some CI mentions; little direct user narrative here).
- **Small teams deploying to k8s** (showcase exists, but not framed as feedback/problems).

---

## Prioritized High-Impact Actions (next 1–2 weeks)
1) **Ship a “Fresh Install Smoke Test” CI gate** to catch onboarding-killer regressions (missing tables, missing artifacts, broken client methods).  
2) **Publish + surface “X/Twitter prerequisites & costs”** in docs and the connector UI (reduce surprise paywall confusion).  
3) **Implement an official Plugin Registry lifecycle + compatibility matrix**, and add automated link/404 checks (prevents Hyperfy-style confusion).  
4) **Add connector guardrails for “single owner per bot token”** and harden ingestion error handling to prevent silent message loss (Telegram now; Slack next).  
5) **Fix/monitor community status surfaces** (daily summary pipeline monitoring + banner) so builders can trust “what changed” information.