## User Feedback Report — 2025-12-27 (based on aggregated feedback through 2025-12-26) ### Data coverage & confidence notes - **Primary sources:** Discord (#discussion, #coders, #partners, core-devs) across **2025-12-24 → 2025-12-26**, plus GitHub repo activity summaries (**2 PRs opened, 0 issues created on 12/26–12/27**). - **Quantification approach:** The dataset is qualitative (no message-level counts). Percentages below are based on **share of daily digests / channels where an issue appears**, and/or **count of distinct user reports** explicitly captured in the highlights/FAQs. --- ## 1) Pain Point Categorization (Top recurring 5–7) ### 1. Documentation / Integration — Token migration confusion + exchange handling **Frequency:** Appears in **3/3 daily digests (100%)** and spans both Discord support and GitHub issue context (e.g., Tangem eligibility/support concern in monthly top issues list). **Severity:** High (financial impact + trust erosion). **What users are experiencing** - Migration tool shows **“0 tokens”** unexpectedly due to **snapshot + “must migrate from the same wallet”** constraint (Dec 25 FAQ). - **Exchange users** experienced confusion due to **snapshot-based migration splitting liquidity** and differing exchange support (Dec 26 highlights). - Wallet compatibility gaps (e.g., users asked about **Moonshot → migration**, advised to move to Phantom; GitHub issue list includes **Tangem WalletConnect not supported**). - Ongoing concern about **delisting risk** on Korean exchanges in January (Dec 25 highlights). **Representative examples** - “Why does migration tool show 0 tokens?” → must be snapshot wallet (Dec 25). - “Migration used snapshot approach, split liquidity, exchange confusion” (Dec 26). --- ### 2. Technical Functionality / UX — ElizaOS Cloud login + deployment reliability **Frequency:** Mentioned in **2/3 daily digests (67%)**, with multiple distinct incidents. **Severity:** High (blocks first successful use of Cloud). **What users are experiencing** - “Application error when logging into ElizaCloud” (Dec 26). - Agent deployment/interaction error: **“username null”** (Dec 26). - Authentication fragmentation prompting SSO discussions (core-devs mentions **custom SSO**). **Representative examples** - DorianD reported login errors and “username null” deployment error; other users shared successful deployments as workaround encouragement (Dec 26). --- ### 3. Technical Functionality — Streaming broken due to dependency mismatch (core + OpenAI plugin) **Frequency:** Mentioned in **1/3 daily digests (33%)** but flagged by core-devs as broken in core, with PR activity underway. **Severity:** Medium–High (breaks a “quality of conversation” feature; impacts perceived responsiveness). **What users are experiencing** - “Streaming functionality broken in the core due to wrong dependencies” (Dec 26). - Fix underway (core-devs references **PR #22** for OpenAI plugin streaming fix; GitHub weekly/monthly summaries also emphasize streaming initiatives). --- ### 4. Technical Functionality / Documentation — Toolchain rigidity & environment confusion (bun vs npm, version mismatches) **Frequency:** Mentioned in **2/3 daily digests (67%)** across direct questions + action items. **Severity:** Medium (friction for new contributors and builders). **What users are experiencing** - Direct request: “Is it possible to use npm instead of bun?” → “nope” (Dec 26 coders). - Ongoing “Bun/Node/NPM version inconsistencies” noted as a technical action item (Dec 24). --- ### 5. Performance / Technical Functionality — Knowledge upload constraints & unclear best practices **Frequency:** Mentioned in **2/3 daily digests (67%)**. **Severity:** Medium (limits real-world agent use with docs/knowledge). **What users are experiencing** - File upload limit **50MB** (Dec 24). - Users asking about uploading **multiple Markdown files**; dev indicates it should work and optimization is ongoing (Dec 26). - Users uncertain how much content (“300 pages of book data”) is appropriate and how it affects context (Dec 24). --- ### 6. Integration / Technical Functionality — Local model + plugin reliability (Ollama config, unruggable SDK/parsing points) **Frequency:** Mentioned in **1/3 daily digests (33%)**, but symptomatic of broader “plugin edge cases” that tend to repeat. **Severity:** Medium (affects non-cloud and advanced builders). **What users are experiencing** - Questions about **Ollama model configuration** (`OLLAMA_SMALL_MODEL=llama3.2:latest`) (Dec 26). - Broken plugin with “parsing points and unruggable SDK” (Dec 26). --- ### 7. Community / Documentation — Expectation gaps: token value narrative, Jeju ambiguity, and “pending event” promises **Frequency:** Appears in **3/3 daily digests (100%)**. **Severity:** High (trust + retention risk, overwhelms product discussion). **What users are experiencing** - Persistent frustration: token down **90–99%**; debate over whether project is “dead” (Dec 26) vs “keep building” optimism (Dec 25). - Jeju uncertainties: “Will Jeju token be $elizaOS?” (asked, unanswered), and unclear timeline (“life-changing event” expected around October still pending) (Dec 26 partners). - Marketing dependency: urgency to regain **X (Twitter) account** viewed as critical (Dec 26). --- ## 2) Usage Pattern Analysis (actual vs intended) ### How users are actually using elizaOS / ElizaCloud - **Rapid prototyping + novelty agents:** Users are deploying themed agents (e.g., marijuana-themed, “Satoshi”, “Pepe”, “Trump”) immediately after Cloud launch (Dec 26). *Implication:* The fastest-growing usage is “builder playground + shareable demos,” not only serious enterprise agents. - **Knowledge-base agents:** Users attempt to upload large content sets (e.g., “300 pages of book data”), ask about multiple Markdown files, and format guidance (Markdown preferred) (Dec 24, Dec 26). - **Personal automation:** Example of using **async agents** to maintain a streak workflow (tip.md) (Dec 25). *Emerging use case:* “lightweight autonomous routines” rather than chat-only assistants. - **Tool-assistance expectations beyond API integrations:** A user asked for agent help with **DaVinci Resolve Studio** editing; community suggested Gemini screen share workaround (Dec 26). *Unexpected demand:* “Desktop copilots” / UI-guided workflows. ### Mismatch vs intended usage (inferred from questions) - Users expect Cloud to be “deploy and chat instantly,” but hit **login/deploy blockers** (login errors, username null). - Users expect standard Node workflows (npm) but encounter **bun-only requirement**. - Users expect a clear coupling between Cloud success and token value; they do not see a coherent explanation beyond buybacks. ### Feature requests aligning with observed usage - **Project showcase pipeline** (#build-showcase usage encouraged) to match the “demo-first” community behavior. - **In-product streaming + stability** to support “feels alive” agent chats (streaming fixes). - **Better knowledge ingestion UX** (multi-file, limits, chunking guidance) driven by real attempts to load books/docs. --- ## 3) Implementation Opportunities (2–3 concrete solutions per major pain point) ### A) Token migration confusion + exchange handling (Documentation / Integration) **High impact / Medium difficulty** 1) **One authoritative “Migration Hub” doc + decision tree** - Include: snapshot rules, “same wallet” requirement, exchange-specific paths, wallet-compatibility matrix (Phantom, Moonshot, Tangem constraints), and scam warnings. - Pattern used by similar projects: **Uniswap / Arbitrum-style migration FAQs** with flowcharts and “If you held on exchange X…” sections. 2) **Migration portal UX: eligibility diagnostics** - Show *why* eligibility is 0: “Wallet did not hold tokens at snapshot” vs “wallet type not supported” vs “exchange custody.” - Provide actionable next steps and a safe link to official support channels. 3) **Exchange comms kit** (PDF + API/ops checklist) - Standardize what exchanges need (token standard change away from token2022, CCIP mintability rationale) and publish a status table. --- ### B) Cloud login + deployment reliability + auth fragmentation (Technical Functionality / UX) **High impact / Medium–High difficulty** 1) **Ship unified auth (SSO) with staged rollout** - Start with “one identity across Cloud + CLI + dashboard,” then add orgs/teams. - Comparable pattern: **Supabase Auth / Clerk** integration playbooks (start simple, add enterprise features later). 2) **Harden deploy pipeline with structured error reporting** - Convert “username null” and generic “application error” into typed errors with user-facing remediation (“set username in profile”, “session expired”, “retry deploy”). - Add server-side correlation IDs + client “Copy error report” button. 3) **Add status + incident transparency** - Public status page or minimal “Cloud health” endpoint + Discord bot updates during incidents. - Comparable pattern: **Vercel / Fly.io** status + incident updates reduces support churn. --- ### C) Streaming broken / dependency mismatch (Technical Functionality / Performance) **Medium–High impact / Low–Medium difficulty** 1) **Pin + validate dependency graph for streaming-critical packages** - Add CI checks ensuring plugin-core compatibility (prevent “wrong core dependencies” regressions). 2) **Golden-path streaming integration tests** - One end-to-end test per provider (OpenAI initially) verifying SSE/token streaming works in real runtime. 3) **Feature flag streaming** - Default on where stable, auto-fallback to non-streaming with warning when incompatible. --- ### D) Toolchain rigidity (bun-only) & environment setup confusion (Documentation / Technical Functionality) **Medium impact / Low difficulty (docs) + Medium difficulty (tooling)** 1) **“Why bun” + “Can I use npm?” doc page** - Explain supported paths and provide “escape hatches” (e.g., using npm for non-core tasks, if feasible). 2) **Single “doctor” command in CLI** - `elizaos doctor` checks bun/node versions, env vars, and common pitfalls (file upload limits, auth state). - Comparable pattern: **Expo doctor**, **Flutter doctor**. 3) **Lockfile + version policy enforcement** - Standardize versions in `.tool-versions` or similar and validate in CI. --- ### E) Knowledge uploads: limits, multi-file, and best practices (Performance / Documentation) **Medium–High impact / Medium difficulty** 1) **Knowledge ingestion guide with concrete sizing rules** - “50MB limit,” recommended chunking, Markdown structure templates, what happens to context, and retrieval expectations. 2) **Upload UX improvements** - Multi-file drag/drop, progress UI, background processing, and explicit indexing state (“Queued / Indexing / Ready”). 3) **Roadmap clarity for custom model hosting** - Since “custom model hosting next week” was mentioned, publish a short spec: supported runtimes, how to connect own GPU servers, security model. --- ## 4) Communication Gaps (expectations vs reality) ### Gap 1: “Tech progress” vs “token value” linkage is unclear - Users repeatedly debate whether the project is dead while Cloud is launching and improving. - The statement “Cloud revenues drive buybacks” exists, but users still ask “why invest if cloud doesn’t impact token,” and want clearer token utility beyond buybacks. **Fix** - Publish a **plain-language token utility page**: what accrues value (and what does not—e.g., yield), where buybacks come from, and what milestones unlock additional utility (e.g., Jeju). ### Gap 2: Jeju details (token, timeline, decentralization) are partially answered - Decentralization goal was confirmed (“at the heart of it”), but **Jeju token = $elizaOS?** was asked and **unanswered**. - “Life-changing event around October” still lacks a concrete update beyond “waiting on others.” **Fix** - Create a **Jeju FAQ** with explicit “known / unknown / not yet decided” sections and update cadence. ### Gap 3: Onboarding & “first successful deploy” gaps - New Cloud users hit login/deploy issues; devs respond ad hoc in Discord. - Repeated how-to questions: upload multiple MD files, large docs, model configuration. **Fix** - Add an onboarding checklist: **Create → Upload knowledge → Deploy → Chat → Share** with screenshots and known error states. --- ## 5) Community Engagement Insights ### Power users observed (and what they need) - **Odilitime**: answers tokenomics/revenue model questions; discusses SSO; supports Jeju decentralization narrative. *Needs:* consistent public comms artifacts to reduce repeated Q&A load. - **Borko**: Cloud limits + roadmap (50MB limit, custom model hosting soon), file upload optimization. *Needs:* productized documentation + clear UI around limits/indexing. - **Stan ⚡ / standujar**: core quality work; streaming fix PR references; cleanup/tests. *Needs:* CI guardrails, reproducible bug reports, and prioritized issue lists. - **The Light / sayonara / Hexx 🌐**: community support (deploy encouragement, workarounds, scam warnings). *Needs:* official support scripts, verified links, and escalation paths. ### Newcomer questions indicating onboarding friction - Migration: “0 tokens,” wallet/exchange confusion, scam exposure risk. - Dev setup: bun vs npm, version mismatches. - Cloud basics: upload constraints, multi-file knowledge, deploy/chat errors. ### Converting passive users into contributors - Provide “good first issue” tracks aligned to current pain: - “Improve error messages for deploy/login” - “Docs: Migration hub + Jeju FAQ” - “CLI doctor command” - Promote #build-showcase as a pathway: “Ship a demo → write a short guide → become maintainer.” --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** is effective for rapid responses but leads to: - repeated questions (migration, tokenomics, onboarding), - high scam/impersonation risk during sensitive flows (noted explicitly in GitHub issue context and Discord warnings), - low structure for triage (“application error” without logs). - **GitHub** is better for actionable technical tracking, but **recent period shows 0 new issues on 12/26–12/27**, suggesting users default to Discord even for bugs. ### Improvements for more structured, actionable feedback 1) **In-product feedback button** (already suggested as a plugin issue in weekly/monthly notes: “user feedback button”) - Collect: page, action, error code, optional screenshot, logs, and consent. 2) **Standard bug report template for Cloud** - Require: repro steps, browser, region, correlation ID, agent ID, deploy method (CLI vs UI). 3) **Weekly “Top 5 problems” poll in Discord** - Fixed options tied to roadmap epics (Auth, Deploy, Knowledge, Streaming, Migration) to quantify priorities. ### Underrepresented segments to capture - **Exchange users** (Bithumb/Coinone/Korbit concerns): need a dedicated intake form for custody/migration edge cases. - **Non-crypto developers**: currently drowned out by token discussion; consider a separate “builders” newsletter/issues digest. - **Teams/organizations**: SSO and identity hints demand, but little direct feedback captured—run targeted interviews. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1) **Ship “Migration Hub” + portal eligibility diagnostics** (docs + UX) - Goal: reduce repeated “0 tokens” confusion and exchange migration friction; improve safety against scams. 2) **Stabilize Cloud onboarding: fix login + “username null” deploy path + add typed errors** - Goal: increase first-successful-deploy rate; reduce Discord support load. 3) **Implement unified auth direction (SSO plan + incremental delivery) and publish it** - Goal: align expectations, reduce identity fragmentation, support CLI↔Cloud seamless flow. 4) **Publish “Knowledge uploads” guide + improve upload UX visibility (limits, indexing state)** - Goal: support the dominant real usage pattern (document ingestion) and reduce “how much context?” uncertainty. 5) **Add structured feedback capture: in-product feedback button + correlation IDs + CLI `doctor`** - Goal: turn vague Discord reports into reproducible issues; increase GitHub-quality bug reports without increasing contributor burden.