# User Feedback Analysis — 2026-01-01 (based on 2025-12-29 to 2025-12-31 community data)

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

> Quantification note: counts below are based on distinct user questions / issue-reports appearing in the provided daily Discord summaries (Dec 29–31). Total observed “question/issue” items ≈ 18; percentages are approximate.

### A. Documentation (Highest frequency)
**Observed problems (≈ 45–55% of questions):**
- **Token migration clarity gaps**: repeated questions about whether migration is still possible, timeline (“ends in February”), eligibility/snapshot status (“snapshot already occurred”), and what users should do next (directed to `#migration-help`).
  - Examples: “Can I still migrate my Ai16z please?”, “Do snapshots not need to be taken…?”
- **Token reference info hard to find**: users asking for contract address, chain availability, token utility, and “where is token info?”
  - Examples: “What’s the contract of ElizaOS?”, “Is Eliza on BSC or SOL?”, request for a dedicated token page and pinned tweet.
- **FAQ / onboarding navigation friction**: users not finding the FAQ channel or where to “submit a ticket.”

**Impact:** High. These questions block onboarding and create repeated support load.

---

### B. Integration (High frequency, growing)
**Observed problems (≈ 15–25%):**
- **Embedding / integrating ElizaCloud agents into websites is non-obvious**: users need to know how to retrieve agent ID via API endpoints; guidance is being DM’d ad-hoc.
  - Example: user asked how to integrate an ElizaCloud agent into a website; answer required API endpoint + API key + agent ID lookup.
- **Transport/streaming complexity**: ongoing engineering work on unified hooks (HTTP/SSE/WebSocket) suggests developer demand, but end-user guidance is not present in the feedback stream (risk of “implementation exists, but unclear how to use”).

**Impact:** Medium–high. This aligns with real usage (developers shipping agents into products), so friction here reduces adoption.

---

### C. Technical Functionality (High severity, lower frequency)
**Observed problems (≈ 10–20%):**
- **Jeju OAuth3 testnet demo login not working** (explicitly reported).
  - Example: “Does the demo login work…? It doesn’t work.”
- **Agent chat/share-link errors**: users report inability to chat with an agent via share link / “previously working system now errors” without diagnostics.
  - Examples: “unspecified errors when trying to chat with an agent via share link”; “encountering an error with something previously working.”

**Impact:** High severity. Breaks demos and first-time experiences.

---

### D. UX/UI (Medium frequency)
**Observed problems (≈ 5–10%):**
- **Character URL / share link confusion**: users getting the “wrong” URL unless they copy from browser; “share link” appears misleading for dev workflows.
  - Example: “How do I get the correct character URL? Copy the URL directly from the browser… should contain the character ID.”

**Impact:** Medium. Causes “it’s broken” perceptions during setup/integration.

---

### E. Community / Access Gating (Medium frequency)
**Observed problems (≈ 5–10%):**
- **Gated channels (Spartan) create repeated “how do I join?” loops**: requires wallet verification and correct token holdings mapping (Collabland still reflecting ai16z vs ElizaOS mentioned as an action item).
  - Example: “How can I join the Spartan group? Verify your holding…”

**Impact:** Medium. Repeated friction for motivated users; also a trust risk if verification appears inconsistent.

---

### F. Integration + Ecosystem Constraints (Medium severity)
**Observed problems (≈ 5–10%):**
- **Twitter/X integration constraints and costs**: users asked for cookie-based auth plugin; answer was “no,” plus explicit mention of Twitter API cost barrier ($200/mo).
- **Bridge direction limitations**: users asked bridging BSC → Solana; answer: only Solana → other chains.

**Impact:** Medium. These constraints are legitimate, but need clearer preemptive communication.

---

### G. Developer Experience / Release Process (Low frequency, high leverage)
**Observed problems (≈ 5–10%):**
- **Plugin version bump uncertainty**: “Should I pump the version for every plugin PR?” and desire for CI/release automation (“release-please” style).

**Impact:** Medium. Affects contributor velocity and consistency.

---

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

### How users are actually using elizaOS (observed)
- **As a Web3-adjacent agent platform**: a significant portion of discussion is token/migration, chain availability, gated access, bridging, wallet workflows.
- **As a foundation for “agent products,” not just a framework**: ElizaCloud website embedding, DegenAI autotrader access, and planned “cloud/babylon” launches dominate practical user intent.
- **As a community-driven plugin ecosystem**: sharing external repos (skills, OpenSouls plugin), asking about Twitter plugin auth, Discord plugin logging, and unified hooks.

