## User Feedback Analysis — 2026-04-28 (based on Apr 25–27 inputs)

### Data sources covered
- Discord daily summaries: **2026-04-25**, **2026-04-26**, **2026-04-27**
- Dev/activity summary (GitHub + internal): **2026-04-27**
- Repo-wide context (Apr 2026 month rollup): **elizaos/eliza** activity snapshot (issues/PRs + notable proposals)

---

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

### 1) Community — Token-price dominated discussion drowning product support (High frequency, High severity)
**What users experienced**
- Discord discussion was “dominated” by token price complaints and loss narratives (Apr 27), plus repeated calls for market-making/VC intervention.
- In the 3-day Discord slice, token economics/price concerns appeared on **2/3 days (67%)** (Apr 26–27).

**Why it matters**
- Newcomers with actual product questions (e.g., “issues with eliza rn”) receive less timely help.
- Creates expectation that core team should address price, not product quality.

**Examples**
- Users requesting outreach to “ai16z and Pantera Capital” (Apr 27).
- Ongoing debate about token utility creating friction (Apr 26).

---

### 2) Documentation — Unclear/underspecified architecture details (HTN + planning) (Medium frequency, High severity for builders)
**What users experienced**
- Technical discussion on HTN (Hierarchical Task Networks) revealed uncertainty about what’s *actually implemented* in ElizaOS v2 vs aspirational plans.
- Users asked for conceptual grounding (HTN vs HTM comparisons; what “HTN-lite” means; upgrade path).

**Why it matters**
- Builders can’t reliably adopt planning features if they don’t know current behavior, extension points, and constraints.

**Examples**
- “Uncertainty expressed” about HTN implementation details; explicit action item to document and verify HTN behavior (Apr 25).

---

### 3) Integration — Broken/unclear links and access paths (Medium frequency, Medium severity)
**What users experienced**
- A specific GitHub-linked resource was non-functional: **Milady Play Store link** broken (Apr 26).
- Users asked how to access Hyperscape Discord / long-term plan (Apr 27).

**Why it matters**
- Broken links are a “first-minute” failure that reduces trust and increases support load.
- Access friction blocks adoption of satellite projects/apps.

**Examples**
- “Milady Play Store link … not functional” (Apr 26).
- Hyperscape Discord invite had to be manually provided by a moderator (Apr 27).

---

### 4) Technical Functionality — Intermittent/undefined runtime “issues with Eliza” without diagnostic capture (Low frequency in this slice, High severity when it occurs)
**What users experienced**
- A user reported “issues with eliza rn” that “resolved itself,” with no further details captured (Apr 27).

**Why it matters**
- Self-resolving issues are still costly: they indicate flakiness, race conditions, or transient infra failures.
- Without structured capture (version, logs, environment), the team can’t reproduce.

**Examples**
- luminousda issue report resolved without intervention (Apr 27).

---

### 5) Community/Security — Scam attempts in support contexts (Medium frequency signal, High severity)
**What users experienced**
- A scam link targeted a user asking for help; community warned them; moderator banned the scammer (Apr 27).

**Why it matters**
- Users seeking help are the most vulnerable; a single incident can permanently damage trust.

**Examples**
- “Suspicious link targeting another member who had asked for help” → ban (Apr 27).

---

### 6) Communication/Expectation — Release timelines and product-state ambiguity (v3 “soon”, degenai “imminent”) (Medium frequency, Medium severity)
**What users experienced**
- Repeated “when will v3 be released?” and “degenai updates soon” messaging without dates.
- Token utility strategy discussion shows concern about balancing token mechanics vs UX friction.

**Why it matters**
- “Soon” messaging increases churn and rumor cycles—especially when the Discord is already market-noise heavy.

**Examples**
- v3 “nearing completion… close to release” (Apr 26).
- degenai updates “imminent” (Apr 26).

---

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

### Observed: Discord being used as a price chat + general lounge more than a product support hub
- Actual usage: market sentiment, investor outreach suggestions, coordination chatter (“eliza army” steering group).
- Intended usage (implied by an OSS framework): technical Q&A, integration help, contribution onboarding.

**Emerging need**
- A clearer separation between: *support*, *builder discussion*, and *market chatter*.

---

