## User Feedback Analysis — 2026-02-20 (based on 2026-02-17 to 2026-02-19 Discord + Feb GitHub activity)

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

**1. Token confusion + migration support gaps (Community / Documentation) — highest severity**
- **Recurring problems**
  - Confusion between **$ai16z / $ai6z vs $elizaos**; community members initially gave incorrect confirmation before correction (“different contracts… ai16z worth way less” — Odilitime).
  - Repeated requests for **official ElizaOS contract address** and where to find it.
  - Users **missing the migration deadline** asking for options (“is there anyway to still do this?” — Jüju) with no resolution.
  - **Token mintability** concerns asked publicly (“Why the token is mintable”) with no answer.
- **Frequency signal**
  - In the 2026-02-19 Discord FAQ list, **~57% (4/7)** of prominent questions were token-identity/migration/mintability/contract-address related.

**2. Spartan setup is brittle; Docker path is broken (Technical Functionality / Documentation) — high severity**
- **Recurring problems**
  - `bun install` hanging and missing plugin packages requiring manual cloning (`@elizaos/plugin-evm`, `plugin-farcaster`, `plugin-jupiter`, `plugin-knowledge`, `plugin-mysql`, `plugin-solana`).
  - “Spartan setup remains challenging and hasn’t been polished yet” (Odilitime).
  - **Docker files exist but are currently non-functional** (explicitly called out on 2026-02-17).
- **Impact**
  - Blocks onboarding for builders; pushes users into ad-hoc installs and tribal knowledge.

**3. Distribution & naming collisions (Integration / Documentation) — medium-high severity**
- **Recurring problems**
  - `npx milady` installing an unrelated Alibaba tool; project is pre-release and “not on npm yet” → users must use GitHub release binaries.
  - Implies missing guardrails in package naming, release comms, and install docs.

**4. Missing “how to collaborate / get support” pathways (Community / UX/UI) — medium severity**
- **Recurring problems**
  - No formal **ticket system** for collab proposals (Kenk: “There is no ticket system… build a plugin instead”), but this doesn’t satisfy non-plugin asks like AMAs/partnerships.
  - Migration support request (“I don’t want to lose my coins”) redirected to public channel; still unresolved (2026-02-18).
- **Impact**
  - Users with urgent/account-like problems (migration loss fear) don’t know where to go; maintainers repeat guidance manually.

**5. Capability/roadmap uncertainty (Community / Documentation) — medium severity**
- **Recurring problems**
  - Questions about **ElizaCloud status** and “promised marketing… after autofun flopped” (Thanos💨) unanswered.
  - Market-context frustration bleeds into product trust (“what’s the use of $elizaos coins now?” / “token has no use case” sentiment).
- **Impact**
  - Expectation mismatch: community expects productized cloud + marketing cadence; reality appears “in progress / not publicly tracked.”

**6. Provider & message-processing correctness issues (Technical Functionality / Integration) — medium severity**
- **From GitHub issues**
  - **Duplicate LLM calls when URL present** in webapp chat (#6486) → doubles cost + duplicated output.
  - **Need custom OpenAI endpoint URL** for OpenAI-compatible providers (#6490) (e.g., SiliconFlow).
- **Impact**
  - Direct cost increases + degraded UX; blocks users who rely on OpenAI-compatible inference vendors.

---

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

**How users are actually using elizaOS**
- **Discord-native agent experiences** as the primary “proof” demo: Babylon Discord “the hanging plaza” is repeatedly pointed to as the best live demonstration (Odilitime).
- **Workflow automation & tool integration**: active interest in “Agentic AI-to-workflow integration,” and the ecosystem is moving toward n8n-style control panels (weekly summary notes a REST API control panel in the n8n plugin).
- **Security/crypto risk monitoring agents**: Vlt9’s Solana rugpull detection tests (flagging DARKTRUMP and NVIDIA token ~2 hours early) indicates real usage in monitoring + alerting.
- **Content automation**: elizaos.news uses automated PlayCanvas video generation with subtitles + narration; planned “1–1 interview show” generation.
- **Personal assistant projects** (e.g., milady personal AI assistant) that want **plugin reuse**; compatibility depends on “next branch” availability.

**Mismatch vs intended usage**
- Users treat the project as both:
  1) a developer framework (plugins, agents, connectors), and  
  2) a consumer-facing token/community brand with expectations of migration support + marketing + cloud product.
