## User Feedback Analysis — 2026-02-25 (based on data through 2026-02-24)

### 1) Pain Point Categorization (top recurring issues)

> Dataset note: signals compiled from ~14 distinct feedback threads across Discord + recent GitHub issues referenced in the provided data.

#### A. **Technical Functionality**
1) **Duplicate processing when messages include URLs (webapp)**  
- Evidence: GitHub issue **#6486** reports URL messages triggering **two LLM calls** (text + attachment preview), duplicating output and cost.  
- Frequency/severity: **High severity**, moderate frequency (a common chat behavior; high cost impact).

2) **Multimodal handling regressions (image content stripped in cloud chat)**  
- Evidence: GitHub issue **#6494** (“Image content stripped from LLM requests in cloud chat”) was closed, indicating real user impact and likely more latent cases.  
- Severity: **High** for users expecting vision workflows.

3) **Version migration edge cases / removed auto-migrations**  
- Evidence: Discord discussion around PR **#6521** removing 1.4.x → 1.6.x auto migration; suggestion to hard-error with instructions.  
- Severity: **Medium–high** (upgrade blockers, risk of data issues).

#### B. **Performance**
4) **Prompt/context bloat leading to token-limit blowups and wasted spend**  
- Evidence: Odilitime reports regularly hitting **~200k token limits** due to “numerous plugins,” with **bootstrap providers + evaluations** as major contributors; GitHub issue **#6486** doubles calls for URL messages.  
- Frequency/severity: **High severity**, appears in multiple forms (~**21%** of threads touch cost/tokens/perf directly).

#### C. **Integration**
5) **Need “OpenAI-compatible” custom endpoint support**  
- Evidence: GitHub feature request **#6490** asks for configurable OpenAI endpoint URL (e.g., SiliconFlow), blocking adoption for users not on OpenAI’s base URL.  
- Severity: **Medium**, but high leverage for ecosystem compatibility.

6) **Unclear relationships between ecosystem components (Spartan vs Milady wallet; Babylon comparisons; token upgrade target)**  
- Evidence: Discord confusion about whether infrastructure is shared; whether new work is “similar to Babylon”; and **which token** receives an “upgrade” (milady.ai vs elizaOS).  
- Severity: **Medium**, drives mistrust and repeated questions.

#### D. **UX/UI + Community (operational UX)**
7) **Discord role/channel access management friction**  
- Evidence: Odilitime struggled to assign “core dev” + labs access; manual channel addition needed; user confusion (“I can see xfn but not milady”).  
- Severity: **Medium**, but impacts contributor onboarding and perceived professionalism.

---

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

#### Observed “actual” usage patterns
- **Agentic trading + Web3 automation is a primary practical use case**, not a side niche:  
  - Discord: **fomolt** introduced as an “agentic trading platform” purpose-built for testing Eliza agents (CLI trading on Base, paymaster, API keys).  
  - Discord: revenue-focus pivot lists multiple trading-related products (Babylon, Hyperscape duel betting, OTC agent).
  - GitHub/plugin ecosystem: multiple exchange/trading plugin submissions and references (e.g., SolCex plugin).

- **Plugin-heavy deployments are common**, leading to token/context pressure:  
  - Odilitime’s 200k token-limit issue highlights users assembling many plugins/providers/evaluators in one agent.

- **Non-technical end-user agents are being built** (emerging “business utility” use cases):  
  - Discord: DarmaStef showcases reservation/travel/database analysis agents for non-technical users.

- **Multi-runtime / multi-language experimentation is accelerating (TS/Rust/Python)**:  
  - GitHub PRs describe v2 direction across Rust/Python/TypeScript, plus examples and planning-mode toggles.

#### Feature requests that align with real usage
- **Cost controls & token efficiency** (e.g., evaluators, action filtering, context pruning) align directly with plugin-heavy deployments and trading agents.
- **Custom OpenAI-compatible endpoints** align with devs using alternative inference providers to manage cost/latency.
- **Stable multimodal support** aligns with “agent assistants” and richer UI expectations in cloud/webapp.

---

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

#### Pain Point 1: Duplicate LLM calls for URL messages (GitHub #6486) — *Category: Technical Functionality / Performance*
**Proposed solutions (prioritized):**
1) **Deduplicate message “content sources” before dispatch** (High impact / Low–Med effort)  
   - Ensure a URL present in text doesn’t also get injected as an “attachment preview” payload in the same turn.  
