## User Feedback Analysis — 2026-05-06 (Aggregated from 2026-05-03 to 2026-05-05 + recent GitHub activity)

### Data snapshot (for quantification)
- Sources included in this digest: Discord summaries (3 days) + top GitHub issues/PR review notes referenced in the aggregated dataset.
- Counted feedback signals (distinct, user-impacting items): **~12** (7 Discord themes/questions + 5 GitHub issues with end-user impact).
- Percentages below are approximate and refer to this limited sample.

---

## 1) Pain Point Categorization (Top recurring friction: 7)

### A) **Integration** (highest frequency + user-visible breakage)
**What users struggle with**
1) **Token bridging / migration confusion (BSC ↔ Solana; ai16z → ElizaOS)**  
   - Discord: repeated questions: “How to bridge elizaos from bsc to solana?”; “Is there any way to migrate ai16z to ElizaOS?”  
   - Severity: high (users at risk of scams + blocked from participation).  
   - Frequency: **~17% (2/12)** directly, but amplified by scam volume.

2) **Telegram reliability regressions (message loss / duplicate polling)**  
   - GitHub: two Telegraf consumers polling same bot → **silent message drops** (#7245).  
   - Severity: very high (appears “randomly broken” to end users).

3) **Slack plugin message-drop risk due to unhandled API errors**  
   - PR review notes flag missing try/catch around user lookup leading to silent drops (plugin-slack migration PR #7375).  
   - Severity: high (connector correctness is foundational).

**Who is most impacted**
- Self-hosters, builders integrating with Telegram/Slack/Discord, and “agent as a community bot” deployments.

---

### B) **Technical Functionality** (blocked core features; “it runs but doesn’t work”)
**What users struggle with**
1) **Authentication detection & credential routing mismatches**  
   - GitHub: Codex CLI auth file format changed; UI says “install required” though logged in (#7243).  
   - GitHub: Anthropic subscription path fails because stealth preload file missing on fresh clones (#7210).  
   - Severity: high (prevents providers from working, creates misleading UI states).

2) **Database schema drift causing partial-state prompts & parsing failures**  
   - GitHub: plugin-sql runtime migrator missing tables → providers fail; chat becomes unusable on fresh DB (#7222).  
   - Severity: critical for new installs (“fresh start” path broken).

**Who is most impacted**
- New installations (fresh clones), local-first users, anyone relying on subscription auth flows.

---

### C) **Community / Safety**
**What users struggle with**
1) **High scam exposure around bridging/migration**  
   - Discord: multiple scam warnings; explicit mentions of scam links around migration/bridging; requests to ban scammers.  
   - Severity: critical (financial loss + trust damage).  
   - Frequency: **~25% (3/12)** explicit signals, plus implicit impact on bridging questions.

---

### D) **UX/UI**
**What users struggle with**
1) **UI states that misrepresent backend reality (especially auth/setup)**  
   - Example: Codex shows “install required” even when authenticated (#7243).  
   - Result: users distrust Settings/Connectors and resort to manual file edits.

2) **Discord spam filter blocks legitimate URLs**  
   - Discord: URL posting blocked; workaround is “wrap in backticks” (5/3).  
   - Severity: medium, but harms support and onboarding.

---

### E) **Documentation**
**What users struggle with**
1) **Missing “official” migration/bridging guide**  
   - Repeated bridging questions + scam risk indicate documentation absence or hard-to-find guidance.  
   - Severity: high due to safety implications.

2) **Unclear “what is shipping vs vision” (roadmap, releases, hidden features)**  
   - Discord: references to “hidden features” and broad claims of scale; also “v2.0.0-beta.0 pushed” without user-facing release notes.  
   - Severity: medium; creates expectation misalignment.

---

### F) **Performance**
**What users struggle with**
- Not directly reported as end-user complaints in this sample, but performance is a visible development theme:
  - Discord: eliza-1 training includes speculative decoding, compression, quantization (dflash, caveman compression, turboquant).
- Risk: without clear benchmarks, users can’t validate improvements or choose configs.

---

### G) **Community (Operations)**
**What users struggle with**
- Discord operational friction: bot management issues; liquidity concerns on Solana (5/4).  
- Severity: low-to-medium, but affects community confidence and support quality.

---

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

### Observed “real” usage
1) **Agents as multi-channel bots** (Discord/Telegram/Slack)  
   - Users expect connector paths to be robust “out of the box” (no silent drops, no double polling, clear errors).

2) **Automation + workflow generation (n8n)**  
   - The project is moving toward clarification loops and better workflow UX (multiple merged PRs around clarification requests and UI quick-picks).  
   - This suggests strong demand for “agent builds automations from natural language”.

