## User Feedback Analysis — 2026-02-19 (based on 2026-02-16 to 2026-02-18 signals)

### Data Notes (for quantification)
We extracted **11 distinct feedback signals** (user questions, complaints, and GitHub issues/requests) from Discord and GitHub items included in the provided dataset.

---

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

### 1. Onboarding / Setup Friction (Spartan + plugins) — **Technical Functionality + Documentation**
**Frequency:** 2/11 signals (~18%) but **high severity** (blocks adoption).  
**Examples:**
- Spartan install hanging on `bun install` due to missing plugins requiring manual cloning (`@elizaos/plugin-evm`, `plugin-farcaster`, `plugin-jupiter`, `plugin-knowledge`, `plugin-mysql`, `plugin-solana`). Docker files exist but “currently non-functional.” (Einav Livne; Odilitime)
- Confusion about plugin compatibility requirements like “must have a `next` branch.” (DigitalDiva; Odilitime)

**What’s affecting most users:** first-run reliability, unclear prerequisites, and non-working “escape hatches” (Docker) that users expect to be the easiest path.

---

### 2. Support & Resolution Pathways Are Unclear (migration + “who do I ask?”) — **Community + Documentation**
**Frequency:** 3/11 (~27%); **severity high** because it involves potential financial loss and reputational risk.  
**Examples:**
- “Is there any way to help me with coin migration? I don’t want to lose my coins.” went unresolved; user was redirected away from DMs but not to a concrete support workflow. (shepa777; Kenk)
- Multiple users missed ai16z migration deadline; official stance is “nothing can be done after 90 days,” plus scam warnings. (Andi CEGY, Mark1980; Kenk, Omid Sa)
- “Which person should I approach for an AMA collab proposal?” unanswered; no clear routing for non-plugin collaborations. (YoungOldman)

**What’s affecting most users:** absence of a single canonical “Support / Requests” entrypoint (ticketing, form, or triage board) and lack of standardized responses/pinned guidance.

---

### 3. Packaging & Distribution Confusion (npx installs wrong tool) — **Integration + Technical Functionality**
**Frequency:** 1/11 (~9%); **severity high** (trust-breaking, security-adjacent).  
**Examples:**
- `npx milady` installs an unrelated Alibaba tool; users told to use GitHub release binaries because it’s pre-release. Issue #324 opened. (davidhq; Odilitime)

**What’s affecting most users:** expectation that `npx <project>` is authoritative and safe; collisions/squatting risks in npm naming.

---

