## User Feedback Analysis — 2026-04-11 (based on community + GitHub data through 2026-04-10) ### Data coverage & volume (for quantification context) - Discord (last 3 days summarized): ~6–10 distinct feedback threads, heavily clustered in **(a) v2 Socket.IO integration**, **(b) tokenomics clarity**, and **(c) “what is X project / how do I do Y” onboarding**. - GitHub (month-to-date snapshot included): multiple **developer-experience breakpoints** (notably `elizaos create` on macOS + bun dependency behavior) and several **security/authorization** and **economic-layer plugin** proposals. --- ## 1) Pain Point Categorization (top recurring 5–7) ### 1) Documentation — Missing canonical protocol + schema docs (High frequency, High severity) **What users report** - **Socket.IO v2 messaging protocol is not documented**: message type enum, required/optional payload fields, event names, and auth requirements. - Example: shah0406 had to reverse-engineer that the working pattern is `socket.emit('message', { type: 1|2, payload: ... })` and that auth requires `{ entityId: UUID }`. - “Use Cursor to query the codebase” was suggested as a workaround, reinforcing that **docs aren’t the source of truth**. **Quantification** - In the #coders thread, **4 distinct documentation questions** were asked by a single integrator (message types, schemas, required fields, DM creation). That’s ~**40–50% of the meaningful technical discussion** captured for the day. **Primary affected users** - Dashboard builders, connector authors, anyone building non-official clients. --- ### 2) Integration — Programmatic DM / channel operations unclear (Medium frequency, High severity) **What users report** - Need to **programmatically discover/create a DM channel** “without the official UI” (shah0406). - Indicates integrators are building **custom front-ends / dashboards** and need parity with official client flows. **Severity driver** - Blocks integrations even when messaging basics work. --- ### 3) Community / Communication — Token utility, buybacks, gas fees: expectations vs reality (High frequency, Medium severity but high sentiment risk) **What users report** - Repeated questions: token utility timeline, buyback timing, Jeju gas fee implementation. - Responses: “some airdrops planned, details not available”; “no plans beyond what was previously laid out.” - Users expressed frustration at vagueness. **Quantification** - In #discussion, **3 core recurring questions** (airdrops, token utility timing, buyback/Jeju timeline) dominated the substantive conversation—~**60–70% of the non-promotional content** in that channel segment. --- ### 4) Technical Functionality — Wallet verification / Collab.land support path unclear (Medium frequency, Medium severity) **What users report** - Wallet verification problem with Collab.land (Huey79ng) and no clear resolution in-thread. **Severity driver** - Prevents access to gated channels/roles; increases support burden in public chat. --- ### 5) Technical Functionality / Developer Experience — “elizaos create” fails on macOS due to bun postinstall behavior (Lower frequency in this dataset, High severity) **What users report (GitHub issue #6704)** - `elizaos create` fails with: “Bun’s postinstall script was not run…” - CLI cleans up project directory after failure, leaving user with nothing to debug. - Root cause: bun runtime packaged as runtime dependency; conflicts with bun’s own install behavior on macOS Apple Silicon. **Severity driver** - Hard onboarding blocker for new developers on macOS. --- ### 6) Security / Safety — Preventing unsafe agent operations is an open concern (Lower frequency, High severity) **What users report** - Discord: explicit concern about preventing agents from unsafe operations (unresolved). - GitHub: multiple proposals around **capability-based authorization**, AgentID, delegation chains, and tool-call enforcement. **Severity driver** - As agents gain wallet + execution abilities, lack of clear safety model becomes a trust blocker. --- ### 7) Project Discovery / Onboarding — “What is elizabao_ai and what can I do with it?” (Medium frequency, Low/Medium severity) **What users report** - Repeated confusion about elizabao_ai status and user capabilities; interest growing. **Severity driver** - Creates noise in general channels and undermines confidence when projects are mentioned without clear call-to-action. --- ## 2) Usage Pattern Analysis (actual vs intended) ### A) Users are building custom dashboards + clients (actual) vs primarily using official UI/connectors (intended) - shah0406’s setup: custom dashboard (8080) + ElizaOS v2 backend + Socket.IO + HTTP polling fallback + local model (Qwen) via external GPU provider. - This implies real demand for: - Stable network protocol docs - Client SDKs / typed schemas - Reference implementations beyond the official UI **Feature requests aligned with this usage** - Canonical Socket.IO message spec + auth flow - Programmatic DM/channel management endpoints --- ### B) Emerging use case: agent economies + usage-based billing + marketplaces - Community/dev mentions: x402 usage-based billing on Base (Orbis), wallet plugin, “economic memory” (MnemoPay), marketplace plugin proposal (MAXIA), safety scoring plugin (SafeAgent), incentive protocol (AIGEN). - This indicates users are pushing ElizaOS toward an **agent commerce stack**, not just “chat agents.” **Feature requests aligned** - Standardized authorization/capability tokens for tool calls - Auditing/ledger hooks and safe defaults for high-risk actions --- ### C) Community expects product-like token communications - Even technical channels are pulled into roadmap/token questions. - Suggests ElizaOS is being used/valued as both **open-source framework** and **token/economic ecosystem**, requiring different comms artifacts. --- ## 3) Implementation Opportunities (2–3 concrete solutions per major pain point) ### Pain Point: Missing Socket.IO v2 protocol documentation **High impact / Low–Medium difficulty** 1. **Publish a “Socket.IO Gateway Spec” page** (single source of truth) - Include: event names, `message.type` enum table, payload JSON schemas, auth (`entityId`), error codes, and examples for ROOM_JOINING + SEND_MESSAGE. - Add a “compatibility” note: v2 vs v3 differences. - Similar approach: **Discord Gateway docs** (opcode/event + payload schemas) and **Matrix Client-Server spec**. 2. **Generate types directly from code (or schemas)** - Export a small `@elizaos/socket-protocol` package with TypeScript types and zod validators. - Similar approach: Kubernetes publishes **OpenAPI schemas**; many projects ship shared “protocol” packages to prevent drift. **Medium impact / Medium difficulty** 3. **Provide a minimal reference client** - A runnable example: connect → auth → join room → send message → receive message. - Include HTTP polling fallback example since users are using it already. --- ### Pain Point: Programmatic DM/channel creation/discovery unclear **High impact / Medium difficulty** 1. **Add a documented “DM API” (or connector-agnostic room API)** - Endpoints/actions: `listRooms`, `getOrCreateDm(participantEntityId)`, `createRoom(members, metadata)`. - Provide a clear mapping: “room” vs “channel” vs “dm”. 2. **Document the internal flow used by the official UI** - “What the official UI does” section: sequence diagram + required server calls/events. **Similar projects** - Slack/Discord both document DM creation flows; Matrix exposes room creation APIs with membership rules. --- ### Pain Point: Tokenomics / roadmap ambiguity causing frustration **High impact / Low difficulty** 1. **Create a “Token Utility & Incentives: What’s confirmed vs speculative” living page** - Use three columns: *Shipped*, *Confirmed (no date)*, *Exploring*. - Add explicit “We will not answer timing questions until X milestone” policy to reduce repeated churn. 2. **Ship a lightweight monthly “Economic Layer Update”** - Even if “no change,” say: “no change since last update” + what would need to be true to change. **Similar projects** - Many crypto-adjacent OSS projects run **regular cadence updates** with explicit “no ETA” rules to prevent expectation spirals. --- ### Pain Point: Collab.land wallet verification support is unresolved in public chat **High impact / Low difficulty** 1. **Add a pinned “Wallet Verification Troubleshooting” guide** - Common errors, steps, what to DM/support, screenshots, and expected resolution time. 2. **Add a /support intake form or Discord ticket bot for verification issues** - Tag to a private mod queue; reduces public back-and-forth. **Similar projects** - Most token-gated communities use **ticket bots** (e.g., Ticket Tool) with canned diagnostics. --- ### Pain Point: macOS onboarding failure (`elizaos create` + bun postinstall) **High impact / Medium difficulty** 1. **Fix packaging: remove bun runtime dependency; keep only `@types/bun` as devDependency** - Aligns with issue #6704’s proposed fix. 2. **Change CLI behavior: do not delete the project folder on build failure** - Keep artifacts + write a “failure report” file (env, stack, steps). - Similar approach: create-react-app and many scaffolding CLIs keep the generated directory and print next steps. 3. **Add a preflight check** - Detect bun install mode / postinstall constraints and warn before scaffolding. --- ### Pain Point: Agent safety / unsafe operations (tool-call authorization) **High impact / Higher difficulty (but strategically crucial)** 1. **Ship a first-party “capability / policy layer” MVP** - Start with: allowlist tools, per-tool human confirmation, spend limits, rate limits, and audit logs. - Integrate with ongoing “AgentID” direction to avoid parallel systems. 2. **Provide “secure-by-default” templates** - Default configs that block on-chain transfers and shell execution unless explicitly enabled. **Similar projects** - Kubernetes RBAC + admission controllers; OAuth scopes; GitHub Actions permission model (“read-all” vs explicit write permissions). --- ## 4) Communication Gaps (expectations vs reality) ### A) “v2 is supported” vs “team is focused on v3” - Users integrating v2 are told docs exist but also that the team is “deep in v3 development,” implying v2 is effectively community-supported. **Fix** - Add a **Version Support Policy** page: what is maintained, what is frozen, where breaking changes happen. ### B) “Docs are the reference” vs “query the codebase with Cursor” - Suggesting Cursor/codebase search as the primary way to learn protocol details signals the docs are incomplete. **Fix** - Adopt a rule: for any public protocol, **docs must include enums/schemas** (code can be supplementary). ### C) Token expectations - Users ask for timelines; responses indicate no additional details. **Fix** - Publish explicit comms constraints: “No ETAs; next info drop at milestone X,” and a single canonical page to reference. ### D) Project discovery (elizabao_ai) - Name is circulating; users ask what it does. **Fix** - Provide a one-page “What is elizabao_ai” with: status, target users, what exists today, how to try, and what’s next. --- ## 5) Community Engagement Insights ### Power users / high-signal contributors and their needs - **shah0406**: integration-heavy builder; needs protocol specs, DM APIs, stable SDKs. - **odilitime**: central helper and core dev presence; bandwidth constrained; needs scalable support mechanisms (docs, templates, community triage). - **NubsCarson** (GitHub): focuses on connector/runtime correctness; needs clear test harnesses and reproducible bug reports. ### Common newcomer questions indicating onboarding friction - Wallet verification help (Collab.land) - “What is elizabao_ai?” - Basic platform misconceptions (e.g., chain exclusivity—multichain had to be clarified) ### Converting passive users into contributors 1. Create “Docs bounties” for protocol pages (Socket.IO spec, DM flow, troubleshooting guides). 2. Add a “Good first issue: Documentation parity” label and a template for capturing: observed behavior → expected → code pointers. 3. Recognize integrators (dashboard/client builders) as a “Connector Working Group” with a dedicated channel and maintainer office hours. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** captures real-time confusion but issues often remain unresolved or get buried (e.g., Collab.land verification). - **GitHub** captures actionable technical issues well (e.g., bun/macOS failure), but many user problems never convert into issues (e.g., Socket.IO protocol gaps are discussed but not systematically tracked as doc tasks). ### Improvements for more structured, actionable feedback 1. **Add Discord → GitHub escalation workflow** - A bot command like `/raise-issue` that creates a prefilled GitHub issue with chat transcript + tags (Docs/Integration/Support). 2. **Weekly “Top Questions” digest from Discord** - Publish the top 5 repeated questions and link to canonical answers (or create missing pages). 3. **Add integration survey for client builders** - Short form: transport (Socket.IO/HTTP), auth method, required APIs (DM, rooms), blockers. ### Underrepresented user segments - Non-core developers attempting first install/run (only one macOS onboarding issue surfaced here, but it’s severe). - Operators deploying agents (hosting, monitoring, reliability)—Hatcher.host interest suggests a growing segment, but their needs aren’t systematically captured. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Publish canonical ElizaOS v2 Socket.IO protocol docs** (enums + payload schemas + auth + examples) and link it prominently from docs.elizaos.ai. 2. **Implement or document programmatic DM/channel creation flow** (reference sequence + API/events), targeting dashboard/client builders. 3. **Fix `elizaos create` macOS bun failure and stop deleting scaffolded projects on error** (packaging + CLI UX hardening). 4. **Create a single “Token Utility / Airdrops / Buybacks / Fees” canonical status page** with a clear update cadence and explicit “no ETA” policy. 5. **Add a structured support path for wallet verification (Collab.land)** (pinned troubleshooting + ticket workflow), reducing unresolved public threads.