# User Feedback Analysis — 2026-05-04 (based on data through 2026-05-03)

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

**Sample size note:** This analysis is based on the captured feedback threads across Discord summaries (May 1–3) plus the highest-signal GitHub issues/PR discussions included in the dataset (notably issues #7210, #7222, #7243–#7245, and runtime/vault headless Linux crash fixes). In this sample, most severe friction shows up as “onboarding-breaking” bugs (auth/DB/connectors) and “expectation misalignment” (token/roadmap).

### A. Documentation (High frequency, high severity)
1) **Roadmap clarity and “what’s shipping when” confusion**  
   - Example: odilitime explicitly recommended making the roadmap/plan clearer; coordinated posting a visual roadmap and planned a GitHub text update.  
   - Symptom questions: “When will ElizaOS V3 launch?”; “What’s the plan?”; “What happened to Babylon airdrop?” (unanswered in the provided thread).
2) **Token economics expectations vs product reality not documented in a durable place**  
   - Example: repeated buyback questions; Shaw reiterating “token holders are not investors; buybacks require revenue.”

**Who it affects most:** Newcomers, token-focused community members, and potential builders trying to gauge platform maturity and near-term direction.

---

### B. Community (High frequency, high severity)
1) **Tone/communication style friction during token-price debates**  
   - Example: community complaints about “poor communication,” “unfulfilled promises,” and claims of insulting responses; tension between “builders vs speculators.”  
2) **Unanswered recurring questions lead to rumor loops**  
   - Example: “Babylon airdrop” question appears unresolved in the captured FAQ log; exchange-listing discussions can’t be public due to NDA, which increases speculation.

**Who it affects most:** Token holders and passive community members evaluating whether to stay engaged.

---

### C. Technical Functionality (High frequency, very high severity)
1) **Fresh install / fresh DB experiences can be broken by silent schema drift**  
   - Example: GitHub issue #7222: missing drizzle `pgTable` defs for tables that app code queries; results in repeated query failures and unusable chat on a fresh PGLite boot.
2) **Connector/runtime conflicts causing silent message loss**  
   - Example: GitHub issue #7245: Telegram dual-poller race between milady wrapper and `@elizaos/plugin-telegram` causing ~50% message drop “sometimes it replies, sometimes it ignores.”
3) **Client architecture duplication causing UI hard failures**  
   - Example: GitHub issue #7244: duplicate `MiladyClient` class leads to augmented methods undefined → UI crashes and chat input becomes unresponsive.

**Who it affects most:** Builders/self-hosters, and anyone onboarding via Milady app or Telegram/Discord connectors.

---

### D. Integration (Medium frequency, high severity)
1) **Auth detection/import mismatches for external tools**  
   - Example: GitHub issue #7243: Codex CLI auth file changed shape; UI incorrectly reports “install required,” preventing auto-enable/routing.  
2) **Anthropic subscription/OAuth path fragile due to missing preload artifact**  
   - Example: GitHub issue #7210: `dev-ui.mjs` references `claude-code-stealth.mjs` that doesn’t exist on fresh clone; results in 401s that look like user error.

**Who it affects most:** Developers using subscription-based auth flows (Codex CLI, Anthropic OAuth) and anyone following docs/tutorials on a clean clone.

---

### E. Performance / Reliability (Medium frequency, very high severity on servers)
1) **Headless Linux runtime instability due to keyring/libsecret**  
   - Example: PR #7230 fixed a process-level segfault on headless Linux by adding D-Bus detection fallback / skipping OS keychain in headless contexts.

**Who it affects most:** Self-hosted server deployments and CI-like environments.

---

### F. UX/UI (Medium frequency, medium severity)
1) **Automation UX gaps (clarification loop partially built / confusing)**  
   - Example: n8n clarification roundtrip work (#7316) indicates the product previously surfaced `_meta.requiresClarification` but UI didn’t render it; users likely experienced “workflow generation failed / stuck” without clear next-step prompts.  
2) **Security/Settings UX complexity around secrets**  
   - Example: Vault integration (#7197) is a major improvement, but implies prior UX stored plaintext config/env and had unclear “primary credential param” heuristics.

**Who it affects most:** Automation users and self-hosters managing multiple connectors/keys.

---

### G. Documentation/UX (Low frequency, medium severity)
1) **Discord spam filter blocks legitimate links**  
   - Example: sentient_dawn couldn’t share a URL; workaround suggested: wrap URLs in backticks.