2) **Add an idempotency key per user message to prevent double streaming** (High impact / Med effort)  
   - E.g., `message_id` ensures only one response is committed to SSE stream.  
3) **Regression test in webapp message pipeline** (Med impact / Low effort)  
   - Snapshot expected SSE events: exactly one assistant message before `done`.

**Comparable approaches:**  
- Chat UIs in projects like **OpenAI’s reference apps** and many **Next.js SSE streaming** examples use per-message IDs and commit-once semantics to avoid double renders.

#### Pain Point 2: Token/context blowups from plugin-heavy agents — *Category: Performance*
**Proposed solutions (prioritized):**
1) **Default-on context budgeting + truncation strategy** (High impact / Med effort)  
   - Hard caps per provider: `recentMessages`, `reflections`, `evaluations`; summarize older items automatically.  
2) **Expose a “Context Breakdown” debug panel/log output** (High impact / Low–Med effort)  
   - Show token contribution by provider/evaluator (e.g., “recentMessages: 42%, reflections: 31%…”).  
3) **Make action/provider filtering a first-class, documented pattern** (Med–High impact / Med effort)  
   - The vector/BM25 filtering idea (seen in PRs) should be integrated with clear defaults for large plugin sets.

**Comparable approaches:**  
- **LangChain** and **LlamaIndex** popularized “retrieval + compression/summarization” patterns and “token accounting per step” to manage context windows.

#### Pain Point 3: Migration confusion & removed auto-migration — *Category: Documentation / Technical Functionality*
**Proposed solutions (prioritized):**
1) **Add explicit upgrade guards with actionable error messages** (High impact / Low effort)  
   - If DB schema version < required, error: “Upgrade to 1.6.x first; run `...` then retry v2.”  
2) **Publish a single canonical migration matrix** (Med–High impact / Low–Med effort)  
   - Table: from version → to version steps; include “unsupported direct jumps.”  
3) **Provide a “dry-run migration check” command** (Med impact / Med effort)  
   - Validates DB state and prints next steps without modifying data.

**Comparable approaches:**  
- **Django** and **Rails** ecosystems normalize explicit migration commands and fail-fast version guards with clear CLI output.

#### Pain Point 4: OpenAI provider lacks custom endpoint URL (GitHub #6490) — *Category: Integration*
**Proposed solutions (prioritized):**
1) **Add `OPENAI_BASE_URL` / `openaiBaseUrl` config to OpenAI provider** (High impact / Low effort)  
   - Keep default as official endpoint; allow override for OpenAI-compatible services.  
2) **Compatibility checklist + example configs (SiliconFlow, etc.)** (Med impact / Low effort)  
3) **Add a simple provider conformance test** (Med impact / Med effort)  
   - Ensures streaming/tool-calls behave consistently under alternate base URLs.

**Comparable approaches:**  
- Many SDKs (e.g., **OpenAI-compatible clients**, **LiteLLM**) expose a base URL override to support multiple backends.

#### Pain Point 5: Discord access/roles friction for contributors — *Category: Community / UX/UI (operational)*
**Proposed solutions (prioritized):**
1) **Automate role assignment via a “Contributor Onboarding” bot flow** (High impact / Med effort)  
   - Request → review → auto-grant channels; reduce manual permission edits.  
2) **Create a “Roles & Channels Map” pinned message** (Med impact / Low effort)  
   - What “core dev”, “labs”, “xfn”, “milady” mean; how to request access.  
3) **Add an audit log checklist for admins** (Med impact / Low effort)  
   - Prevents silent failures when assigning roles with permission constraints.

**Comparable approaches:**  
- Large OSS Discords (e.g., Kubernetes/community servers) use structured onboarding + clearly documented role-gated areas.

#### Pain Point 6: Ecosystem/product messaging ambiguity (tokens, upgrades, project status) — *Category: Communication / Community*
**Proposed solutions (prioritized):**
1) **Single “What’s Shipping / What’s Live” status page updated weekly** (High impact / Low–Med effort)  
   - Clarify: what is launched vs planned (e.g., milady.ai token “not launched yet”).  
2) **FAQ entry: “How ElizaOS relates to Milady / Babylon / Spartan”** (Med impact / Low effort)  
3) **Explicit policy on price talk + redirect patterns** (Med impact / Low effort)  
   - Keep morale while preventing discussion channels from being dominated by price anxiety.

---

### 4) Communication Gaps (expectations vs reality)

