## User Feedback Analysis — 2026-05-02 (based on 2026-04-29 to 2026-05-01 inputs)

### Dataset notes (for quantification)
- Sources included: Discord (#discussion, #coders) and GitHub issues/PR threads referenced in the aggregated feed.
- Identified **~12 distinct “feedback events”** (user questions, problem reports, or requests). Percentages below are **share-of-events** (directional, not statistically rigorous).

---

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

### A) Documentation — **Positioning & “what is ElizaOS?” confusion** (≈17%, high frequency / medium severity)
**Observed problems**
- Repeated questions on **ElizaOS vs Orbofi** (“main advantage”, “why more robust?”) indicate users lack a crisp mental model of intended audience and tradeoffs.
  - Example: *zeerlayer* asked for deeper explanation; *odilitime* responded with Linux vs Shopify/App Store analogy and “build serious agents from scratch” framing.
- App-store layer messaging is muddy: “with Milady, ElizaOS now has an app store component,” but the boundaries between framework vs “store” aren’t clear.

**Who it impacts most**
- Newcomers evaluating whether to build on ElizaOS vs choose a consumer platform.

---

### B) Technical Functionality — **Fresh-clone / first-run failures that make chat unusable** (≈17%, very high severity)
**Observed problems**
- GitHub issue: `plugin-sql` runtime migrator missing Drizzle `pgTable` defs causes missing tables (`entity_identities`, etc.), producing cascading provider/evaluator failures and “internal parsing error” symptoms.
  - Example: issue #7222 describes **5+ errors per message** and effectively non-functional chat on a fresh PGLite DB.
- GitHub issue: dev preload references a missing `claude-code-stealth.mjs`, breaking Anthropic subscription OAuth path with 401s.
  - Example: issue #7210: silent filtering of missing preload file → interceptor never installs → subscription users hit `401 Invalid authentication credentials`.

**Who it impacts most**
- Developers trying to run locally for the first time (or boot consumer wrappers like Milady).

---

### C) Integration — **Self-hosted + cross-platform auth/CORS edge cases** (≈17%, high severity)
**Observed problems**
- Self-hosted connectivity expanded (HTTPS dashboards, Capacitor mobile, Electrobun desktop), but auth flows have fragile edges:
  - PR review notes a case where an **invalid token can retry until timeout instead of prompting pairing UI** (401 loop → generic backend timeout).
- CORS complexity rises with mobile WebView origins + operator-set allowed origins; users will likely struggle to know which env vars to set and how to debug.

**Who it impacts most**
- Self-hosters and builders shipping mobile/desktop wrappers.

---

### D) Technical Functionality — **Long-lived agent reliability: “memory rot” after ~3 months** (≈17%, high severity, emerging)
**Observed problems**
- *sentient_dawn* reports “memory rot” in retrieval-only architectures (RAG/vector store + LLM): stale facts persist, contradictions accumulate, drift is invisible until humans notice.
- Community request: *mayoe76* asked for the full field report, indicating strong demand for operational guidance.

**Who it impacts most**
- Power users running persistent agents in production (automation, trading, long-running social agents).

---

### E) Integration / Platform Constraints — **Model access & moderation refusals (ChatGPT “cyber” refusals / flags)** (≈8%, medium severity)
**Observed problems**
- *shawmakesmagic* hit “ChatGPT cyber refusals” on v5.5; mentions applying for special access; also mentions conversations flagged for violations.
- This reads as a practical “I can’t do the task I need” friction, but root cause is partly upstream provider policy.

**Who it impacts most**
- Users building security/cyber-themed agents or running prompts likely to trigger refusal policies.

---

### F) Community — **Token/exchange expectation management & NDA constraints** (≈8%, medium frequency / low-to-medium severity)
**Observed problems**
- Recurring exchange listing questions (e.g., Coinbase) met with “NDA, can’t discuss.”
- On Apr 30–29, funding/token collapse context produced dissatisfaction and skepticism about viability; team explains constraints and avoids promises.

**Who it impacts most**
- Traders/community members evaluating project health via token performance rather than shipped product.

---

### G) Security / Technical — **Secrets management, local data storage, and key security questions** (≈8%, medium severity)
**Observed problems**
- New developer questions on **local LLM data storage**, **agent key security**, and **red-team swarm testing** (Apr 30).
- Good news: `@elizaos/vault` landed (cross-platform secrets vault + Settings UI), but users still need clear best practices for secure deployment.

**Who it impacts most**
- Teams moving from hobby builds to real deployments.

---

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

### How users are actually using ElizaOS
1. **Cross-platform “agent runtime everywhere”**: strong pull toward self-hosted runtime reachable from web, mobile (Capacitor), and desktop (Electrobun). This matches v3’s positioning as “runtime on all devices,” but increases auth/CORS support burden.
2. **Production-grade operations**: users are running agents long enough to hit **multi-month failure modes** (memory rot) and care about reconciliation, freshness, ontology evolution, and drift detection.
3. **Hardware/robotics experimentation**: *shawmakesmagic* integrated Eliza into a **$4k Unitree robot** and issued locomotion commands—an emerging “agents controlling physical devices” use case.
4. **Provider diversity and credential complexity**: Anthropic subscription OAuth, multiple AI SDK updates, and secrets vault work suggest users want to swap providers frequently and expect “credentials just work.”

### Notable feature requests aligned with observed usage
- **Operational playbooks**: request for full “memory rot” report indicates desire for real-world runbooks, not just API docs.
- **Robust onboarding & diagnostics**: fresh clone failures show developers need preflight checks that prevent “it runs but is broken” states.
- **Security-by-default**: vault adoption suggests appetite for secure config flows across platforms, including headless servers.

---

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

### 1) Fresh-clone / first-run failures (SQL schema drift; missing stealth preload)
**High impact / medium difficulty**
1. **Add a boot-time “schema completeness” sanity check** in `plugin-sql`:
   - Compare abstract schema exports vs Drizzle `pgTable` registry; fail fast with a single actionable error listing missing tables.
   - Similar approach: Prisma/TypeORM style migration validation (“pending migrations” / “schema mismatch”) before serving requests.
2. **Introduce an install-time / dev-time “preflight doctor” command** (`eliza doctor`):
   - Checks: required preload artifacts exist, DB tables present, provider creds resolvable, and prints fix steps.
   - Similar approach: `next dev` startup checks; `supabase db doctor`; `firebase emulators:start` diagnostics.
3. **Stop silent failure patterns**:
   - For the stealth preload file: if feature enabled but file missing, log a loud warning and disable the auth mode (do not proceed into ambiguous 401/parse errors).

**Priority rationale**: these issues make the product appear “broken” immediately, blocking adoption.

---

### 2) Self-hosted auth/CORS and invalid-token UX loops
**High impact / medium difficulty**
1. **Explicit invalid-token path to pairing UI**:
   - If `/api/auth/status` returns `required=true` and `authenticated=false`, show pairing/re-auth immediately (don’t loop retries until timeout).
   - Similar approach: GitHub CLI/device flows immediately re-auth on 401 rather than exponential retry.
2. **CORS debugging UX**:
   - Add a `/api/diagnostics/cors` endpoint returning computed allowlist + request origin evaluation (“allowed because …”).
   - Similar approach: many reverse proxies provide “why denied” logs; Stripe CLI style local diagnostics.
3. **Self-host “quickstart profiles”**:
   - Provide reference env templates for: (a) browser-only, (b) browser+mobile, (c) desktop+mobile.
   - Include `ELIZA_ALLOWED_ORIGINS` examples and common pitfalls.

---

### 3) Long-lived agent “memory rot”
**High impact / medium-to-high difficulty**
1. **Formalize a “Memory Maintenance Pipeline” as a first-class module**:
   - Scheduled reconciliation pass (freshness gates, cross-source diffs, re-embedding under current ontology) based on *sentient_dawn*’s proven production approach.
   - Similar approach: search index re-ranking/refresh cycles; knowledge graph “truth maintenance systems.”
2. **Add claim-level provenance + freshness metadata**:
   - Store `source`, `timestamp`, `confidence`, `expiry/TTL`, and “last verified” fields; require the model to surface freshness constraints when making assertions.
3. **Drift detection dashboard**:
   - Track contradiction rate, stale-fact usage, and “last reconciliation run” in a UI panel (even simple counters/logs at first).

---

### 4) Positioning confusion (ElizaOS vs Orbofi; framework vs app store)
**Medium impact / low difficulty**
1. **One canonical comparison page**:
   - “ElizaOS (framework/runtime) vs Orbofi (consumer platform)” with: target user, control vs convenience, deployment model, monetization model.
2. **Explain “app store layer” clearly**:
   - Define what “Milady app store component” means (distribution? plugin registry? hosted apps?) and what it does *not* mean.
3. **Decision tree in onboarding**:
   - “If you want X → choose Y” (e.g., quick consumer launch vs deep agent engineering).

---

### 5) Model access/refusals (ChatGPT “cyber”)
**Medium impact / medium difficulty**
1. **Provider policy guidance + safer defaults**:
   - Add docs: which providers refuse what; recommended alternatives; how to route “sensitive domains” to compliant models.
2. **Refusal-resilient routing**:
   - Detect refusal patterns and automatically fallback to a different provider or to a constrained tool mode.
   - Similar approach: multi-provider routers in LangChain/LlamaIndex; circuit-breakers for API error classes.
3. **Clear UX copy when refusal is upstream**:
   - Separate “Eliza error” vs “Provider policy refusal” to reduce misattribution.

---

## 4) Communication Gaps (expectations vs reality)

1. **Exchange listings vs transparency**
   - Users expect roadmap-style answers (“timeline for Coinbase listing”); reality is NDA constraints. This creates repeated questions.
   - Improvement: pin a short “Exchange listings FAQ” explaining NDA limits and what signals *can* be shared (e.g., “no comment” policy, compliance basics).

2. **“Robust and mature” claim lacks proof points for evaluators**
   - The Linux vs Shopify analogy is helpful, but evaluators want specifics: architecture diagrams, plugin lifecycle, deployment options, and what “control/extensibility” concretely means.
   - Improvement: publish a “Robustness” checklist: self-hosting, secrets vault, plugin system, cross-platform runtime, testing story.

3. **Onboarding gaps revealed by recurring first-run failures**
   - Silent missing tables / missing preload files create “it starts but behaves nonsensically” experiences.
   - Improvement: shift failures left with preflight checks and loud errors.

4. **Long-lived agent ops is under-documented**
   - The memory-rot report shows users are beyond toy demos; they need operational discipline docs (retention, reconciliation, audits).

---

## 5) Community Engagement Insights

### Power users / high-leverage contributors and their needs
- **sentient_dawn**: production research on long-lived memory failures; needs a path to upstream the approach (design doc, reference implementation, benchmarks).
- **shawmakesmagic (Shaw)**: hands-on integrations (robotics), platform direction; needs structured intake for advanced use cases so they become repeatable docs/examples.
- **odilitime**: community ops and expectation management; needs better canonical docs to reduce repeated explanations.
- **Sw4pIO (GitHub reporter)**: high-signal bug reports with reproduction steps; needs rapid triage and a “known issues” page to confirm coverage.

### Newcomer friction questions
- “What is ElizaOS vs Orbofi?”
- “Why is it more robust?”
- “How do I self-host across web/mobile/desktop without auth/CORS pain?”
These map directly to missing “first 30 minutes” guidance and decision docs.

### Converting passive users into contributors
- Create “good first issues” around:
  - Preflight doctor command checks
  - Docs: self-hosting profiles, provider policy matrix
  - Example projects: robotics adapter template
- Offer a lightweight “Contributor onboarding hour” after AMAs (AMA had ~20 listeners; good funnel moment).

---

## 6) Feedback Collection Improvements

### Effectiveness of current channels
- **Discord** is strong for ideation and quick Q&A, but feedback is **unstructured** and repeats (positioning, exchange questions).
- **GitHub issues** capture high-quality repro steps (e.g., #7210, #7222) but may be underused by non-dev users experiencing UX problems.

### Improvements for more structured, actionable feedback
1. **Weekly “Top Friction” form** (5 questions, auto-tags into GitHub):
   - “What were you trying to do?” “Where did you get stuck?” “Logs/screenshots?” “Platform (web/mobile/desktop)?” “Provider?”
2. **Add a dedicated “Self-hosting + Auth” issue template**:
   - Required fields: origin, allowed origins env, token type, `/api/auth/status` response, platform (Capacitor/Electrobun/browser).
3. **Long-lived agent ops survey**:
   - Capture retention strategy, reconciliation frequency, memory store type, drift symptoms—target users like *sentient_dawn* and operators running months-long agents.

### Underrepresented segments
- **Non-Discord self-hosters** (likely experiencing CORS/auth issues but not reporting).
- **Mobile-first users** (Capacitor path is new; likely silent failures without clear reporting loops).
- **Enterprise/security-conscious teams** (asking about vault is a hint; more of these users may exist but aren’t giving feedback yet).

---

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

1. **Ship an “eliza doctor” preflight + fail-loud startup checks** for: SQL schema completeness, missing preload artifacts (Claude stealth), and basic provider credential resolution.  
2. **Fix invalid-token UX loop** in self-hosted flows: if server says unauthenticated, show pairing/re-auth immediately (no retry-to-timeout).  
3. **Publish two canonical docs**:
   - “ElizaOS vs Orbofi (and what ‘app store layer’ means)”
   - “Self-hosting profiles: browser/mobile/desktop + auth/CORS troubleshooting”  
4. **Upstream a first-class “Memory Maintenance” proposal** (design doc + minimal implementation) based on *sentient_dawn*’s reconciliation/freshness/diff/re-embed approach.  
5. **Create a structured feedback intake loop after community events** (AMA follow-up form + curated “top 5 pain points” thread) to convert listeners into actionable issues/PRs.