**Who it affects most:** Helpers/power users sharing fixes, and anyone trying to collaborate quickly.

---

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

### What users are actually building/doing
1) **Trading agents are a primary real-world driver (not just “agent framework demos”)**  
   - Evidence:
     - marianodim building a spot trading agent for SOL/SUI + 5 tokens (1–2 signals/week).
     - Shaw highlighting `plugin-auto-trader`, `plugin-social-alpha`, and “Spartan” as key repos.
     - “Social copy trading” concept: `plugin-social-alpha` analyzing “trenches channels” for profitability of social signals.
2) **Automation-as-product (n8n workflows) is moving from “nice-to-have” to core usage**  
   - Evidence: multiple PRs centered on clarification loops, connector target catalog, and restoring NL-first hero UI in Automations Overview.
3) **Long-lived agents in production are hitting “memory rot” after ~3 months**  
   - Evidence: sentient_dawn’s field report + mitigation (freshness gates, periodic diffs, re-embedding).
4) **Hardware/robotics integrations are emerging** (unexpected but high leverage showcase)
   - Evidence: shawmakesmagic running Eliza on a Unitree robot to walk around on command.

### Mismatch vs intended positioning
- Intended: “developer-focused framework comparable to Linux” (odilitime’s Orbofi comparison).  
- Actual: Many participants behave like *product/token consumers* seeking timelines, buybacks, and price support. This creates recurring friction in Discord.

### Feature requests that align with observed usage
- **Trading:** safer strategy backtesting, clearer plugin templates for signal generation + execution + risk controls; “social alpha → copy trader” pipeline.
- **Automation:** full clarification UI in chat, plus connector-aware quick-picks (guild/channel pickers) to reduce failure rate.
- **Long-lived memory:** first-class “memory reconciliation” job support and visibility into stale facts.

---

## 3) Implementation Opportunities (Concrete solutions, prioritized)

### Pain Point 1: Roadmap + expectation confusion (Documentation/Community)
**Impact:** High (reduces churn, repeated debates, and support load)  
**Difficulty:** Low–Medium

1) **Ship a “Single Source of Truth” roadmap page with explicit status taxonomy**  
   - Implement: `/roadmap` in GitHub Pages + pinned Discord announcement linking to it.  
   - Include: “Now / Next / Later,” plus “Confirmed vs exploratory,” and explicit dependency notes (e.g., “buybacks require revenue”).  
   - Similar approach: Kubernetes enhancement proposals (KEPs) + public roadmap boards; many OSS projects pin a “Project status” doc.
2) **Publish a persistent FAQ that answers the top recurring questions**  
   - Include: buybacks preconditions, V3 target window (even if broad), Babylon airdrop status (even if “canceled/unknown”), NDA boundaries for listings.  
   - Similar approach: Arbitrum/Optimism and other tokenized ecosystems reduce speculation with “what we can/can’t say” pages.
3) **Introduce a “Weekly shipping note” format** (3 bullets shipped, 3 in progress, 3 risks)  
   - Leverage existing development summaries but rewrite for community comprehension.  
   - Similar approach: Home Assistant weekly release notes; Rust “This Week in Rust.”

---

### Pain Point 2: Fresh install breaks (schema drift, missing artifacts) (Technical Functionality)
**Impact:** Very High (blocks adoption)  
**Difficulty:** Medium