1) **“Project is dead” perception driven by token price stagnation**  
- Evidence: Discord users equate price action with dev activity (“stalled,” “dead”), requiring moderator reassurance.  
- Gap: community lacks a visible, trusted “development heartbeat” outside chat.

2) **Token ecosystem confusion (upgrade target + token availability)**  
- Evidence: unresolved confusion about whether the “token holder upgrade” applies to **elizaOS** or **$milady.ai**; user couldn’t find milady.ai token (confirmed “not launched yet”).  
- Gap: unclear canonical source of truth for token status/announcements.

3) **Upgrade/migration path isn’t obvious to users**  
- Evidence: discussion about removing auto-migration and possibly adding error handling indicates users will attempt unsupported jumps.  
- Gap: missing “supported upgrade paths” doc that’s easy to find from release notes/CLI errors.

4) **Plugin guidance drift (which image generation plugin to use)**  
- Evidence: Discord recommends **plugin-bootstrap** over older plugin-image-generation.  
- Gap: docs likely don’t clearly mark deprecated/legacy plugins vs recommended defaults.

---

### 5) Community Engagement Insights

#### Power users / high-signal contributors and their needs
- **Odilitime**: repeatedly troubleshooting permissions, answering viability questions, and working on performance/token issues → needs better tooling for **context/token diagnostics** and less time spent on admin support.  
- **Stan ⚡**: driving DB refactor/migration strategy → needs crisp community-facing migration comms to reduce repeated Q&A.  
- **Fido (fido.eth)**: building **fomolt** and actively requesting feedback → needs a structured way to collect developer feedback (template + test checklist).  
- **Ogie**: publishing SolCex plugin and registry PRs → needs clearer plugin submission “definition of done” and discoverability.

#### Newcomer questions indicating onboarding friction
- “Is the project dead / will price recover?” (status visibility problem)  
- “Where do I buy token / why can’t I find it?” (token lifecycle/status problem)  
- “Which plugin should I use?” (recommended path problem)  
- “Why can’t I see X channel?” (permissions onboarding problem)  
- “Is this similar to Babylon?” (product positioning problem)

#### Converting passive users into contributors
- Create **“good first issue” lanes** tied to real pain: URL duplication fix, base URL config, migration guardrails, token breakdown tooling.  
- Run **monthly “Plugin Clinic” office hours**: maintainers + plugin authors triage integration/perf issues together.  
- Add a lightweight **“Feedback → PR” ladder**: short template that turns Discord reports into GitHub issues with reproduction steps.

---

### 6) Feedback Collection Improvements

#### Current channel effectiveness
- **Discord**: great for rapid reassurance/admin help, but feedback is **unstructured** and easily derails into price/status chatter.  
- **GitHub issues**: higher quality for actionable bugs/feature requests (e.g., #6486, #6490), but not all Discord-reported problems get captured.

#### Improvements for more structured, actionable feedback
1) **Create a “Bug Intake” Discord form that auto-files GitHub issues** (or posts in a triage channel with required fields)  
   - Required: version, runtime (cloud/webapp/cli), repro steps, logs.  
2) **Add a weekly “Top 3 regressions” pinned thread**  
   - Keeps community aligned on what’s being fixed and reduces repeated questions.  
3) **Opt-in telemetry for token/context metrics (developer mode)**  
   - Aggregate anonymous “top token contributors” to guide performance work.

#### Underrepresented segments whose feedback is missing
- **Non-Web3 / enterprise automation users** (e.g., Gmail/WhatsApp/N8N users) are referenced in project summaries but not strongly present in Discord feedback.  
- **Python/Rust runtime users**: lots of code movement, but little direct UX feedback on those runtimes.  
- **Cloud paying customers**: billing/onboarding is mentioned strategically, but user feedback on onboarding/billing friction is absent in this dataset.

---

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

1) **Fix URL-triggered duplicate LLM calls (GitHub #6486) + add regression test**  
2) **Ship “Context/Token Breakdown” tooling + default context budgets to prevent 200k token blowups**  
3) **Implement OpenAI provider `baseUrl` override (GitHub #6490) + publish 2–3 OpenAI-compatible examples**  
4) **Add fail-fast migration guards + publish a one-page migration matrix for v1.x → v2.0.0**  
5) **Publish a canonical “What’s Live / Token Status / Ecosystem Map (ElizaOS vs Milady vs Babylon vs Spartan)” page and link it prominently in Discord**