### Observed: Builders are adopting ElizaOS for “agent operations” (LifeOps, calendars, automation, coding agents)
Signals from dev summary + community topics point to real-world operator workflows:
- LifeOps expansion (Google Calendar management)
- n8n workflow credential feedback refinement
- GitHub PAT persistence for coding sub-agents
- Eliza Cloud monetization (pay-as-you-go containers, org credit balances)

**Feature requests aligning with this pattern**
- Better “operator-grade” docs: how to connect credentials, how to debug failures, how to reason about agent planning (HTN), how to deploy reliably.

---

### Emerging/unexpected: Strong pull toward agent commerce + Web3 integrations
From monthly GitHub proposals (closed but indicative of demand):
- Identity/trust layers for agents (cryptographic identity, scoped delegation)
- Marketplaces for agent-to-agent services and GPU rental
- x402 pay-per-call APIs for autonomous paid tool usage

**Implication**
- Users want safe defaults and guardrails (spend limits, delegation, receipts) as much as they want integrations.

---

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

### A) Token-price noise drowning support (Community)
**Opportunities (prioritized)**
1) **High impact / Low difficulty:** Create and enforce a “Support-first routing” policy
   - Add pinned guidance in 💬-discussion: “Support questions → #help / #builders; price talk → #trading”
   - Auto-reply bot when messages include common price tickers/phrases, suggesting the trading channel.
2) **High impact / Medium difficulty:** Introduce a dedicated **#help-intake** channel with a required template (environment, version, logs)
   - Use Discord “Forum Channels” with tags (Bug, Integration, Docs, Cloud Billing).
3) **Medium impact / Low difficulty:** Weekly “Build Update” post to shift conversation toward product progress
   - Summarize concrete shipped items (e.g., pay-as-you-go hosting, calendar support) rather than timeline hype.

**Comparable approaches**
- Many OSS Discords (e.g., popular web frameworks) use **forum-style help channels** + strict off-topic separation to keep support searchable.

---

### B) HTN/planning confusion (Documentation)
**Opportunities (prioritized)**
1) **High impact / Low difficulty:** Publish a single canonical doc page: “Planning in ElizaOS (v2 today)”
   - Define: HTN-lite vs full HTN, what’s shipped, what’s experimental, and extension points.
2) **High impact / Medium difficulty:** Add a “Planning Debug View” example (logs + visualization)
   - Show trigger → decomposition → step execution, with a minimal reproducible sample.
3) **Medium impact / Medium difficulty:** Add acceptance tests for HTN behaviors
   - So community can verify upgrades don’t regress decomposition semantics.

**Comparable approaches**
- Agent frameworks (and workflow engines) often ship **“concept + runnable example + debug tooling”** together; docs alone don’t resolve mental-model gaps.

---

### C) Broken links & access friction (Integration/Documentation)
**Opportunities (prioritized)**
1) **High impact / Low difficulty:** Add automated link checking to docs/README and key repo pages
   - Catch broken Play Store links and outdated invites.
2) **Medium impact / Low difficulty:** Maintain a “Project Directory” page (Hyperscape, apps, steering group contact)
   - One stable location rather than ad-hoc invite drops.
3) **Medium impact / Medium difficulty:** Versioned “Getting Started” landing page per release line (v2/v3)
   - Reduce confusion when links or instructions differ across versions.

**Comparable approaches**
- Docs sites commonly run CI link checkers (e.g., Mintlify/Docusaurus ecosystems) to prevent first-time UX failures.

---

### D) Intermittent runtime issues without diagnostics (Technical Functionality)
**Opportunities (prioritized)**
1) **High impact / Low difficulty:** Standardize a “bug report bundle” command
   - CLI or UI button: exports version, platform, plugin list, last N logs, config redactions.
2) **High impact / Medium difficulty:** Add lightweight client-side incident IDs in chat/runtime
   - When a user says “it broke,” they can paste an incident ID that maps to logs.
3) **Medium impact / Medium difficulty:** Add health checks + clearer transient-failure messaging
   - Distinguish “model timeout” vs “connector auth” vs “rate limit.”

**Comparable approaches**
- Infrastructure tools (and cloud CLIs) routinely provide `diagnostics` bundles to convert vague complaints into actionable reports.

---

### E) Scam targeting support seekers (Community/Security)
**Opportunities (prioritized)**
1) **High impact / Low difficulty:** Add an auto-moderation rule for new accounts posting links in help contexts
   - Quarantine suspicious links; require mod approval for first X posts containing URLs.