### Emerging / unexpected use cases
- **Automated community storytelling / media generation**: Jin’s pipeline generates “newspaper-style” images from Discord/GitHub activity with seasonal variance—this is a novel “community ops” use of agent tooling.
- **Speculative “intel/counterintel agents”**: discussed hypothetically in partners channel; indicates interest in advanced agent orchestration and privacy/security positioning.
- **Game development “slow-burnish” projects**: Zelda/RuneScape recreation interest hints at demand for long-running agent-driven worlds or tooling that supports content pipelines.

### Feature requests aligning with real usage
- Website integration primitives (stable embed SDK, example apps, clearer API flows).
- Better logging/observability (Discord plugin logging improvements; duplicate events fixes; agentId/name fallback).
- Multimodal agents (request: “agents that can understand images without being told”).
- Release automation for plugins (CI-based versioning).

---

## 3) Implementation Opportunities (2–3 concrete solutions per major pain point)

### Pain point 1: Migration + token information confusion (Documentation / UX)
**High impact, low–medium difficulty**
1) **Create a single “Token & Migration Hub” page** linked from website header/footer:
   - Include: migration steps, timeline, snapshot eligibility rules, FAQs, contract addresses per chain, official links (CoinGecko, explorers), bridging rules, and “common errors.”
   - Mirror what projects like **Arbitrum / Optimism** do: one canonical page with “Do not trust other links,” per-chain addresses, and step-by-step guides.
2) **Add a “Migration status checker”** (simple web form):
   - User inputs wallet address → returns: snapshot eligibility (if available), correct chain instructions, and links to `#migration-help`.
   - Similar to **airdrop eligibility checkers** used by many L2 ecosystems.
3) **Pin a Discord + X (Twitter) “contract addresses & links” post**:
   - Reduces repeated “What’s the contract?” questions.
   - Already requested explicitly (“Create pinned tweet with contract addresses”).

---

### Pain point 2: Wallet connection / transfer issues (Integration / Technical Functionality)
**High impact, medium difficulty**
1) **Publish an “Official wallet compatibility matrix”**:
   - MetaMask ↔ Phantom workflows, Solana vs EVM guidance, known issues (e.g., “MetaMask transfer issues → import EOA into Phantom” workaround that Kenk repeats).
   - Similar to how **Magic Eden** and **Jupiter** document wallet differences and common pitfalls.
2) **Add targeted troubleshooting prompts in help channels** (structured intake):
   - Bot asks: chain, wallet type, desktop vs extension, error text/screenshot.
   - Produces actionable data instead of “it doesn’t work.”
3) **Fix/validate Collabland role verification** for ElizaOS holdings (not ai16z):
   - Reduces Spartan access friction and prevents support churn.

---

### Pain point 3: Broken demos / unclear errors (Jeju OAuth3 login; share-link chat errors) (Technical Functionality / UX)
**Very high impact, medium difficulty**
1) **Treat demos as production: add monitoring + “demo mode” fallback**
   - If OAuth3 demo login fails, show a clear banner: “Demo login temporarily unavailable” + alternate read-only demo path.
   - Common practice in developer platforms (e.g., **Supabase** status + graceful UI messaging).
2) **Add error envelopes and client-visible error codes** for share-link chat failures:
   - Replace “unspecified error” with “ELZ-CHAT-403 share link expired” or “ELZ-CHAT-500 message router duplicate event,” etc.
   - Similar to **Stripe**-style error codes that enable self-serve debugging.
3) **Publish a “Known Issues” page** linked from Cloud UI and Discord:
   - “Phantom desktop connect issue,” “OAuth3 demo login,” “share-link chat errors,” with ETAs/owners.

---

### Pain point 4: Website embedding/integration lacks standard path (Integration / Documentation)
**High impact, medium difficulty**
1) **Release an official “ElizaCloud Embed Starter Kit”**
   - Minimal JS snippet or React component; handles agent discovery (agent ID), auth, and chat UI embedding.
   - Similar to **Intercom**, **Crisp**, or **Slack app** “Add to site” quickstart flows.
2) **Document a canonical integration flow** with copy-paste examples:
   - “Get API key → list agents endpoint → select agentId → embed.”
   - Avoid DM-only support; consolidate into docs + examples repo.
3) **Add a UI affordance: “Copy embed code” in Cloud dashboard**
   - Eliminates the “how do I get agent ID?” loop.

---

### Pain point 5: Plugin release/versioning uncertainty (Community / DX)
**Medium impact, low–medium difficulty**
1) **Adopt automated releases (Changesets or release-please) for plugins**
   - Addresses “Should I bump version every PR?” and reduces maintainer overhead.
   - Widely used in ecosystems like **Next.js**, **pnpm**, and many monorepos.
2) **Contributor guide: “When to bump versions” + PR template checkbox**
   - Short-term fix until automation is deployed.
3) **Standardize plugin CI checks** (lint, typecheck, minimal integration tests)
   - Reduces regressions like duplicate events or media handler issues.

---