1) **Add “fresh clone smoke tests” for Milady + core workflows**  
   - Test cases:
     - New PGLite boot creates all required tables (guards against #7222 class of issues).
     - Anthropic OAuth preload artifact present or explicit warning (guards against #7210).
     - Codex CLI auth detection works for both legacy and modern shapes (#7243).  
   - Similar approach: Next.js “create-next-app” CI smoke; Supabase CLI uses migration verification checks.
2) **Create a schema-source-of-truth validator** for `plugin-sql`  
   - Implement: at plugin init, compare abstract schemas barrel vs drizzle `pgTable` registry; fail loud (or at least warn) if missing tables.  
   - Similar approach: Prisma migration drift detection; Rails schema consistency checks in CI.
3) **Replace “silent fallback” with explicit UI/CLI errors**  
   - Example: if stealth preload missing, log “Anthropic subscription auth requires X file; run build step Y.”  
   - Similar approach: Vite/ESBuild ecosystem typically fails loud on missing entrypoints.

---

### Pain Point 3: Telegram reliability + connector ownership ambiguity (Integration/Technical Functionality)
**Impact:** Very High (user-facing message loss)  
**Difficulty:** Medium

1) **Enforce single poller per bot token** (tactical fix)  
   - Implement: runtime guard: if wrapper polling is enabled, auto-disable `@elizaos/plugin-telegram` (or vice versa) and log a single clear line.  
2) **Converge onto one canonical Telegram integration path** (strategic fix)  
   - Fix Bun/Telegraf launch issues upstream and delete the duplicate wrapper once stable.  
   - Similar approach: Discord.js bots typically centralize gateway connection ownership to prevent duplicate event consumers.
3) **Add a delivery-integrity test**  
   - Simulate N messages → assert N replies (or at least N received) in e2e harness.

---

### Pain Point 4: Auth + subscription detection mismatches (Integration/UX)
**Impact:** High (prevents using paid subscriptions; misleads users)  
**Difficulty:** Low–Medium

1) **Support multiple credential shapes with explicit provenance**  
   - Example: Codex CLI: detect both legacy and `tokens.access_token` shapes; store “source=codex-cli.”  
2) **Add an in-app “Auth diagnostics” panel**  
   - Show: detected providers, where credentials were found (vault/env/file), last validation time, and next remediation step.  
   - Similar approach: GitHub CLI and AWS tooling provide “auth status” commands that reduce guesswork.
3) **Make auto-enable decisions explainable**  
   - When a plugin is not auto-enabled, show a tooltip/log: “Not enabled because no valid token detected” + link to doc.

---

### Pain Point 5: Headless Linux stability (Performance/Reliability)
**Impact:** High for self-hosting; reduced crash reports  
**Difficulty:** Medium (mostly already underway)

1) **Codify “headless mode” behavior**  
   - Document and implement a consistent rule: prefer passphrase/env-derived master key on servers; skip OS keychain.  
2) **Add a `--diagnose-secrets` CLI command**  
   - Reports: keyring availability, D-Bus detection, vault status, and fallback path chosen.  
   - Similar approach: Docker “docker info”; Node “--trace-warnings” style debugging.

---

### Pain Point 6: Discord spam filter blocks collaboration (Community/UX)
**Impact:** Medium (slows support/help loops)  
**Difficulty:** Low

1) **Add an allowlist + trust-based link posting**  
   - Allow common domains (github.com, docs site, discord cdn, etc.) and give “Helpers/Contributors” a looser rule set.  
2) **Replace “backticks workaround” with a bot hint**  
   - When a message is blocked, DM the user: “Your link was blocked; try X; request allowlist via Y.”  
   - Similar approach: many Discord servers use AutoMod + modmail with structured remediation.

---

### Pain Point 7: Long-lived agent memory rot (Technical Functionality / Product quality)
**Impact:** Emerging but potentially very high for production deployments  
**Difficulty:** Medium–High

1) **Adopt “memory reconciliation” as a first-class scheduled job**  
   - Provide hooks: freshness gates on claims, periodic cross-source diffs, re-embedding under current ontology (per sentient_dawn’s proven approach).  
2) **Add “staleness observability”**  
   - Track: last verified timestamps on facts; show confidence decay; alert when contradictions detected.  
   - Similar approach: knowledge graph systems and RAG stacks increasingly attach temporal metadata + verification pipelines.

---

## 4) Communication Gaps (Expectations vs reality)

1) **“Token holder” expectations vs “open-source builder” reality**  
   - Recurring mismatch: users request buybacks/price actions; team frames token as non-equity and emphasizes long product runway (8-year IPO analogy).  
   - Fix: publish a “What the token is / isn’t” page and link it whenever token debates spike.