2) **High impact / Low difficulty:** Pin “Official support safety rules”
   - “Mods/devs will never DM you links; verify domains; use GitHub issues for code help.”
3) **Medium impact / Medium difficulty:** Verified-support roles + a public “staff directory” message
   - Reduce impersonation success rate.

**Comparable approaches**
- Crypto-adjacent OSS communities often rely on **link throttling for new users** + “no-DM support” policies.

---

### F) Release/timeline ambiguity (Communication)
**Opportunities (prioritized)**
1) **High impact / Low difficulty:** Replace “soon/imminent” with a public checklist + current status
   - “v3: in QA; blocking items: X; target window: week-of … (best effort).”
2) **Medium impact / Low difficulty:** Short “What shipped this week” changelog posts
   - Reinforce momentum without over-promising dates.
3) **Medium impact / Medium difficulty:** Beta sign-up cohort
   - Converts “when release?” into “join beta, give feedback,” producing structured input.

**Comparable approaches**
- Projects like Rust/Node ecosystems use **release trains** and “this is what’s in nightly/beta/stable” to align expectations.

---

## 4) Communication Gaps (expectations vs reality)

### Gap: Token utility expectations vs frictionless UX reality
- Team message: accept any payment method, buy back tokens (UX-first).
- User expectation (implied by complaints): token should have direct enforced utility or price support actions.

**Fix**
- Publish a plain-language explainer: “Token utility strategy: what it is / isn’t, and why.”

---

### Gap: “Issues with Eliza” reports are too vague to action
- Users ask in Discord without templates; issue resolves; no learnings captured.

**Fix**
- Provide a “How to report a bug” short form in Discord + link to GitHub issue template.

---

### Gap: Confusion about project context (ELIZA effect, Hyperscape, steering group)
- Positive: educational links were shared (Apr 27).
- Missing: a stable doc page explaining “why elizaOS is named this,” plus project map.

**Fix**
- Add a “Project Origins & Glossary” page + “Related Projects” directory.

---

## 5) Community Engagement Insights

### Power users and their needs (from observed interactions)
- **odilitime**: moderation, onboarding, resource sharing, community coordination (“eliza army” steering group); needs scalable tooling (auto-mod, structured help intake).
- **shawmakesmagic**: product strategy + token utility messaging; needs a consistent comms channel to reduce repeated debates.
- **thirti.eth**: deep technical exploration (HTN); needs authoritative technical docs and confirmation of current implementation.
- Contributor signal from dev summary: **lalalune** driving dependency modernization—needs CI clarity and contributor-friendly upgrade guidance.

### Newcomer questions indicating onboarding friction
- “Is anyone having issues with eliza rn”
- “Where can I access Hyperscape Discord / what’s the plan”
- “What is the ELIZA effect”
- “When v3 / degenai updates”

### Converting passive users into contributors
- Funnel market-focused users into tangible build tasks:
  - “If you want token value, here are 5 product tasks you can help with” (docs, link checks, examples, moderation bots, bug triage).
- Promote the CONTRIBUTING guide work (a PR exists in repo context) and pin “Good first issue” lists.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness (based on slice)
- Discord general chat produces **high volume but low actionability** (price talk, vague issue reports).
- GitHub issues/PRs capture detailed proposals well, but newcomers may not transition there.

### Improvements
1) **Structured Discord intake** (forum + templates + tags) feeding into GitHub when confirmed reproducible.
2) **Monthly “UX pulse” form** (5 questions, optional logs) linked in-app and pinned in Discord.
3) **Underrepresented segments to recruit**
   - Business clients using **Eliza Cloud** (billing, reliability, integrations)
   - Non-crypto users (productivity + automation only)
   - Mobile/desktop app users (onboarding, settings, connector setup)

---

## Prioritized High-Impact Actions (next 2–4 weeks)
1) **Create a structured #help-intake (forum-style) channel + required bug template + escalation path to GitHub.**
2) **Ship HTN/planning documentation: “What’s implemented today + runnable examples + debug guidance.”**
3) **Add automated link checking in CI for docs/README + fix known broken Milady Play Store link path.**
4) **Harden Discord safety: new-account link throttling + pinned “no-DM support” policy + verified staff directory.**
5) **Publish a “v3 status checklist” post and keep it updated weekly to replace “soon/imminent” ambiguity.**