3) **Token/market-adjacent workflows** (bridging, migration, copy trading signals)  
   - Discord: bridging questions and scam traffic cluster around token operations; repos shared include trading/social alpha plugins (copy trading evaluation).

4) **Self-hosting + Cloud hybrid**  
   - Cloud monetized apps, domain flows, and app-scoped chat indicate users are deploying production apps—not just demos.

### Emerging / unexpected use cases
- **Monetized agent-built apps with custom domains** (Cloud: domain purchase/sync/verify; app-scoped chat). This pushes elizaOS into “AI app platform” expectations (billing correctness, auth correctness, CORS correctness).

### Feature requests aligned with actual usage
- “One-click” **safe bridging/migration** UX: verified links + in-app warnings.
- Connector reliability guarantees: “exactly-once” update handling patterns; anti-duplication safeguards.
- Auth/import “doctor” that validates provider credentials and explains failures.

---

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

### Pain Point 1: Token bridging/migration confusion + scams (Integration + Community/Safety)
**Solutions (prioritized)**
1) **High impact / Low–Med effort:** Publish a canonical “Migration & Bridging” page and pin it everywhere  
   - Include: supported chains, *official* bridges (e.g., Wormhole, deBridge as mentioned by users), step-by-step, and “common scam patterns”.  
   - Add an “ONLY trust these domains” allowlist.  
   - Similar approach: many crypto projects maintain a single “Official Links” + “Bridge Guide” doc and auto-delete non-allowlisted bridge links in chat.

2) **High impact / Medium effort:** Discord anti-scam automation tuned for bridging keywords  
   - Auto-respond to “bridge/migrate” keywords with the pinned guide.  
   - Auto-quarantine messages containing new/untrusted domains.  
   - Add a `/report-scam` command that collects link + user ID for mods.

3) **Medium impact / Medium effort:** In-app (or dashboard) “Bridge status + verification” banner  
   - If elizaOS has a UI surface for token utilities, show verified bridge options and warnings.

---

### Pain Point 2: Connector message loss (Telegram/Slack) (Integration)
**Solutions (prioritized)**
1) **High impact / Low effort:** Enforce “single poller per token” guardrail (Telegram)  
   - Add runtime startup check: if wrapper polling is enabled, **force-disable plugin polling** (or vice versa) and log loudly.  
   - Provide a config linter that outputs a red “Double polling detected” warning.

2) **High impact / Medium effort:** Add at-least-once delivery + idempotency on inbound updates  
   - Track `update_id` (Telegram) / `event_id` (Slack) in storage; ignore duplicates; ensure no silent drops.  
   - Similar approach: Slack Bolt apps often use retry headers + dedupe stores; Telegram bots commonly persist last processed update IDs.

3) **High impact / Low–Med effort:** “Never drop silently” policy on connector handlers  
   - Wrap Slack `users.info` calls in try/catch; if lookup fails, proceed with a fallback identity object and store memory anyway.  
   - Emit structured error events that can be surfaced in UI (“Slack API rate limited; message processed with partial metadata”).

---

### Pain Point 3: Auth detection & subscription flows failing (Technical Functionality + UX)
**Solutions (prioritized)**
1) **High impact / Low effort:** Update credential detectors to support both legacy + modern formats (Codex + Anthropic)  
   - Codex: accept `tokens.access_token` shape.  
   - Anthropic: ensure the preload artifact exists on fresh clones OR fail loudly with a targeted warning.

2) **High impact / Medium effort:** Add a “Provider Auth Doctor” command + Settings panel  
   - One button runs checks: “found token file”, “token valid”, “provider reachable”, “selected plugin enabled”, “routing target correct”.  
   - Similar approach: Kubernetes “diagnostics”, Vercel “checks”, and many CLIs provide `doctor` commands that drastically reduce Discord support burden.

3) **Medium impact / Medium effort:** Make UI status reflect real runtime routing  
   - If auto-enable is skipped, explain why (e.g., “Detected Codex auth file but unsupported format; update required”).

---

### Pain Point 4: Fresh-install DB/schema failures (Technical Functionality)
**Solutions (prioritized)**
1) **High impact / Medium effort:** Add schema-source-of-truth validation at boot  
   - On plugin-sql init: verify every abstract schema has a corresponding drizzle `pgTable` migrator entry; fail startup with explicit action items.  
   - Similar approach: Prisma migration checks, Rails schema consistency checks.

2) **High impact / Low effort:** Add smoke tests for “fresh PGLite boot + first chat turn”  
   - CI should run: create empty DB → boot → send message → assert no provider errors.