2) **Release timing ambiguity (V3, Cloud, Milady)**  
   - Question “When will V3 launch?” appears repeatedly without a concrete window in the captured thread.  
   - Fix: even a coarse target (“weeks, not months”) reduces churn; if unknown, say what gates must be met.
3) **“Can’t discuss listings” creates a vacuum**  
   - NDA constraint is real; without a standard explanation, users interpret silence as inaction.  
   - Fix: standardize a short policy statement and re-use it consistently.
4) **Unanswered program promises (e.g., Babylon airdrop)**  
   - The question appears and remains unanswered in the captured log, amplifying distrust.  
   - Fix: explicitly close the loop: delivered / delayed / canceled / unknown + next update date.

---

## 5) Community Engagement Insights

### Power users and their needs (and how to leverage them)
- **odilitime**: community ops + roadmap comms; repeatedly bridging tension with actionable steps (roadmap posting, workaround explanations).  
  - Need: tooling to publish updates easily (templated announcements, roadmap sync).
- **sentient_dawn**: deep technical research (memory rot) + active helper; blocked by spam filter when sharing links.  
  - Need: frictionless knowledge sharing + a channel for long-form technical field reports.
- **Sw4pIO**: high-signal bug reporter (auth/db/telegram) providing reproducible steps and verified fixes.  
  - Need: fast triage feedback loop, “verified reporter” tag, and a clear path to submit PRs.
- **2-A-M / standujar / NubsCarson**: shipping core infrastructure and UX improvements (automation, cloud auth, cross-platform stability).  
  - Need: user feedback loops that confirm whether changes reduce real-world onboarding failures.

### Common newcomer questions indicating onboarding friction
- “How do buybacks work / when?”  
- “When is V3?”  
- “What is plugin-social-alpha for?”  
- “How do I share a link if the spam filter blocks it?”  
- “How do I join the steering group?”

### Converting passive users into contributors
1) Create **“Good First Issue: Onboarding reliability”** label and bundle tasks like auth-shape detection, doc fixes, and smoke tests.  
2) Run a **monthly bug bash** focused on “fresh install to first success” for: chat, Telegram, n8n workflow, trading plugin template.  
3) Provide **starter templates**: “trading agent template,” “telegram bot template,” “n8n automation template,” each with a known-good path.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord**: excellent for sentiment and quick Q&A, but token-price debates can drown product feedback; spam filters can block legitimate collaboration.  
- **GitHub issues**: high-quality, reproducible technical feedback (notably from Sw4pIO), but not all users file issues—many fail silently and churn.

### Improvements for more structured, actionable feedback
1) **Add an in-app “Report a problem” exporter**  
   - Auto-collect: OS, bun/node versions, enabled plugins, connector states, last 200 lines of logs (redacted), vault/keyring mode.  
   - Output: a prefilled GitHub issue using a strict template.
2) **Introduce a weekly “Top 5 support questions” digest**  
   - Convert repeating Discord questions into docs/FAQ updates; measure reduction week-over-week.
3) **Tag Discord threads into categories** (roadmap, trading, automation, connectors, auth) via moderators/helpers and mirror into GitHub Discussions.

### Underrepresented user segments (missing feedback)
- **Non-trading enterprise/workflow users** (aside from n8n signals, most visible usage is trading/token related).  
- **Self-hosted server operators** (headless Linux crash implies they exist, but their broader needs aren’t captured).  
- **Robotics/hardware builders** (promising showcase, but no structured feedback channel).

---

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

1) **Stabilize “fresh install → first success” with CI smoke coverage** (DB schema presence, auth artifact checks, connector single-owner rules).  
2) **Publish a canonical roadmap + FAQ (V3/Cloud/Milady + token/buyback policy + Babylon airdrop status)** and pin it in Discord + keep GitHub text version in sync.  
3) **Fix/guard Telegram single-poller ownership and add delivery-integrity tests** to eliminate silent message loss.  
4) **Add “Auth diagnostics + explainable auto-enable” UX** so users understand why a provider/plugin isn’t working (Codex/Anthropic especially).  
5) **Reduce Discord collaboration friction** by implementing link allowlists/trust tiers and automated remediation messaging when AutoMod blocks URLs.