## User Feedback Analysis — 2026-03-22 (based on 2026-03-19 to 2026-03-21 sources)

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

> Sample size note: Feedback is dominated by Discord (#discussion, #coders) across ~3 days, with a heavy skew toward token/investor concerns. Percentages below are based on the recurring themes within the collected questions/issues for these dates (not the entire community).

#### A. **Community (Communication, trust, accountability)**
**Frequency/Severity:** Very high / Very high  
**What users are experiencing**
- “Team isn’t communicating” claims persist despite weekly video updates (“cronjob”) and daily updates channel; users say updates **don’t answer the questions they care about** (token plans, utility, timelines).
- Trust erosion from perceived defensiveness (“paid shills” framing) and unresolved “broken promises” narratives.
- Leadership visibility gap: repeated mentions that Shaw is active on Twitter but absent in Discord for investor/product clarity.

**Evidence/examples**
- Repeated conflict in #discussion: community asks about token recovery, minting/selling plans, and utility; multiple questions remain unanswered.
- Rainman suggests auto-linking the UPDATES channel when complaints arise—signaling recurring, unresolved perception issues.

#### B. **Technical Functionality (ElizaCloud / deployment reliability)**
**Frequency/Severity:** High / High  
**What users are experiencing**
- Eliza Cloud deployments failing or becoming “stuck,” forcing users to switch from GUI to CLI.
- Critical runtime error: `Cannot find module '@elizaos/plugin-discord'` after configuring Discord plugin via GUI.
- No clear “reload container” / recovery path in GUI once stuck.
- Disk image uploads reported as sent but not arriving server-side.

**Evidence/examples**
- jin reports GUI deploy failures, slow Docker build/upload, module missing error, and lack of GUI reload mechanism.
- 2026-03-20: disk image upload not appearing on server; confirmed by Odilitime.

#### C. **Documentation (Onboarding clarity; ecosystem architecture; migration info)**
**Frequency/Severity:** High / Medium-High  
**What users are experiencing**
- Confusion about ecosystem components: “Will Milady replace ElizaOS?” “Is Milady competing with OpenClaw?”  
- Migration information hard to find for newcomers; confusion around old vs new token (investor onboarding failure mode).
- Users don’t know where to find “what’s happening” (UPDATES channel exists, but discoverability/expectation-setting is weak).

**Evidence/examples**
- HatcherLabs required clarification that Milady is built on ElizaOS; OpenClaw can exist within Milady.
- Matthi(b)123 request: make migration info easier to find for new investors.

#### D. **UX/UI (ElizaCloud GUI gaps; operational affordances)**
**Frequency/Severity:** Medium / High (when hit)  
**What users are experiencing**
- GUI deployment path appears unreliable compared to CLI; users fall back to CLI to get anything done.
- Lack of a visible “retry/rebuild/reload” control in GUI creates dead-ends after configuration changes (e.g., Discord plugin).

**Evidence/examples**
- jin: “GUI deployment attempts failed,” “container stuck,” “Is there a way to reload the container through GUI?”

#### E. **Performance (Build/upload latency)**
**Frequency/Severity:** Medium / Medium  
**What users are experiencing**
- Docker image build and upload takes “a while,” causing uncertainty whether the system is working or stalled.

**Evidence/examples**
- Odilitime explains long build/upload times are normal; user still experiences it as friction.

#### F. **Integration (Discord plugin packaging; plugin registry pipeline)**
**Frequency/Severity:** Medium / High  
**What users are experiencing**
- Discord plugin import error suggests packaging/registry/deployment mismatch (GUI config references plugin that isn’t present in runtime image).
- Community is building plugins (e.g., Moltraffle) and needs a smooth path to registry inclusion (PR guidance exists but could be more turnkey).

**Evidence/examples**
- Missing `@elizaos/plugin-discord` module at runtime.
- Moltraffle plugin release + recommendation to PR to `elizaOS/registry`.

#### G. **Community / Product Expectation Misalignment (Token utility & tokenomics)**
**Frequency/Severity:** Very high / Very high  
**What users are experiencing**
- Repeated direct questions: “What is one use case of this token?” “Why should anyone buy this token?” (unanswered in thread).
- Migration optics: “40% community tokens” seen as a cash grab; lack of clear, auditable post-migration plan.
- Users explicitly compare to “Virtuals protocol” as a benchmark for shipping token utility.

**Evidence/examples**
- Multiple unanswered FAQs on token utility and mint/sell timeline.
- Babylon integration described as leading to buybacks/airdrop, but users still perceive utility as not implemented end-to-end.

**Quantified observation (within this dataset)**
- **~50%+ of highlighted questions/complaints** across 3/19–3/21 center on token utility/performance and trust/communication (dominant theme in #discussion summaries and FAQs).

---

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

#### How users are actually using ElizaOS (from feedback)
- **Cloud-first agent deployment**: Users attempt to deploy agents through Eliza Cloud GUI, then fall back to CLI when GUI fails (jin).
- **Plugin ecosystem building**: Community ships permissionless on-chain plugins (Moltraffle raffle plugin on Base) and seeks registry inclusion.
- **Web3/financial agent use cases**: Users ask “Anyone builds trading agents here?” and get confirmation “Yes.”
- **Ecosystem stacking**: Users are evaluating Milady vs ElizaOS vs OpenClaw, implying they’re composing solutions rather than picking one monolith.

#### Intended usage signals (implicit in team comms)
- ElizaOS as the **foundational agent OS**, with Milady as an app/framework layer on top; plugins as modular extensions; ElizaCloud as deployment infrastructure.

#### Emerging / unexpected use cases
- **On-chain raffle / VRF-based automation** as a community-led “agent + chain action” pattern (Moltraffle).
- **Identity protocol ideation** (agentic identity protocol) suggests demand for higher-level primitives beyond basic agent runs.

#### Feature requests that align with real usage
- **Reliable deploy + recover workflow** (GUI reload/retry, better errors) aligns with cloud-first behavior.
- **Simplified plugin-to-registry publishing path** aligns with community plugin output.
- **Clear architecture map & decision guide** aligns with “stack selection” questions (Milady vs OpenClaw vs ElizaOS).

---

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

Below, each opportunity includes prioritized solutions (Impact vs Difficulty) and examples of how similar projects handle it.

#### 1) ElizaCloud deployment failures & “stuck” states (GUI/CLI mismatch)
**Solution A (High impact / Medium difficulty): Add GUI “Recovery Controls”**
- Add **Rebuild Image**, **Restart Container**, **Roll back to last successful config**, and **View build logs** buttons in the GUI.
- Provide a “safe mode” deploy: disable optional plugins until base agent boots.

**Solution B (High impact / Medium difficulty): Preflight validation for configured plugins**
- When enabling Discord plugin in GUI, run a preflight that checks the runtime image includes `@elizaos/plugin-discord` (or adds it).
- If missing, offer one-click fix: “Add plugin dependency and rebuild.”

**Solution C (Medium impact / Low difficulty): Improve error messaging + docs**
- Replace “Cannot find module …” with guidance: “Plugin not included in image; run `elizaos plugins add @elizaos/plugin-discord` (or equivalent) and redeploy.”

**Comparable patterns**
- **Heroku/Render/Fly.io**: explicit “restart/redeploy” controls + log-first debugging flows.
- **Docker Desktop / Kubernetes dashboards**: clear separation of build logs vs runtime logs, plus restart/recreate actions.

#### 2) Missing module `@elizaos/plugin-discord` after GUI config
**Solution A (High impact / Medium difficulty): Unify plugin dependency model across GUI + CLI**
- Ensure GUI writes to the same dependency manifest the CLI uses (or vice versa), eliminating drift.

**Solution B (High impact / Medium difficulty): Make Discord plugin a “core optional” bundle**
- Ship a standard “social bundle” image that includes Discord plugin, reducing first-run failures.

**Solution C (Medium impact / Low difficulty): Add a deployment-time “dependency resolution” step**
- At build time, parse enabled plugins and auto-install missing packages.

**Comparable patterns**
- **VS Code extensions**: extension enablement triggers installation + reload prompts.
- **Netlify build plugins**: declared plugins are resolved and installed during build automatically.

#### 3) Documentation gaps: ecosystem architecture & migration/onboarding clarity
**Solution A (High impact / Low difficulty): Publish a one-page “What is what?” architecture explainer**
- Include: ElizaOS (base), Milady (built on ElizaOS), OpenClaw (agents can run within Milady), ElizaCloud (deployment).
- Add a decision tree: “If you want X, start with Y.”

**Solution B (Medium impact / Medium difficulty): Add a “New here?” onboarding hub pinned in Discord + docs**
- Links: UPDATES channel, weekly cronjob videos, migration FAQ, “how to deploy,” “how to publish plugins.”

**Solution C (Medium impact / Low difficulty): Migration FAQ rewrite with investor-safe clarity**
- Prominently address “old token vs new token,” supply/minting info if available, and what is *not* promised.

**Comparable patterns**
- **Kubernetes** has a strong “Concepts” section + architecture diagrams.
- **Ethereum L2s** often publish “bridge & migration” pages with explicit safety warnings and step-by-step checklists.

#### 4) Communication mismatch: “updates exist” but don’t answer key questions
**Solution A (High impact / Low difficulty): Add an “FAQ answered this week” section to updates**
- Track top unanswered questions (token utility, timelines, deploy reliability) and explicitly answer or state “no update.”

**Solution B (High impact / Medium difficulty): Single source of truth roadmap + status labels**
- Public roadmap with: Planned / In progress / Blocked / Shipped.
- Tie weekly video + daily updates to roadmap items.

**Solution C (Medium impact / Low difficulty): Office hours with structured Q&A**
- 30 minutes weekly, questions collected заранее, answers summarized in a pinned post.

**Comparable patterns**
- **Rust** and **Next.js**: “This week in…” summaries that map work to roadmap and explicitly call out what is not changing.

#### 5) Release readiness uncertainty (Milady “ready when ready”)
**Solution A (Medium impact / Low difficulty): Define “Beta” criteria checklist**
- “Playable and running” is good, but add: installer verification (GPG/SHA), minimum crash-free run, known issues list.

**Solution B (Medium impact / Medium difficulty): Staged release channels**
- Nightly / Beta / Stable with clear expectations and rollback instructions.

**Comparable patterns**
- **Chrome / Firefox channels**: clear stability expectations; known issues; staged rollouts.

---

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

#### Where expectations don’t match reality
- **Users expect token utility + concrete buy reasons now**, while team messaging emphasizes “devs are building” without tying deliverables to token value. This gap drives repeated direct questions that go unanswered.
- **Users expect leadership presence in Discord** for accountability; reality is mostly Odilitime responding, with Shaw described as active on Twitter.
- **Users expect GUI deployment to be the “happy path,”** but current reality forces CLI workarounds.

#### Recurring questions indicating onboarding/documentation gaps
- “Where are updates?” (despite UPDATES channel + weekly videos)
- “Will Milady replace ElizaOS?” “Is Milady competing with OpenClaw?”
- “How do I redeploy/reload when the container is stuck?”
- “Why is the build taking so long—is it broken?”

#### Specific improvements to align expectations
- Pin a “Start here (Read before posting)” message in #discussion linking: Updates, Roadmap, Architecture map, Deploy troubleshooting.
- Add “Known limitations” section: what ElizaCloud GUI can/can’t do today; when to use CLI.

---

### 5) Community Engagement Insights

#### Power users / key contributors surfaced in this dataset
- **jin**: hands-on deploy/debug feedback (high-value for Cloud reliability); also initiated increasing feedback frequency to weekly.
- **sb**: technical clarifications; unblocks architecture misunderstandings quickly.
- **Stan ⚡**: plugin ecosystem enablement (registry PR guidance).
- **Moltraffle**: shipping real plugins; represents the “builder” segment that can expand ecosystem utility.
- **Odilitime**: primary community ops responder; currently a single-threaded “support bottleneck.”

#### Common newcomer questions (onboarding friction)
- Relationship between ecosystem components (ElizaOS vs Milady vs OpenClaw).
- Where to track progress/releases and how to interpret “beta.”
- Basic operational troubleshooting on ElizaCloud.

#### Converting passive users into active contributors
- Create a “Good first plugin PR” template + video walkthrough: build → test → registry PR.
- Add a “Cloud Issues Triage” program: tag community members to reproduce + confirm fixes (jin-like contributors).
- Recognize builders in release notes (Moltraffle-style contributions) to reinforce productive participation vs price-only discourse.

---

### 6) Feedback Collection Improvements

#### Effectiveness of current channels
- Discord captures high-volume sentiment quickly, but **threads are dominated by token price discourse**, which drowns technical UX issues unless explicitly solicited.
- Technical issues are present but scattered (deployment failures, upload bugs, checksums) and not consistently converted into GitHub issues.

#### Suggestions for more structured, actionable feedback
- Add a weekly “Deploy & Plugins Check-in” form (3–6 questions) linked in Discord; auto-create GitHub issues for reproducible bugs.
- Introduce required fields for Cloud bug reports: CLI version (e.g., 1.7.2), plugin list, logs, steps, expected vs actual.
- Maintain a public “Top 10 Issues” dashboard: number of reports, status, workaround.

#### Underrepresented segments (missing feedback)
- **Non-crypto / non-token users** using ElizaOS for productivity automations (e.g., WhatsApp/Gmail/N8N from prior weekly summary) are not visible in this snapshot.
- **New developers** beyond Discord power users: lack of beginner pain points beyond architecture confusion suggests we need targeted onboarding surveys.

---

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

1) **Fix ElizaCloud “stuck deploy” workflow**: add GUI restart/rebuild/rollback + expose logs, and implement plugin preflight checks (highest impact on real usage).  
2) **Resolve Discord plugin packaging mismatch** (`@elizaos/plugin-discord` missing): unify GUI/CLI dependency handling; add build-time dependency resolution.  
3) **Ship a one-page Ecosystem Architecture + Decision Guide** (ElizaOS vs Milady vs OpenClaw) and pin it in Discord + docs.  
4) **Reformat updates to answer the top recurring questions explicitly** (even if the answer is “not decided yet”), and link each update to a public status/roadmap item.  
5) **Create a structured bug intake + auto-triage pipeline** (Discord → form → GitHub issue) to prevent critical infra bugs (upload failures, checksum issues) from being lost in chat noise.