## User Feedback Analysis — 2026-04-22 (based on 2026-04-19 to 2026-04-21 community + repo signals) ### Data notes / sample size - Primary signals: Discord daily logs (Apr 19–21) + surfaced GitHub activity context (plugin registry PR #346 CI failure; LifeOps/auth changes referenced in daily summary). - In the 3-day Discord sample there were ~11 distinct user-facing “feedback events” (questions, incidents, or support requests). Percentages below are relative to this small sample and should be treated as directional, not statistically representative. --- ## 1) Pain Point Categorization (Top 6) ### 1) Community — Scam/phishing pressure + unsafe support pathways (High severity, high frequency) **Observed frequency:** ~4/11 events (~36%) explicitly mention scams/phishing or scam warnings (arena phishing “airdrop” links; discussion channel scam warnings; fraudulent support ticket scam after token migration). **What’s happening (examples):** - Phishing in arena channel with “airdrop” tags; moderators stated “airdrop tags in Discord are always scams.” - A user (nelsonlopes_) reported being scammed via a fraudulent support ticket after failing to migrate tokens, compounding losses. - Multiple community members posted active scam warnings in general discussion. **Who it impacts most:** newcomers and token holders seeking support; anyone asking “Is there a ticket here?” (unanswered). --- ### 2) Documentation — Confusing “how to build/run examples” and discover the right starting point (Medium severity, recurring) **Observed frequency:** ~1–2/11 events (~9–18%) directly, plus indirect signals (unanswered “ticket” question suggests unclear support docs). **What’s happening (examples):** - User asked for guidance on building examples from docs; redirected to GitHub examples directory (`eliza/tree/v2.0.0/examples`). - Several “general questions” in discussion received no response (e.g., ticket/support), suggesting documentation isn’t answering common onboarding needs. **Who it impacts most:** developers evaluating ElizaOS via docs, first-time builders. --- ### 3) Technical Functionality — CI/CD workflow and permissions issues blocking plugin ecosystem contributions (High severity, moderate frequency) **Observed frequency:** ~1/11 events (~9%), but high impact due to blocking merges. **What’s happening (examples):** - Plugin registry PR #346 failing because `claude-code-action` can’t fetch OIDC token: missing `id-token: write` permission or `github_token` configuration. Reported as repo config, not code. **Who it impacts most:** plugin authors / maintainers, especially external contributors who cannot fix repo settings. --- ### 4) Integration — Provider/plugin gaps and requests (Medium severity, moderate frequency) **Observed frequency:** ~2/11 events (~18%). **What’s happening (examples):** - Request for “minimax token plan key integration as a provider plugin” remained unresolved. - Strong interest in third-party marketplaces / paid-agent workflows (e.g., Elisym integration plugin enabling paid jobs via Nostr + SOL payments). **Who it impacts most:** builders trying to deploy agents with specific model providers or monetize agent capabilities. --- ### 5) UX/UI — Authentication & wallet provider UX inconsistencies (Medium severity, moderate frequency; largely inferred from dev logs) **Observed frequency:** Not directly complained about by users in the Discord snippet, but addressed in the daily dev summary (a “latent” pain point). **What’s happening (examples from development notes):** - Wallet + GitHub unified authentication; server-side token refresh added to fix silent logout. - UI styling/text wrapping issues for EVM/Solana wallet providers being fixed. **Who it impacts most:** users onboarding via wallet auth; anyone switching between GitHub and wallet login paths. --- ### 6) Communication Gaps (Product/Token/Legal) — Expectations vs reality around tokens, staking, migration windows, and product relationships (High severity, high frequency) **Observed frequency:** ~4/11 events (~36%). **What’s happening (examples):** - Multiple users asked about staking; moderators confirmed it’s not available. - Token migration window closure caused direct loss exposure; user could not migrate $700–900 and then got scammed seeking help. - Confusion about ElizaOK vs elizacloud vs token: “ElizaOK is built with elizacloud and has no separate token; all users flow into elizacloud.” - Lawsuit discussion created uncertainty; team said they will respond via lawyers and have code documentation proving delivery. **Who it impacts most:** token holders, newcomers, and anyone evaluating project legitimacy/trajectory. --- ## 2) Usage Pattern Analysis (Actual vs intended use) ### How users are actually using ElizaOS (from this sample) 1. **Agents as revenue-generating services** (emerging “agent-as-a-business” pattern) - Elisym plugin: capability cards (NIP-89), encrypted job requests (NIP-90), on-chain settlement (SOL). Users are actively building for paid-provider workflows. - v3 teased as enabling agents to “generate revenue,” reinforcing that monetization is a top-of-mind usage goal. 2. **Security operations inside community + agent ecosystem** - Users discuss building plugins to detect/handle scammers (“plugin for scammers”). - Discord is functioning as a high-risk support channel; users seek “tickets,” making it a target for impersonation. 3. **LifeOps / personal operations automation (calendar, travel, cross-platform messaging)** - Development focus suggests growing real-world orchestration use cases beyond chatbots—calendar management, travel booking, cross-platform gateways. ### Mismatch vs intended positioning - ElizaOS is presented as an agent framework, but a significant slice of “daily urgency” is **token ops + scam avoidance** rather than building agents. - Users increasingly expect **official support workflows** (tickets, migration help) inside Discord, which the current community structure does not safely provide. ### Feature requests aligned with real usage - **Provider plugin requests** (e.g., minimax integration) align with real-world deployment needs. - **Monetization primitives** (capability discovery, job encryption, payments, receipts) align with marketplace and paid-task workflows (Elisym, x402 APIs, etc.). --- ## 3) Implementation Opportunities (2–3 per major pain point, prioritized) ### A) Scam/phishing + unsafe support pathways **High impact / Medium difficulty** 1. **Replace “informal support” with a hardened, verifiable support flow** - Publish a single official support entry point (website form or GitHub Discussions category) and explicitly state “No Discord tickets.” - Add Discord auto-responder for keywords (“ticket”, “support”, “migration”) pointing to the official flow and warning about scams. - Similar approach: many crypto + OSS projects (e.g., Ethereum clients, major wallets) pin “Support = website only” and auto-moderate support DMs. **High impact / Low–Medium difficulty** 2. **Discord hardening pack** - Ban/disable “airdrop” tag patterns via AutoMod + regex; throttle new accounts; restrict link posting in high-traffic channels. - Add a `/report-scam` command that pings moderators with message link + user ID. - Similar approach: large Discord communities (gaming + crypto) use AutoMod keyword blocks + new-user link restrictions. **Medium impact / Medium difficulty** 3. **“Safety plugin” guidance for agent operators** - Provide an “Operator Safety Checklist” doc: never paste keys, never accept “support tickets,” verify domains, etc. - Optionally ship a small “anti-impersonation” helper bot that posts verified staff list and warns on lookalike names. --- ### B) Documentation gaps (examples, onboarding, “where do I start?”) **High impact / Low difficulty** 1. **Docs quickstart that mirrors how people actually start** - A single “Build your first agent in 10 minutes” path that links directly to `examples/` and includes exact commands + expected output. - Include troubleshooting for bun/node versions and common build failures. **High impact / Medium difficulty** 2. **“Which product is this?” docs page (ElizaOS vs elizacloud vs ElizaOK)** - Add a canonical diagram + FAQ: what is open source, what is cloud, what has tokens, what does not. - Put this in README + Discord pinned post. **Medium impact / Low difficulty** 3. **Convert repeated Discord questions into docs via automation** - Weekly digest: top 5 repeated questions -> open docs PR with answers. - Similar approach: Kubernetes/Next.js communities formalize FAQ from community channels into docs. --- ### C) CI/CD workflow and permission blockers (plugin registry) **High impact / Low difficulty** 1. **Fix the immediate registry CI permissions** - Update workflow to include `permissions: id-token: write` (and ensure correct `github_token` usage) for `claude-code-action` on PRs (PR #346). - Add a CI preflight job that fails with a clear message if permissions are insufficient (so contributors don’t debug blindly). **High impact / Medium difficulty** 2. **Introduce a “CI steward” role and playbook** - Document what maintainers must do when OIDC/permissions fail; add a rotation so issues are resolved quickly. - Similar approach: many OSS projects designate “Build Cop” ownership for CI health. **Medium impact / Medium difficulty** 3. **Local validation for registry submissions** - Provide a `registry validate` command (or script) that checks package metadata and reduces dependency on privileged CI steps for basic verification. --- ### D) Integration gaps (provider plugins, marketplaces, monetization rails) **High impact / Medium difficulty** 1. **Provider plugin SDK checklist + templates** - Standardize how to add providers (auth, keys, rate limits, error handling, redaction). - Provide a template repo for “model provider plugin” so minimax-like requests can be implemented by community faster. **Medium–High impact / Medium difficulty** 2. **Official “marketplace integration” interface** - Define a minimal capability schema + job/request protocol abstraction (Elisym/Nostr, x402, other markets). - Similar approach: LangChain tool schema conventions; OpenAI “function calling” shaped community plugin ecosystems via a stable interface. **Medium impact / Low difficulty** 3. **Curate and certify integrations** - A “Verified plugins” list in registry with security notes (tests, provenance, maintainers). Elisym plugin already emphasizes tests + provenance—use that as a model. --- ### E) Communication gaps (staking, migration, legal, product identity) **High impact / Low difficulty** 1. **Pin an “Expectation Setting” post across Discord channels** - Staking: not available (and if planned, state “no ETA”). - Migration: closed; no recovery path; list official warning and support channel. - Airdrops: always scams in Discord. **Medium impact / Medium difficulty** 2. **Status page + incident-style updates** - When major events happen (migration closing, legal filings), publish a short, linkable status note so Discord doesn’t become the canonical source. - Similar approach: incident posts used by infra projects to reduce rumor spread. --- ## 4) Communication Gaps (recurring expectation mismatches) ### Recurring questions indicating onboarding/support gaps - “Is there a ticket here?” → Users expect a ticketing/support system inside Discord; current reality: this is unsafe and not standardized. - “Is staking available?” → Token holders expect standard DeFi features; reality: none today. - “How do I build the examples?” → Docs not providing an immediately executable path. - “ElizaOK vs elizacloud vs token?” → Users conflate products and tokens; needs a canonical explanation. ### Suggested messaging improvements - Add a **Discord “Support & Safety” channel** (read-only) with: - Official links - “No DMs from staff” policy - How to verify staff - What to do if scammed (reporting checklist) - Add a **Product Map** page and link it from: - README - Docs homepage - Discord welcome message --- ## 5) Community Engagement Insights ### Power users observed (and their needs) - **odilitime (core dev/mod):** frequently doing high-stakes comms (legal, token migration clarification) and developer support. Needs: better tooling to avoid being the single point of failure (templated responses, pinned FAQs, support workflow). - **igor.peregudov (plugin author):** high-quality integration work; blocked by CI permissions. Needs: faster maintainer response on repo config + clear contributor path. - **stan0473 (core/community dev):** building anti-scam plugin ideas, helping route technical issues. Needs: a defined security/workflow lane to channel anti-scam contributions. ### Newcomer friction signals - Unanswered basic support question (“ticket”) suggests newcomers can’t find the right help entry point quickly. - Token-related questions attract newcomers who may not be builders, increasing moderation load and risk. ### Converting passive users into contributors - Create “Good First Plugin” bounties: provider plugin skeletons (e.g., minimax) with clear acceptance criteria. - Add a monthly “Plugin Demo Day” in Discord: 5-minute demos + a single thread for follow-up; reduces scattered support questions. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord:** fast, but high noise + high scam risk; questions get missed; not structured for product decisions. - **GitHub:** structured for engineering, but many user concerns (token ops, support) never become trackable issues. ### Improvements (structured, actionable) 1. **Introduce a single “Feedback Intake” form** (feature request / bug / docs / security / token ops), auto-routed to GitHub Issues/Discussions with labels. 2. **Weekly triage post**: top questions, answered with permalinks to docs; unanswered questions become tracked issues. 3. **Add lightweight telemetry of docs pain**: “Was this page enough to run the example?” (yes/no) + optional comment. ### Underrepresented segments (missing feedback) - **Non-crypto builders**: current discourse is token/scam heavy; we have little signal from teams using ElizaOS purely for agent automation. - **Enterprise / production operators**: limited direct feedback on deployment, uptime, cost controls—despite monetization ambitions. - **Non-Discord users**: need more GitHub Discussions and docs-based feedback capture. --- ## Prioritized High-Impact Actions (Next 2–4 weeks) 1. **Harden support + anti-scam posture in Discord** (AutoMod rules, official support entry point, keyword auto-responder, pinned “no tickets/no airdrops” policy). 2. **Unblock plugin registry contributions by fixing OIDC/permissions in CI** (PR #346 root cause) and document a maintainer playbook for CI permission failures. 3. **Publish a canonical “ElizaOS / elizacloud / ElizaOK / token” explainer + staking/migration FAQ** and pin it in Discord + link from README/docs. 4. **Ship a “Run the examples” docs path with copy-pastable commands and troubleshooting** (make `examples/` the primary onboarding route). 5. **Stand up structured feedback intake** (form → labeled GitHub issues/discussions) to reduce repeated Discord questions and capture underrepresented user needs.