3) **Medium impact / Medium effort:** Consolidate schema definitions to avoid drift  
   - Generate drizzle schemas from abstract schemas (or invert: derive abstract from drizzle) to eliminate parallel definitions.

---

### Pain Point 5: Discord spam filter blocks legitimate URLs (UX + Community Ops)
**Solutions (prioritized)**
1) **Medium impact / Low effort:** Allowlist common dev domains + GitHub + official bridge domains  
2) **Medium impact / Medium effort:** Add “trusted poster” role bypass for established contributors  
3) **Low–Med impact / Low effort:** Improve bot message explaining how to post URLs safely (auto-DM with instructions)

---

## 4) Communication Gaps (expectations vs reality)

1) **“Token holders as investors” vs builder-first roadmap reality**  
   - Discord shows tension around buybacks/price action; Shaw clarifies revenue-first, long timelines.  
   - Gap: newcomers arrive with investor expectations; project messaging is infrastructure/product-focused.

   **Improve by**
   - A short, pinned “Economic expectations” explainer: what the team will/won’t do, what milestones unlock what mechanisms.

2) **“Hidden features” and scale claims vs actionable onboarding**  
   - Claims about scaling to hundreds of thousands of agents and hidden features are inspiring but increase expectation pressure.  
   - Gap: users ask basic “how do I bridge/migrate” and “why isn’t my connector working”.

   **Improve by**
   - Pair vision posts with “Getting Started: 30 minutes to first working agent on X platform” and “Known issues” sections.

3) **Release signal without user-facing notes (v2.0.0-beta.0)**  
   - Users see version mention but not what changed or what to test.

   **Improve by**
   - Beta release notes with “top 5 changes”, “migration steps”, “what feedback we need”.

---

## 5) Community Engagement Insights

### Power users / high-leverage contributors (and their needs)
- **Shaw**: deep model/training updates; needs a structured way to convert technical progress into user-testable outcomes (benchmarks, “try it here” artifacts).
- **Odilitime** (moderation + ops): needs better anti-scam tooling and less support load from repeated migration questions.
- **satsbased**: provides practical bridging help; could be empowered with a canonical link to share.
- **Sw4pIO**: high-signal bug reporter (auth/Telegram/schema). Needs fast confirmation, labels, and a “repro harness” path to keep reporting.
- **2-A-M / standujar / NubsCarson / lalalune**: shipping platform features and fixes; benefit from clearer “top user pain” priorities.

### Newcomer friction signals
- New dev introductions (e.g., rsn6958) suggest onboarding demand, but the most visible questions are still basics (migration, bridging, posting URLs).

### Converting passive users into contributors
- Create “Good first fix” lists tied to current pain:
  - connector try/catch hardening
  - docs improvements (bridging guide)
  - CI smoke tests for fresh install
- Offer a monthly “Bug bounty (non-monetary)” leaderboard (credits, roles, shoutouts) for reproducible reports.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord**: great for real-time triage, but repetitive questions + scams overwhelm; hard to extract structured bugs.
- **GitHub issues**: high-quality when submitted (Sw4pIO reports are exemplary), but many users likely never file issues.

### Improvements (structured + actionable)
1) **Add a “Migration/Bridging” intake form** (Discord → form → curated FAQ updates)  
2) **Add connector-specific issue templates** (Telegram/Slack/Discord) requiring:
   - runtime (bun/node), plugin version, connector config, logs snippet, and reproduction steps
3) **Add an in-app “Report a problem” button** that auto-attaches anonymized diagnostics (enabled plugins, provider routing, connector states)

### Underrepresented segments
- Non-crypto “pure agent framework” users: current Discord visibility is skewed toward token/market discussion and migration/scam topics.
- Enterprise/self-host ops users: we see signals (headless, auth, domains) but not direct feedback from production operators; consider periodic ops survey.

---

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

1) **Publish and pin an official Migration & Bridging guide + verified link allowlist** (reduces scams + repeated questions; high safety impact).  
2) **Implement connector “no silent drops” hardening + single-poller safeguards (Telegram) and try/catch on Slack inbound path** (directly improves user trust in agents as bots).  
3) **Add a “Provider/Auth Doctor” (CLI or UI) and fix credential detection for modern Codex + ensure Anthropic subscription path fails loudly** (cuts onboarding failures and misleading UI).  
4) **Add CI smoke test: fresh DB boot → first chat turn succeeds (plugin-sql schema completeness)** (prevents “fresh install is broken” regressions).  
5) **Tune Discord anti-spam to reduce false positives on legitimate links while keeping scam protection** (improves support velocity without sacrificing safety).