- The “build a plugin” guidance is good for dev integrations, but **doesn’t cover** partnership/AMA/collab flows and token-migration support needs.

**Feature requests aligned with observed usage**
- Custom OpenAI endpoint configuration (#6490) aligns with “bring-your-own-inference” behavior.
- Fixing duplicate URL processing (#6486) aligns with real chat usage patterns.
- Spartan polish (docs + Docker) aligns with actual onboarding friction seen in Discord.

---

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

#### A) Token confusion + migration support gaps
1) **Single canonical “Token & Migration” page** (high impact, low-medium difficulty)
   - Include: contracts, migration timeline, “ai16z vs elizaos” explanation, mintability explanation, official links, and scam warnings.
   - Mirror in Discord via **pinned post + `/contract` bot command** returning the canonical data.
   - Similar approach: major crypto projects maintain a “token address” page + Discord bot command to reduce impersonation/scam risk.

2) **Post-migration support policy + tooling** (high impact, medium difficulty)
   - Publish explicit policy: whether late migration is possible; if not, why; if yes, via what process.
   - If feasible: a **one-time late-migration claims form** with signed-wallet proof and automated eligibility checks.
   - Similar approach: projects that used Merkle-claim migrations often provide a documented late-claim pathway or a firm “no late claims” policy with rationale.

3) **Mintability FAQ with verifiable evidence** (medium impact, low difficulty)
   - Answer “mintable” with: contract type, owner privileges (if any), renounced/multisig status, and links to explorer verification.
   - Add a short “how to verify on-chain” section.

#### B) Spartan setup brittleness + broken Docker
1) **Ship a working `docker compose up` golden path** (high impact, medium difficulty)
   - Make Docker the recommended first-run; gate merges on “compose boots clean” CI.
   - Include profiles: `core`, `core+db`, `core+recommended-plugins`.

2) **Create a “required vs optional plugins” manifest + installer** (high impact, low-medium difficulty)
   - A machine-readable manifest (JSON/YAML) listing default plugin set and versions.
   - Provide `elizaos doctor` to check missing plugins and fix order/versions.

3) **Known-issues + troubleshooting matrix** (medium impact, low difficulty)
   - Document `bun install` hangs, common missing packages, and resolution steps.
   - Similar approach: many frameworks (e.g., large monorepos) maintain “first-run failures” pages with copy/paste fixes.

#### C) Distribution & naming collisions (`npx milady` issue)
1) **Reserve/verify npm package names and publish a stub** (high impact, low difficulty)
   - Publish `milady` (or scoped package) that prints: “pre-release, install from releases” + link.
   - Prevents users installing the wrong tool.

2) **Installation UX hardening** (medium impact, low difficulty)
   - Update README and docs with a prominent “Do not use npx yet” warning until ready.
   - Add release assets with platform checksums and a one-liner installer script.

#### D) Missing support/collab pathways
1) **Introduce lightweight routing: Support vs Partnerships vs Dev Help** (high impact, low difficulty)
   - Discord: three pinned “Start here” messages with clear rules and escalation paths.
   - Add a simple web form or GitHub Discussions categories for: migration support, partnerships/AMA, plugin help.

2) **Volunteer “triage squad” + macros** (medium impact, low difficulty)
   - Empower helpful members (e.g., MDMnvest) with canned responses and a maintained knowledge base.
   - Similar approach: open-source projects use “support champions” and standardized replies to reduce maintainer load.