## 4) Communication Gaps (Expectations vs reality)

### Where expectations don’t match reality
- **“Test URL?” / “Does demo login work?”**: users expect demos to be functional; reality: demo login is currently broken on Jeju OAuth3 testnet.
- **Bridging expectations**: users expect bi-directional bridging (“BSC → Solana”), but current limitation is one-way (“Solana → other chains only”).
- **Access expectations for DegenAI**: some curiosity implies broad availability, but access is gated at **1M tokens** for autotrader functionality—this should be explicit in a public feature matrix.
- **Twitter plugin auth**: users ask for cookie-based auth (cheaper/easier), but it’s not supported; cost barrier remains.

### Recurring questions indicating doc/onboarding gaps
- “Where is the FAQ channel?”
- “Where to submit a ticket?”
- “What’s the contract address?”
- “Is Eliza on BSC or SOL?”
- “How do I integrate an ElizaCloud agent into my website?”
- “Can I still migrate / did snapshot happen?”

### Specific improvements
- Add an **Onboarding “Start Here”** page in Discord with: FAQ, migration, contracts, Cloud beta access, and support intake.
- Add a **Capabilities & Constraints** doc: supported chains, bridging directions, wallet support, Twitter/X limitations, and known costs.
- Ensure answers given in Discord (e.g., contract address, migration end date) are mirrored in docs within 24 hours.

---

## 5) Community Engagement Insights

### Power users / key helpers observed (and their needs)
- **Kenk**: repeatedly helping with wallet migration/verification and acknowledging docs/website gaps (needs better canonical docs and verification tooling).
- **Odilitime**: active on plugins (OpenAI image generation fix, caching), Jeju demo feedback, and roadmap ideas (needs clear maintainer processes and test environments).
- **Stan**: core DX (unified hooks, duplicate events, CI/release automation idea) (needs automation and consistent contribution workflow).
- **sam**: hands-on Cloud website integration support via API snippets (needs official integration docs + SDK).
- **Destiny / Broccolex / satsbased**: onboarding navigation help (needs better Discord information architecture).

### Newcomer friction signals
- Can’t find FAQ/ticket paths.
- Confusion around token migration mechanics and timelines.
- Basic “where do I get the right URL/agentId” integration hurdles.

### Converting passive users to contributors
- Create a **“Good first issues: Docs”** board specifically for migration FAQ, token hub page, and integration examples.
- Run a weekly **office-hours + pairing session**: “Embed an ElizaCloud agent in 30 minutes.”
- Recognize community helpers with a **Support Contributor role** and a lightweight playbook (what to ask, where to file issues, how to escalate).

---

## 6) Feedback Collection Improvements

### Effectiveness of current channels
- **Discord is high volume but low structure**: many “unanswered” questions (e.g., “Is there a test URL?”, “Where’s this RuneScape game being built?”) and many issues lack reproducible details (“unspecified error”).
- **GitHub signal is currently low in this slice** (no new issues/PRs on Dec 31–Jan 1 in core repo), suggesting problems are being handled informally in Discord rather than captured for triage.

### Improvements for structured, actionable feedback
1) **Introduce a “Bug report” Discord form/workflow** (bot-driven):
   - Required fields: product area (Cloud/Jeju/Plugin), steps, expected vs actual, logs, platform.
   - Auto-creates a GitHub issue with labels.
2) **Add in-product feedback hooks in Cloud beta**
   - One-click “Report issue” that attaches environment data + session ID.
3) **Weekly triage digest**
   - Summarize top Discord issues → link to GitHub tracking items → post back to Discord for transparency.

### Underrepresented segments (missing feedback)
- **Non-crypto developers** trying to use elizaOS purely as an agent framework (feedback is dominated by token/migration topics).
- **Windows-first developers** (only one explicit Windows workaround appears; likely more silent failures).
- **Teams evaluating enterprise readiness** (few comments about compliance, uptime, SLAs—likely not present in Discord but important for Cloud adoption).

---

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

1) **Ship a canonical “Token & Migration Hub” + pinned contract addresses (Discord + X)**
   - Immediate reduction in repeated questions; improves trust and onboarding.

2) **Fix Jeju OAuth3 demo login and add demo monitoring + clear failure messaging**
   - Protects public perception during “going public” prep; reduces confusion.

3) **Publish an official ElizaCloud website integration quickstart + starter kit + “Copy embed code” UI**
   - Aligns with actual usage; turns ad-hoc DM support into scalable self-serve docs.

4) **Implement structured support intake (Discord bot form → GitHub issues) and a “Known Issues” page**
   - Converts vague reports into actionable engineering work; improves response times.

5) **Adopt plugin release automation (release-please/Changesets) and document versioning rules**
   - Improves contributor throughput and reduces maintainership friction across plugins.