### 4. Provider / Compatibility Limitations (OpenAI-compatible endpoints) — **Integration**
**Frequency:** 1/11 (~9%); **severity medium-high** (blocks many deployments).  
**Examples:**
- Feature request: configure a custom OpenAI endpoint URL to use OpenAI-compatible third-party services (e.g., SiliconFlow). (GitHub #6490)

**What’s affecting most users:** real-world usage increasingly relies on OpenAI-compatible gateways; lack of endpoint override prevents adoption.

---

### 5. Message Handling Bug Causing Duplicate LLM Calls — **Performance + UX/UI**
**Frequency:** 1/11 (~9%); **severity high** (2× cost + broken UX).  
**Examples:**
- URLs in messages trigger duplicate processing (as text + as attachment/preview) leading to duplicated output and doubled token usage. (GitHub #6486)

**What’s affecting most users:** cost surprises, confusing chat output, and lack of guardrails against double-processing.

---

### 6. Plugin Runtime Reliability Issues on Common Environments — **Technical Functionality**
**Frequency:** 1/11 (~9%); **severity medium** (environment-specific but blocks local LLM workflows).  
**Examples:**
- Ollama plugin embedding error on Ubuntu 24.04 even though Ollama works. (plugin-ollama issue referenced in daily raw data)

**What’s affecting most users:** Linux compatibility and “it works on my machine” gaps for popular local setups.

---

### 7. Governance/Policy Uncertainty: Autonomous AI agents in Discord — **Community**
**Frequency:** 1/11 (~9%); **severity medium** (moderation risk, trust).  
**Examples:**
- Dawn’s autonomous participation prompted questions about whether AI agents are allowed; need clarified server rules. (jin, Kenk, Odilitime; Dawn)

**What’s affecting most users:** unclear expectations for disclosure, moderation boundaries, and acceptable automation.

---

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

### Observed usage (from feedback)
1. **Agents for on-chain/security workflows (Solana, rugpull detection, identity, trust graphs)**  
   - Vlt9’s rugpull detection catching DARKTRUMP and NVIDIA ~2 hours early; offering test keys.  
   - MoltBridge trust layer and identity discussions (Ed25519, ERC-8004, trust graphs).  
   **Implication:** elizaOS is being used as **agent infrastructure for high-stakes financial automation**, not just chat agents.

2. **Plugin ecosystem as the primary extension mechanism (even for business development)**
   - Community guidance: “If it’s a service, build a plugin.” (Kenk)  
   **Implication:** users treat plugins as the “official integration contract,” but also need non-plugin collaboration paths (AMAs, partnerships).

3. **Content automation & media generation as a parallel product surface**
   - elizaos.news: automated video generation, mobile improvements, upcoming “1-1 interview → generated show.” (jin)  
   **Implication:** demand for **MCP-backed documentation/content pipelines** (HackMD MCP suggestion) and media-focused agent features.

### Emerging / unexpected use cases
- **Decentralized agent identity + trust scoring** as a first-class requirement (SAID Protocol integration PR; MoltBridge). This suggests a “trust & identity” vertical is forming inside the ecosystem.

### Feature requests aligning with real usage
- **Custom OpenAI endpoint URL** (GitHub #6490) aligns with production users using OpenAI-compatible providers.
- **Reduced token waste / duplicate call prevention** (GitHub #6486) aligns with cost-sensitive and high-volume usage (trading/security bots, workflow agents).

---

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

### A) Spartan setup + plugin dependency friction
**High impact / medium difficulty**
1. **Create a single “Spartan Quickstart” that is executable and tested in CI**
   - Include: required vs optional plugins list, expected directory structure, and exact commands.
   - Add a CI job that runs `bun install && bun test` for the Spartan template on each release.
   - Similar approach: many frameworks maintain “template smoke tests” (e.g., Next.js examples tested in CI).

2. **Add `elizaos doctor` + `elizaos plugin add <name>`**
   - `doctor`: checks Bun version, required plugins present, correct branches, and prints fixes.
   - `plugin add`: clones/installs missing plugins with correct branch (`main/next`) and pins versions.
   - Similar approach: Flutter’s `flutter doctor`, Homebrew diagnostics, and toolchain installers.

3. **Either fix Docker or remove it until it works**
   - If Docker remains: publish a known-good `docker-compose.yml` with cached layers and healthchecks.
   - If not: mark clearly as “experimental” with a big warning to avoid misleading users.

---

### B) Support pathways (migration issues + collab routing)
**High impact / low-to-medium difficulty**
1. **Introduce a single “Support & Requests” hub**
   - Options: GitHub Discussions categories + Discord `/support` bot command that links to the right form.
   - Include a “Migration help / scams warning” flow with canned steps and official-only links.

2. **Add a lightweight ticket intake for non-dev needs**
   - Use GitHub Issue Forms (or a hosted form) for: migration, partnerships, AMAs, grants.
   - Auto-triage labels and owners (e.g., “BD”, “Community”, “Token/Migration”).

3. **Pin canonical answers + time-boxed policies**
   - Migration: pinned post with deadlines, immutable policy, and a “what we can/can’t do” checklist.
   - Similar approach: Uniswap/Aave communities pin migration/airdrop scam warnings and “no exceptions” policies to reduce repeat questions.

---

### C) Packaging/distribution: `npx milady` installs wrong package
**High impact / medium difficulty**
1. **Secure the npm package namespace**
   - Publish `milady` (if possible) or move to a scoped package (e.g., `@elizaos/milady`) and update docs to discourage unscoped installs.
   - Add `npm publish --access public` prerelease tags (`next`, `beta`) to avoid ambiguity.

2. **Add install-time verification**
   - Provide a signed checksum for binaries; document verification steps.
   - Similar approach: many CLIs provide checksums/signatures (Rustup, Hashicorp tools).

3. **Improve error messaging in docs and README**
   - Put a prominent warning: “Do not use `npx milady` yet; use GitHub releases” until resolved (Issue #324).

---

### D) OpenAI provider: custom endpoint URL
**High impact / low difficulty**
1. **Add `OPENAI_BASE_URL` (or provider config field)**
   - Pass through to client initialization; default to official endpoint.
   - Ensure it supports common OpenAI-compatible variants.

2. **Document compatibility matrix**
   - Example configs for SiliconFlow, local gateways, LiteLLM, OpenRouter-style endpoints.
   - Similar approach: LiteLLM standardizes “base_url” overrides across providers.

3. **Add a connection test command**
   - `elizaos providers test openai` to validate endpoint, auth, and model listing.

---

### E) Duplicate LLM calls when URLs present
**High impact / medium difficulty**
1. **Deduplicate URL preview vs text pipeline**
   - Decide one canonical representation before LLM call: either text-only or attachment-only.
   - Add an integration test for “message containing URL” to ensure single completion (Issue #6486).

2. **Add cost guardrails**
   - Optional: detect repeated identical prompts in short windows and warn/abort.
   - This complements existing interest in cost tracking (e.g., scenario cost evaluator work referenced in monthly data).

3. **Instrument and expose “LLM calls per user message”**
   - Helps detect regressions and gives users transparency into token/cost behavior.

---

## 4) Communication Gaps (expectations vs reality)

1. **Expectation:** Docker-based setup works.  
   **Reality:** “Docker files exist, but currently non-functional.”  
   **Fix:** mark Docker path clearly as experimental or restore it to working.

2. **Expectation:** There is a “ticket system” or formal routing for proposals/support.  
   **Reality:** “There is no ticket system for this” and users remain unsure who to contact (AMA proposal).  
   **Fix:** publish a routing map (Support / Collabs / Plugins / BD) with owners.

3. **Expectation:** `npx milady` should install the project.  
   **Reality:** installs an unrelated tool; workaround is GitHub binaries.  
   **Fix:** packaging corrections + prominent warnings until resolved.

4. **Recurring questions indicating doc gaps**
   - “Which plugins are required?” (Spartan)
   - “Does install order matter?” (answered: no, but question suggests fragility perception)
   - “Is there a safe way to migrate coins / where is support?” (unresolved, repeats across migration topics)

---

## 5) Community Engagement Insights

### Power users / advanced contributors and their needs
- **Vlt9**: running real-time security detection + offering test keys; needs a structured beta program and integration hooks.  
- **Dawn (SageMind AI)**: building identity/trust layer; needs clear governance for agent participation and integration specs.  
- **jin**: shipping elizaos.news; benefits from shared tooling (HackMD MCP) and content pipelines.  
- **Stan**: pushing HackMD MCP adoption; needs team alignment + chosen documentation workflow.  
- **Odilitime / Kenk**: acting as human routers for support; need better tooling to reduce repeated manual triage.

### Common newcomer questions indicating onboarding friction
- Setup failures (Spartan, missing plugins, Docker).
- “Who do I contact?” for collabs and support.
- Migration anxiety (risk of loss/scams).

### Converting passive users into contributors
1. **Create “Founding Agents” and “Plugin Beta Testers” cohorts**
   - MoltBridge asks for 50 founding agents; formalize this into an elizaOS program with badges/roles.
2. **Publish a curated “good first issues” list tied to real pain**
   - Examples: URL double-processing test, Ollama Ubuntu repro, Spartan installer/doctor.
3. **Add contributor pathways for non-code roles**
   - Support triage rotation, documentation fixes, reproducible bug report templates.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord:** fast discovery of problems, but unresolved questions get lost (e.g., AMA contact, migration help, MVP collab interest, test key follow-up).
- **GitHub Issues:** strong for actionable engineering items (URL duplicate calls, OpenAI endpoint), but not used consistently for support/process questions.

### Improvements for more structured, actionable feedback
1. **Add Discord-to-GitHub escalation**
   - A simple bot command: `/escalate` that turns a message thread into a GitHub issue/discussion with context.
2. **Adopt Issue Forms for key flows**
   - Setup/Install, Provider/Integration, Migration/Token, Partnerships/AMA.
3. **Weekly “Top unanswered questions” post**
   - Automatically aggregate unanswered Discord questions (we saw at least 4 unanswered items across Feb 18 alone).

### Underrepresented segments
- **Enterprise evaluators**: daily raw data mentions a tracking issue for enterprise sign-up inquiries (e.g., Microsoft, Google X), but there’s no visible feedback loop about enterprise requirements (SSO, audit logs, SLAs).  
- **Non-Web3 builders**: most visible usage is Web3/security; feedback from general automation/chat/productivity users is comparatively missing.

---

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

1. **Ship a tested Spartan onboarding path (docs + CI smoke test + “required plugins” list)**  
2. **Create a single Support/Requests hub with clear routing (migration, AMA/collabs, integrations) and pinned canonical answers**  
3. **Fix or clearly deprecate broken Docker setup to eliminate misleading onboarding paths**  
4. **Implement `OPENAI_BASE_URL` (custom endpoint) + document OpenAI-compatible providers**  
5. **Fix URL double-processing to prevent duplicate LLM calls (add regression test + basic instrumentation for “calls per message”)**