## User Feedback — 2026-02-09 (based on Feb 6–8 sources) ### Data snapshot used - Sources: Discord (💬-coders, core-devs, 💬-discussion), plus referenced GitHub issues/PR summaries visible in the dataset. - Volume (this snapshot): ~14 identifiable feedback reporters + several replies from core contributors (e.g., Stan ⚡, Bill Ding, Odilitime, tcm390). - Note: Percentages below are computed from **distinct feedback threads/themes observed in this snapshot (n=12)** to keep the quantification honest given limited raw message counts. --- ## 1) Pain Point Categorization (top recurring 7) ### 1) **Technical Functionality — Plugin compatibility + breaking changes (25% of themes; high severity)** **What users hit** - Missing `MAX_EMBEDDING_TOKENS` constant in latest AI provider plugin versions, causing plugin loading/integration failures (Wes; acknowledged by s). - “Wallet fixes resolved locally but not yet deployed” → users blocked waiting on releases (s). - Unclear direction: “rollback vs PR across all plugin repos” (Wes; unanswered). **Who it impacts most** - Anyone integrating milaidy/openclaw connectors as plugins; developers trying to stay on latest versions. --- ### 2) **UX/UI — Character customization is brittle/hidden (17% of themes; high severity)** **What users hit** - Agent defaulting to “eliza” personality instead of custom character (azsxdc). - Character creation currently limited to onboarding only; unclear file placement/loading workflow (Bill Ding confirmed limitation). - Model selection mismatch: `claude-haiku-3.5` used despite config specifying otherwise (azsxdc). **Who it impacts most** - Builders trying to ship branded agents (Twitter bots, game NPCs, consumer agents) where persona consistency is core UX. --- ### 3) **Performance — Postgres “logs table” bottleneck (8% of themes; very high severity)** **What users hit** - Excessive writes/reads to `logs` table slow Postgres → slower Eliza response times (sayonara). - Team confirmed a “major optimization plan” is in progress (Stan ⚡). **Who it impacts most** - Hosted/cloud or any production deployment with sustained traffic; impacts perceived reliability directly. --- ### 4) **Integration — Twitter plugin functional gaps (8% of themes; medium severity)** **What users hit** - Quote repost does not render as native quote tweet; posts text + link only (azsxdc). - “No idea, make an issue/PR” response indicates missing ownership/triage for key integration (Bill Ding). **Who it impacts most** - Users using ElizaOS for social automation/marketing agents; undermines credibility of “works with Twitter” claims. --- ### 5) **UX/UI + Technical Functionality — ElizaCloud account/login failures (17% of themes; high severity)** **What users hit** - Duplicate accounts created when claiming $5 welcome credit because email link routes to **dev.elizacloud.ai** instead of prod (yojo). - Credit mismatch ($5 promised → $1 received), and agent fragmentation across accounts (yojo). - Dashboard “cycling” between login and dashboard (user ∙∙·▫▫ᴼⒻⓄⓍⓏⓎᴼ▫▫·∙∙; forwarded to cloud team). **Who it impacts most** - New users evaluating the product; this is a first-session conversion killer. --- ### 6) **Documentation — Deployment + environment expectations are unclear (8% of themes; medium severity)** **What users ask repeatedly** - “Do we need to run both Eliza and milaidy for examples / full functionality?” (azsxdc; unanswered) - “VPS vs local? Has anyone deployed milaidy on a VPS?” (azsxdc; unanswered) - “What is cluster mode?” in the context of PM2 proposal (unanswered) **Who it impacts most** - New builders attempting production-like setups; leads to Discord support load and stalled adoption. --- ### 7) **Community — Token/product communication + moderation trust issues (17% of themes; very high severity)** **What users hit** - Repeated questions: token use-case, staking (confirmed unavailable), “5 promised products” status, whether marketing exists, “why buy elizaos” (averma, gby, mbat; mostly unanswered). - Community sentiment deterioration tied to price drop and exchange delistings; reports of muting/banning for criticism (from daily summary). **Who it impacts most** - Token holders and prospective adopters evaluating project legitimacy; spills into developer trust and contributor retention. --- ## 2) Usage Pattern Analysis (actual vs intended) ### Observed “actual use” 1. **Developer-first agent building + plugin ecosystem composition** Users are actively assembling agents from many plugins/connectors (milaidy/openclaw connectors as Eliza plugins). This increases sensitivity to version skew and missing constants. 2. **Persona-driven consumer agents** (Twitter bots, branded characters, “Eliza vs custom character”) The character system is being treated as a *product surface*, not a dev detail. 3. **Game/NPC integration** - SpacetimeDB integration into a game backend reported as “surprisingly quick” (metalhorse233). - Babylon game: users spin up agents, trade in terminal, explore feed (puncar). 4. **Educational use / simplified packaging demand** - ElBru wants to use milaidy setup as a homeschool project for a 10-year-old → strong signal that “one-click / minimal-bloat app” is a real adoption wedge. 5. **Hosted/managed deployments** - BuildAMolt offers 2-minute VPS setup for Moltbots, indicating user pull toward “hosted agent stacks” vs local-only tinkering. ### Misalignment with intended/communicated usage - If ElizaCloud is positioned as an onboarding funnel, the **dev/prod link bug + login loop** breaks the intended activation path. - If “plugins make it modular,” users still expect **compatibility guarantees** across core + official plugins (e.g., `MAX_EMBEDDING_TOKENS`). ### Feature requests aligned with real usage - Character editor (already in progress) aligns strongly with persona-driven usage. - Better deployment/process management patterns (PM2 suggestion) aligns with real “run it like a service” usage. --- ## 3) Implementation Opportunities (2–3 concrete solutions per major pain point) ### A) Plugin compatibility breakages (`MAX_EMBEDDING_TOKENS`, wallet fixes not released) **High impact / medium effort** 1. **Introduce a plugin “compat layer” and deprecation policy** - Add a small core shim exporting required constants (e.g., `MAX_EMBEDDING_TOKENS`) and mark plugin-side definitions optional. - Publish a compatibility matrix: `core version ↔ plugin versions`. - Similar approach: **Kubernetes API deprecations** + version skew policy; **VSCode extension engine compatibility**. 2. **Monorepo-level CI for cross-plugin contract tests** - A nightly workflow that installs latest core + latest official plugins and runs a boot test. - Failures auto-open issues in the offending plugin repo with stack traces. - Similar: **Next.js canary tests** across example apps; **LangChain integration tests** for providers. 3. **Release discipline for “fixed locally”** - Require that fixes referenced in Discord (e.g., wallet fixes) have a tracking issue + target release tag. - Automate “changeset → publish” for official plugins. --- ### B) Character customization + model selection mismatches **High impact / medium effort** 1. **Ship the character editor with a deterministic load order + validation** - Explicit precedence: CLI arg > env > project config > onboarding default. - Add a startup log line: “Loaded character: X from path Y; model: Z from config source Q”. - Similar: **Docker compose config resolution** + `docker compose config` output. 2. **Add a `elizaos doctor` command** - Checks: character file path, JSON schema validity, model config, plugin versions, env overrides. - Outputs actionable fixes (“Model overridden by ENV MODEL_PROVIDER=…”). 3. **Make “character as a first-class artifact”** - Support `characters/` directory convention + hot reload in dev. - Provide 2–3 canonical examples: Twitter persona, game NPC, customer support agent. --- ### C) Postgres logs table performance bottleneck **Very high impact / medium-to-high effort** 1. **Separate operational logs from conversational memory** - Route logs to append-only store (e.g., ClickHouse/Elastic) or at minimum a separate partitioned table. - Keep Postgres focused on transactional state/memory. - Similar: **Sentry** / **OpenTelemetry** patterns; **Supabase** recommends separating analytics from OLTP. 2. **Partition + index strategy + write throttling** - Partition logs by day/week; index only what’s queried. - Add sampling / rate limits for verbose logs in production. - Add retention policy and background vacuum tuning. 3. **Async/batched logging** - Buffer log writes and flush asynchronously; reduce per-message DB hits. --- ### D) ElizaCloud account duplication + login loop **High impact / low-to-medium effort** 1. **Fix email link routing and enforce canonical domain** - Ensure all auth/claim links are generated with prod base URL. - Add server-side redirect from `dev.elizacloud.ai` links to prod with a signed token. 2. **Account merge + idempotent credit claim** - Credit claim should be idempotent by email identity. - Provide a self-serve “merge accounts” flow or support tool. 3. **Add client-side auth state diagnostics** - On login loop, expose a “Copy diagnostics” button: env, auth provider, token expiry, last error. --- ### E) Twitter quote repost limitation **Medium impact / low-to-medium effort** 1. **Implement native quote-tweet endpoint support** - Ensure plugin uses correct API endpoint/parameters for quote tweets, not a workaround post. 2. **Add integration test that asserts native quote formatting** - A mocked Twitter API test verifying payload shape. 3. **Ownership + triage** - Label in GitHub: `integration:twitter`, define maintainer rotation, and document supported/unsupported actions. --- ### F) Token/product communication breakdown (community trust) **Very high impact / medium effort (mostly process)** 1. **Publish a single “Reality vs Roadmap” page updated weekly** - Include: what shipped, what slipped, why, next ETA window. - Pin it in Discord + link in README. 2. **Define the token scope explicitly** - If token utility is not imminent, say so; if planned, list concrete, verifiable milestones (e.g., escrow rentals usage, fee discounts, marketplace requirements). 3. **Moderation policy transparency** - Publish moderation guidelines and an appeal path to reduce “muted/banned for criticism” narratives. --- ## 4) Communication Gaps (expectations vs reality) ### Recurring expectation mismatches - **“Modular plugins” vs “plugins break on latest”**: Users expect official plugins to stay compatible; missing constants undermines confidence. - **“Custom characters” vs onboarding-only limitation**: Users expect file-based or UI-based character management; current behavior defaults to Eliza with little explanation. - **“ElizaCloud onboarding credit” vs actual experience**: $5 promise but account duplication + $1 credit reality creates immediate distrust. - **“Twitter works” vs partial support**: Posting works but quote reposts aren’t native; needs clearer capability statement. ### Documentation/onboarding questions that keep reappearing - Where to put character files / how to ensure they load. - VPS deployment guidance for milaidy/Eliza. - PM2/cluster mode explanation for production ops. **Specific improvements** - Add a “Known limitations” section per plugin (Twitter: quote tweets status). - Add “Production deployment recipes”: local dev, single VPS, and managed cloud. - Add a “Config precedence” doc (env vs config vs onboarding). --- ## 5) Community Engagement Insights ### Power users / high-leverage contributors (and what they need) - **Wes**: shipping PRs fast; blocked by unclear contribution workflow + compatibility direction. Needs: CONTRIBUTING, maintainer review SLAs, clear “yes, submit PRs across repos” guidance. - **metalhorse233**: successful game integration; needs: a documented guide + example repo to amplify and attract game devs. - **MochinoLabs**: proposing ops architecture (PM2, symlinked dirs). Needs: an “Ops RFC” process and maintainers to evaluate proposals quickly. - **yojo**: provided detailed repro steps for cloud account bug. Needs: fast support resolution + public postmortem once fixed. - **tcm390 / ziflie**: tight feedback loop (bug found → fixed → confirmed). This is the model to replicate. ### Newcomer friction signals - Basic setup/deploy questions unanswered (VPS, examples compatibility, cluster mode). - Users hesitate to contribute more PRs without process clarity (Wes explicitly paused). ### Converting passive users into contributors - Create “Good first issue: plugins” list (Twitter quote-tweet, character load order). - Add a weekly “Bug bash hour” with a pinned form + live triage (Babylon already has a green feedback button—extend this pattern). - Reward testers (already mentioned) but make it concrete: badges, release credits, small bounties. --- ## 6) Feedback Collection Improvements ### Effectiveness of current channels - **Discord**: great for rapid discovery, but many questions remain unanswered and decisions (“rollback vs PR”) aren’t captured as durable guidance. - **GitHub**: good for concrete bugs/PRs, but not consistently linked from Discord (e.g., Twitter limitation response was “make an issue” rather than “here is issue #…”). - **In-product feedback (Babylon green button)**: promising—direct and contextual; resulted in a fast fix cycle. ### Improvements for structured, actionable feedback 1. **Add a “Report a bug” command in Discord that opens a prefilled GitHub issue** - Auto-captures: version, plugins enabled, OS, logs snippet. 2. **Weekly triage digest** - “Top 5 issues, status, owner, ETA window” posted to Discord and GitHub Discussions. 3. **Standardize feedback taxonomy** - Tags: `cloud-auth`, `character-system`, `plugin-compat`, `performance-db`, `integration-twitter`. ### Underrepresented segments missing from feedback - Non-crypto builders using ElizaOS purely for apps (only a few signals: games/education). - Less-technical users (education angle suggests demand, but their pain points aren’t fully captured because setup is still developer-heavy). - Enterprise/security reviewers (DigitalDiva raised “malicious code in skills” concern, but details and follow-up path weren’t surfaced publicly). --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Fix ElizaCloud onboarding breakages (dev→prod links, account merge, idempotent $5 credit)** *Impact:* immediate conversion + trust; *Difficulty:* low-to-medium. 2. **Stabilize plugin ecosystem with compatibility guarantees (contract tests + compatibility matrix + `MAX_EMBEDDING_TOKENS` shim)** *Impact:* unblocks milaidy + broader plugin adoption; *Difficulty:* medium. 3. **Ship character editor + config precedence + “doctor” diagnostics (character/model mismatch transparency)** *Impact:* improves persona reliability across Twitter/game/consumer agents; *Difficulty:* medium. 4. **Execute the Postgres logs table optimization plan with clear milestones (partitioning/async logging/retention)** *Impact:* platform-wide latency and reliability; *Difficulty:* medium-to-high. 5. **Publish a weekly “Roadmap reality check” (products/token utility status) + moderation policy** *Impact:* reduces community volatility and repeated unanswered questions; *Difficulty:* medium (process + comms).