## User Feedback Analysis — 2026-05-13 (based on activity through 2026-05-12) ### Data sources represented - **Discord (May 10–12, 2026):** plugin registry submission blockers, Discord security/scammer reports, requests to run sandboxed agents, operational cost discussion, token/branding concern. - **GitHub issues (late Apr–early May, 2026 snapshot):** several “fresh clone / first run” breakages and integration reliability bugs (auth detection, missing migration tables, duplicate Telegram pollers, missing dev preload file). Many were closed quickly, but they indicate recurring friction patterns. --- ## 1) Pain Point Categorization (Top recurring 5–7) > Quantification note: The dataset for this date is small and skewed toward a few high-signal threads. Percentages below are calculated over **~12 distinct feedback items** (Discord threads/questions + representative GitHub issue reports included in the provided data), so treat them as directional. ### 1) Integration — Plugin registry submission blocked (404 / unclear policy) **(High severity, high frequency)** - **~17% (2/12)** of feedback items explicitly report **v2 plugin registry returning 404** for both `elizaos-plugins/registry` and `plugins.elizacloud.ai`, blocking third‑party plugin submission (e.g., `plugin-undesirables@2.0.3`). - Secondary friction: **license constraints** (BUSL‑1.1) prevent PRs to the monorepo, making the registry the only path—currently broken. **Most affected users** - Plugin authors trying to publish to the ecosystem; any plugin with licensing restrictions that cannot be upstreamed. --- ### 2) Community / Security — Scammers + “compromised admin accounts” confusion **(High severity, medium frequency)** - **~17% (2/12)** of feedback items flag **suspicious activity/scammers** and claims of **compromised admin accounts** in Discord. - A core response clarified “project has no admins,” which itself indicates **role/permissions ambiguity** for users. **Most affected users** - Newcomers assessing project legitimacy; contributors hesitant to click links/install binaries; moderators and maintainers dealing with trust erosion. --- ### 3) Documentation / Community — Unclear process for running/testing agents in Discord (OAuth/whitelist) **(Medium severity, medium frequency)** - **~8% (1/12)** requests a clear procedure to test a **sandboxed multi-agent orchestrator** in the official Discord (read-only, @mention-only, no DMs). - The request implies missing “how to safely test bots/agents in community spaces” guidance (OAuth invite, permission model, required safeguards). **Most affected users** - Builders trying to demo or validate integrations; community ops needing consistent guardrails. --- ### 4) Technical Functionality — “Fresh install / fresh clone” breakages in core flows (auth, migrations, dev scripts) **(High severity, medium frequency)** From the provided GitHub issues snapshot (all high-impact when they occur): - **Auth detection drift:** Codex CLI auth file format changed; UI reports “install required” incorrectly (issue #7243). - **Runtime DB missing tables:** plugin-sql runtime migrator missing definitions for tables used by relationship/memory providers, causing cascaded prompt composition failures (#7222). - **Dev tooling mismatch:** missing `claude-code-stealth.mjs` preload prevents Anthropic subscription OAuth path from working (#7210). Even when quickly fixed, the pattern is consistent: **first-run experience can fail silently**, then surface as confusing downstream errors (“parsing error”, “no structured output”). **Most affected users** - New self-hosters, template users, and contributors pulling `develop`/alpha branches. --- ### 5) Integration / Reliability — Messaging connectors can lose messages silently (Telegram; Slack risk flagged in PR review) **(High severity, lower frequency in this slice)** - Telegram: two concurrent pollers (wrapper + plugin) cause **race-driven silent message loss** (#7245). - Slack: review notes missing try/catch on `users.info` could drop messages on API errors (from PR analysis in #7375). **Most affected users** - Bot operators using Telegram/Slack connectors; anyone evaluating the framework via “does the bot reliably reply?” --- ### 6) Community / Communication — Token/project status uncertainty goes unanswered **(Medium severity, low frequency)** - **~8% (1/12)** raised concerns about **token support** and perceived branding signals (“removed from X bio”), with **no community response** recorded. **Most affected users** - Community members looking for roadmap clarity; potential contributors who interpret silence as risk. --- ### 7) Performance / Cost Understanding — Confusion about operational costs and cost drivers **(Low–medium severity, low frequency)** - **~8% (1/12)** discussion on Twitter bot costs indicates users are actively operating agents and care about cost tuning (replies volume as main driver). **Most affected users** - Builders deploying social agents at scale; anyone deciding between self-hosting vs cloud. --- ## 2) Usage Pattern Analysis (Actual vs intended) ### Observed “actual usage” 1. **Ecosystem-first behavior:** Users are building and trying to ship **third-party plugins** (including non-monorepo-compatible licenses). This implies the plugin registry is not optional; it’s critical infrastructure. 2. **Community-as-testbed:** Builders want to test **agents inside the official Discord** with constrained permissions (sandbox channels, @mention-only). Discord is functioning as a quasi-staging environment. 3. **Connector-driven adoption:** Telegram/Twitter/Slack appear as “first proof” surfaces; reliability (no silent drops) is a primary success metric. 4. **Multi-agent orchestration emerging:** Interest in A2A/MCP-enabled research agents suggests users are pushing beyond single-agent chat into **tool-using orchestrators**. ### Emerging / unexpected use cases - **MCP + A2A research agents** being run in shared community spaces with strict permissioning requirements. - **Cost-optimized social bots** (Twitter) where reply volume and behavior configuration are treated as product levers. ### Feature requests aligned with usage patterns - A reliable, well-documented **plugin publishing pipeline** (registry + validation + discoverability). - A documented **“Community bot/agent sandbox” program** (OAuth, permissions, rate limits, safety checks). - Connector reliability guarantees: “exactly-once polling owner” patterns and connector health checks. --- ## 3) Implementation Opportunities (Solutions per major pain point) ### Pain Point A: v2 plugin registry 404 + submission policy ambiguity (Integration) **High impact / Low–medium difficulty** 1. **Add a “registry status & fallback” mechanism** - Publish a single source of truth page (e.g., `status.elizaos.ai/plugins-registry`) and pin it in Discord. - If registry is down/private, provide an **official fallback path** (e.g., “open an issue with metadata attached” or “PR to staging registry repo”). - Similar approach: Kubernetes/Helm charts often publish status + fallback install methods when registries are degraded. **High impact / Medium difficulty** 2. **Make registry submission self-validating + transparent** - Add CI checks that validate plugin JSON metadata and repo visibility; return explicit errors rather than 404 confusion. - Provide a `eliza plugin publish --dry-run` that validates metadata locally and prints the target endpoints. - Similar approach: Homebrew and VS Code Marketplace both provide local packaging/validation steps before publish. **Medium impact / Medium difficulty** 3. **Support license-aware submission paths** - Formalize “monorepo PR” vs “external registry entry” tracks, explicitly covering BUSL‑1.1 and other licenses. - Provide template language: what is allowed where, and why. --- ### Pain Point B: Discord scammers / permission ambiguity (Community) **High impact / Medium difficulty** 1. **Harden server security posture** - Enforce 2FA for privileged roles, reduce role sprawl, audit integrations, and rotate compromised tokens. - Add an automated anti-scam bot and link filter rules for new accounts. - Similar approach: Rust and Python Discord communities use staged permissions + anti-phishing bots with quarantine roles. **High impact / Low difficulty** 2. **Clarify governance + roles publicly** - A short “Who are maintainers/mods?” doc and a pinned Discord message: “No admins; here’s how to verify staff; here’s where official links live.” - Add an `/official-links` command to reduce phishing success. **Medium impact / Low difficulty** 3. **Incident playbook** - A lightweight runbook for moderators: how to respond to compromised accounts, scam waves, and user reports. --- ### Pain Point C: Unclear process for testing agents in Discord (Documentation / Community) **High impact / Low difficulty** 1. **Create a “Bot/Agent Sandbox Policy”** - Required constraints checklist: no DMs, respond only on mention, rate limits, logging, data retention, code-of-conduct compliance. - Define OAuth invite/whitelist steps and who approves. **Medium impact / Medium difficulty** 2. **Provide a standard “sandbox bot” template** - A reference implementation that demonstrates the permission model and safe defaults. **Medium impact / Medium difficulty** 3. **Separate test environment** - A dedicated “elizaOS-labs” Discord or a private staging guild for vetted demos. --- ### Pain Point D: First-run failures due to drift between code, auth formats, migrations, dev scripts (Technical Functionality) **High impact / Medium difficulty** 1. **Introduce “first-run contract tests”** - CI job that boots a fresh template install with PGLite and runs a minimal chat turn + connector initialization. - Catch missing tables, missing preload files, and auth-detection mismatches before merge. - Similar approach: Next.js and Supabase templates commonly run “create project → run dev → smoke request” CI. **High impact / Low–medium difficulty** 2. **Fail loud on missing critical components** - For dev scripts: if a stealth/preload feature is enabled but file missing, log a **blocking warning** with remediation. - For migrations: assert required tables exist at runtime init; if not, print “schema drift” guidance. **Medium impact / Medium difficulty** 3. **Versioned parsers for external auth files** - Codex/Anthropic/other credential importers should accept multiple known shapes with clear logging of which one matched. --- ### Pain Point E: Silent message loss in connectors (Integration / Reliability) **High impact / Medium difficulty** 1. **Single-owner enforcement for polling** - At runtime, detect duplicate pollers for the same token and hard-disable one with an explicit log. - Similar approach: many Telegram bots avoid dual `getUpdates` by locking via a single process or switching to webhooks. **High impact / Medium difficulty** 2. **Connector health + delivery metrics** - Expose “received updates / processed / replied” counters and alert when drops occur. - Add “connector self-test” action that sends a ping and confirms round-trip. **Medium impact / Low difficulty** 3. **Guard critical API calls** - For Slack: wrap user lookup calls in try/catch and continue with degraded metadata rather than dropping the entire event. --- ### Pain Point F: Token/project status uncertainty and unanswered questions (Community / Communication) **Medium impact / Low difficulty** 1. **Add a “Project status & roadmap” pinned FAQ** - What is supported today, what’s experimental, and how token/branding relates (or doesn’t) to core maintenance. 2. **Triage & response SLA for sensitive questions** - Even a short acknowledgment reduces rumor amplification. --- ## 4) Communication Gaps (Expectations vs reality) 1. **Plugin registry expectations** - Expectation: “There is a public, working registry and a stable submission process.” - Reality: endpoints/repo return 404 and policy may change (registry vs monorepo PR). - Improvement: publish registry state, intended timeline (beta), and official fallback immediately. 2. **Discord authority model** - Users assume “admins exist,” then see claims of compromised admin accounts. - Maintainers state “no admins,” which conflicts with typical Discord mental models. - Improvement: clearly list roles, responsibilities, and verification methods. 3. **Onboarding and first-run reliability** - Expectation: fresh clone + `bun run dev` “just works.” - Reality (from issues): subtle drift causes cascading failures that look like model/parser problems. - Improvement: first-run smoke tests + clearer boot-time diagnostics. 4. **How to run bots/agents safely in community spaces** - Recurring questions imply missing docs: OAuth invite/whitelist, what permissions are allowed, and how to avoid spam/privacy issues. --- ## 5) Community Engagement Insights ### Power users surfaced (and what they need) - **odilitime (core dev/community ops):** currently acting as the routing point for registry investigation and OAuth setup. Needs tooling and documented processes to reduce “human bottleneck” support load. - **thegreatluna8713 / sailorpepe.eth (plugin publisher):** needs a reliable registry pipeline and licensing-aware guidance. - **rma_bot (multi-agent orchestrator builder):** needs a standardized sandbox/testing program and clear approval steps. - **Sw4pIO (high-signal issue reporter in GitHub snapshot):** represents “sharp edge finder” for first-run and integration bugs; would benefit from an official “integration test” harness and contributor guidance to turn reports into PRs faster. ### Newcomer friction signals - Multiple introductions with little follow-up suggests newcomers may not know: - where to start building, - which tasks are needed, - how to get feedback on early work. ### Converting passive users into contributors - Create “good first plugin publish” and “connector reliability” task boards. - Add a “Plugin publishing office hours” weekly thread. - Provide a pre-made GitHub issue template for: registry submission, connector drops, auth detection, first-run failures. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord:** fast, but unstructured; key issues (token concern, security question) can go unanswered or get buried. - **GitHub issues:** high-quality for technical bugs, but not capturing many UX/process concerns unless they break builds. ### Improvements (more structured + actionable) 1. **Single intake form for operational blockers** - A GitHub Discussion category or form: “Publishing/Registry,” “Connector Reliability,” “Security/Abuse,” “Onboarding/Docs.” 2. **Add lightweight tagging + metrics** - Track: time-to-first-response, time-to-resolution, and “blocker” flags (e.g., registry down). 3. **In-app / CLI feedback command** - `eliza doctor` collects environment + validates registry reachability + outputs a shareable report (redacting secrets). ### Underrepresented segments - **Non-Discord users / quieter self-hosters** (only visible when they file GitHub issues). - **Plugin authors with restrictive licenses** (explicitly impacted now). - **Operators focused on cost/performance tuning** (Twitter bot cost discussion hints at this, but it’s not systematically captured). --- ## Prioritized High-Impact Actions (next 1–2 weeks) 1. **Restore or provide an immediate fallback for plugin publishing** (registry status page + documented alternative submission path), explicitly covering BUSL‑1.1 constraints. 2. **Ship a Discord security hardening + trust clarification package** (2FA enforcement for privileged roles, pinned “official links / staff verification,” incident playbook). 3. **Publish a “Discord Agent Sandbox Program”** (approval steps, OAuth/whitelist procedure, required safety constraints) to standardize community-based testing. 4. **Add first-run smoke tests in CI for templates and core runtime** (fresh boot, minimal chat, PGLite migrations, basic connector init) and improve fail-loud diagnostics for missing critical components. 5. **Connector reliability guardrails**: enforce single polling owner per token (Telegram) and add basic delivery/health counters to detect silent drops early.