#### E) Provider & message-processing correctness
1) **Fix duplicate URL processing (#6486)** (high impact, medium difficulty)
   - Ensure URL preview/attachment generation doesn’t create a second LLM pass.
   - Add regression test: “message with URL triggers exactly 1 completion.”

2) **Add custom endpoint URL to OpenAI provider (#6490)** (high impact, low-medium difficulty)
   - Support `OPENAI_BASE_URL` (or provider config key) and document OpenAI-compatible vendors.
   - Similar approach: LiteLLM and other compatibility layers standardize `base_url` to support many backends.

---

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

- **Token identity reality vs community assumptions**
  - Conflicting answers occurred publicly before correction; this signals the canonical answer isn’t discoverable enough.
  - Repeated “contract address?” questions indicate information is not surfaced where users look first.

- **Migration urgency vs lack of a formal process**
  - Users fear losing funds and ask for direct support; being told “post publicly, not DMs” is good for transparency but doesn’t resolve urgency.

- **Spartan maturity**
  - Users expect Docker to work because files exist; reality: “currently non-functional.” This should be clearly labeled (or removed until supported).

- **Roadmap ambiguity (ElizaCloud/marketing)**
  - Unanswered questions about ElizaCloud and marketing follow-through create a vacuum filled by speculation and negativity.
  - Recommended: a short monthly “What we shipped / what slipped / what’s next” post—even if marketing is minimal.

Recurring questions that indicate onboarding gaps:
- “Is X token the same as Y token?”, “contract address?”, “missed migration deadline—now what?”, “how do I propose a collab?”, “how do I set up Spartan without it hanging?”

---

### 5) Community Engagement Insights

**Power users and what they need**
- **Odilitime**: repeatedly acts as technical/product clarifier (token contracts, benchmarks vs OpenClaw, setup limitations). Need: reduce repeat questions via canonical docs and bot commands.
- **Kenk**: directs builders to plugin guide; needs: clearer non-plugin collaboration pathways so answers don’t feel like dead ends.
- **jin**: shipping community-facing media/product (elizaos.news); needs: feedback loops and contributor help for storyboarding/interview feature.
- **Vlt9**: security/trust-graph experimentation; needs: integration touchpoint (someone to answer “open to technical chat?”) and identity standards alignment.
- **MDMnvest**: community support (contracts/socials); needs: official, maintained references to avoid accidental misinformation.

**Common newcomer friction**
- Where to find official contract/socials.
- How to see a “real demo” (Babylon/hanging plaza is currently tribal knowledge).
- How to start building (Spartan install path is rough).
- Where to get help for migration/support.

**Converting passive users into contributors**
- Create “Good first plugin” bounties: small connector plugins, docs fixes (Spartan setup), bot command PRs.
- Promote hackathon voting/projects as “contribute by testing” with clear test scripts and issue templates.
- Add a “Builders onboarding hour” weekly in Discord: 30 minutes setup help + 30 minutes plugin scaffolding.

---

### 6) Feedback Collection Improvements

**Current channel effectiveness**
- **Discord** is effective for rapid Q&A but leads to repeated questions and inconsistent answers (token identity confusion is the clearest example).
- **GitHub issues** capture actionable bugs/features well (#6486, #6490), but user support problems (migration) are not consistently converted into trackable issues.

**Improvements for more structured feedback**
1) Add **issue templates** for:
   - “Setup/Install problem” (collect OS, bun/node versions, logs, plugins list)
   - “Provider compatibility request” (API compatibility, base URL, auth method)
2) Add a **migration/support intake form** (even if only to provide automated answers + policy), linked from Discord.
3) Introduce **Discord → GitHub escalation**: a pinned message explaining when/how to open an issue, with a bot that can generate a prefilled GitHub issue link.

**Underrepresented segments**
- Non-crypto builders who only care about agent automation (they may avoid Discord due to token chatter).
- Enterprise/teams evaluating deployment; they need clear Docker + auth + scaling guidance surfaced prominently.
- Non-English users (no signals here; likely missing feedback due to channel language).

---

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

1) **Publish and pin a canonical “Token & Migration” hub** + add a Discord `/contract` (and `/migration`) bot command.  
2) **Make Spartan onboarding deterministic**: working Docker Compose + “required vs optional plugins” manifest + `elizaos doctor`.  
3) **Close the top UX-cost bug**: fix duplicate URL → double LLM call (#6486) with regression tests.  
4) **Unblock OpenAI-compatible providers**: implement configurable OpenAI base URL (#6490) and document supported vendors.  
5) **Add clear support/collab routing**: separate pathways for (a) dev/plugin help, (b) token/migration support, (c) partnerships/AMAs—with owners and expected response times.