## User Feedback Analysis — 2025-12-16 (from Discord Dec 13–15 + GitHub activity through Dec) ### Data notes (for quantification) Across the provided Discord digests (Dec 13–15), there were **10 “Key Questions”** captured. Of these: - **5/10 (50%)** were about **token migration and related security/visibility concerns** - **4/10 (40%)** were about **setup/onboarding and “which version / where do I configure X”** questions - **1/10 (10%)** was about **infra/hosting choice** GitHub signals (Dec month-to-date snapshot) reinforce the same themes: docs location confusion (#6122), provider compatibility questions (e.g., DeepSeek API #6156, OpenAI-compatible API #6168 in weekly summary), and setup ergonomics (.eliza autogeneration #6204, plugin-sql dir creation fixes). --- ## 1) Pain Point Categorization (Top recurring friction areas) ### 1) Technical Functionality — **Token migration reliability & “visibility” problems** (High severity, high frequency) **What users are experiencing** - Delays and uncertainty when tokens are held on exchanges (notably **Bithumb**): users perceive ElizaOS as “responsible,” while community responses indicate it’s the exchange’s job. - Hardware wallet migration issues: tokens not showing when connecting a Ledger directly to the migration site; workaround required (connect Ledger → browser wallet → site). - Users report price anxiety during migration, amplifying urgency and frustration. **Examples** - “How long do Koreans have to wait for migration?” (Bithumb delay) - “It doesn’t show up my Ai16z holding when connecting my ledger” → workaround via Phantom/Solflare/etc. --- ### 2) Security — **Migration-site compromise fears + recurring scam attempts** (Very high severity, medium frequency) **What users are experiencing** - A direct claim that the **migration site was compromised** and prompted approvals for valuable tokens; moderators acknowledged investigation. - Scammers appearing in main discussion; at least one was identified and banned. **Examples** - “Is the ElizaOS migration site hacked/hijacked?” → “We’re looking at it.” - Moderator action: scammer identified and banned (shows ongoing threat). --- ### 3) Documentation — **Onboarding gaps: plugins, versions, and “where does this config live?”** (High frequency, medium severity) **What users are experiencing** - Confusion about why basic prompts fail with errors (e.g., **TEXT_LARGE**) when an inference plugin isn’t registered. - Confusion about **whether OpenAI API keys must be connected to “elizacloud”** (unanswered in digest). - “Latest codebase” is referenced as a fix, but users ask “which version do you mean?” and don’t get a clear answer. - GitHub corroboration: docs moved/renamed (“Where did packages/docs go?” #6122) and requests for a proper public docs UI (#6128). **Examples** - “TEXT_LARGE error even when I just write ‘hi’” → caused by missing OpenAI/AI plugin registration. - “Which version do you mean by latest codebase?” → unanswered. --- ### 4) Technical Functionality — **DB integrity issues in real integrations (Twitter replies FK failures)** (Medium frequency, high severity for affected teams) **What users are experiencing** - Foreign key constraint failures tied to Twitter replies; “SQL fixes” exist but it’s unclear which release contains them and how to validate. **Examples** - “twitter replies causing database fail due to foreign key constraints” → “try latest codebase, it has SQL fixes.” --- ### 5) Integration — **Users want connectors and real-world data workflows (Neon, n8n, MCP/A2A)** (Medium frequency, medium severity) **What users are experiencing** - Users are building agents around external datasets (e.g., **NFL trade data in Neon**) and want clearer patterns + ready connectors. - Cloud direction emphasizes n8n workflows and MCP/A2A services, but developers still ask for concrete “connectors” and starter guidance. **Examples** - Request: integrate Neon-hosted NFL trades with an Eliza agent for queries. - “ElizaOS needs connectors” with a GitHub repo reference. --- ### 6) Community / Process — **Support tone + PR quality gate uncertainty** (Medium frequency, medium severity) **What users are experiencing** - A harsh response (“go sue Bithumb”) may discourage newcomers, especially international users already stressed about funds. - Core-dev proposal: require **screenshots/videos in PRs** because PRs that “build and pass review” still fail in production—indicates pain in release confidence and reviewer bandwidth. **Examples** - Migration support exchanges became tense. - Proposed PR rule: demos attached; plus stronger testing expectations. --- ## 2) Usage Pattern Analysis (actual vs intended) ### How users are actually using elizaOS (observed) 1. **Operations + token logistics** are a major “first experience” for many users right now (migration, wallets, exchanges). This is not product-intended usage, but it dominates attention. 2. **Agent builders are integrating live data sources** (Neon/Postgres datasets) and expecting “AI agent as an interface to my database.” 3. **Developers treat plugins as required runtime components**, but the system still allows failure modes that look like “the platform is broken” rather than “you’re missing an inference provider.” 4. **Cloud is seen as both hosting and identity/config layer** (questions like “do I need to connect that OpenAI key to elizacloud?”), indicating users conflate local framework vs managed cloud. ### Emerging / unexpected use cases - **Sports analytics agent** (NFL trades) with database-backed queries. - Mentions of **NFT interaction** use cases (lighter signal, but present). - Community interest in **voice** and **mobile** (from GitHub week summary issues #6196 and #6195), suggesting demand for packaged end-user surfaces beyond the dev framework. ### Feature requests that align with usage - **Connector ecosystem** (Neon/Postgres, social platforms, ad networks, SEO, social publishing). - **Cloud “create → publish → monetize → promote” loop** (explicitly stated in Discord). - **Clear multi-tenant/auth story** (JWT PR #6200 indicates direction; users will need docs + defaults). --- ## 3) Implementation Opportunities (solutions per major pain point) ### A) Token migration reliability & wallet visibility **1) Publish a “Migration Status & Responsibility” page (High impact, low/medium effort)** - Include CEX-by-CEX status (e.g., Bithumb: pending), who to contact, typical timelines, and what ElizaOS can/can’t do. - Similar pattern: L2 / token migrations often maintain a public status page (e.g., Ethereum L2 bridge status dashboards; major airdrop/migration projects publish per-exchange readiness lists). **2) Add a migration-site “Wallet Detection Checklist” with auto-diagnostics (High impact, medium effort)** - Detect Ledger direct connection limitations and prompt: “Use Phantom/Solflare with Ledger” + link to steps. - Show “We found zero AI16Z tokens at this address” vs “We can’t read this wallet type.” - Similar pattern: Uniswap / major dApps provide preflight checks (network, account, token balances) before allowing critical actions. **3) Add safe-mode UX: explicit approval warnings + transaction simulation hints (High impact, medium effort)** - Before any token approval/signature: show the exact contract, spender, and a “does this look right?” explainer. - Borrow from hardware wallet UX principles and Revoke.cash-style warnings (common in Web3 safety tooling). --- ### B) Security fears around migration site + scams **1) Ship an incident-style security update protocol (Very high impact, low effort)** - A pinned “Security Advisory” post with: what’s reported, what’s confirmed, what users should do now (e.g., revoke approvals, move funds), and when next update arrives. - Similar pattern: npm, GitHub Security Advisories, and major DeFi projects use short, timestamped updates to reduce rumor spread. **2) Add domain verification + signed announcements (High impact, medium effort)** - Ensure official domains are consistently communicated; publish a signed message (PGP or on-chain signature) linking official URLs. - Similar pattern: many crypto projects publish “official links” pages + signed proofs to reduce phishing. **3) Strengthen Discord anti-scam automation (Medium impact, low/medium effort)** - Auto-filter suspicious links, require account age thresholds in key channels, and create a single “report scam” workflow. - Similar pattern: large open-source Discords use AutoMod + locked-down newcomer permissions. --- ### C) Onboarding & documentation gaps (plugins, “elizacloud”, versions) **1) Add a “First Run Doctor” in CLI (`elizaos doctor`) (High impact, medium effort)** - Checks: inference plugin installed/registered, env vars present, `.eliza` directory, DB connectivity, compatible package versions. - Similar pattern: `flutter doctor`, `brew doctor` drastically reduce repetitive setup questions. **2) Upgrade error messages to be prescriptive (High impact, low/medium effort)** - Example: TEXT_LARGE → “No inference provider registered. Install @elizaos/plugin-openai (or compatible) and set OPENAI_API_KEY (or configure Cloud provider).” - Similar pattern: modern SDKs (Supabase, Firebase) emit “actionable” errors that include next steps. **3) Version clarity: “latest codebase” → always map to tag/commit (Medium impact, low effort)** - In Discord support playbooks: always answer with “>= vX.Y.Z” or “commit abc123” and link release notes. - Similar pattern: Kubernetes/Helm communities standardize version-based support answers. --- ### D) DB foreign key constraint failures (Twitter replies) **1) Provide a minimal reproduction + migration guide (High impact, medium effort)** - A small fixture dataset + steps to trigger the FK failure, then verify the fix. - Similar pattern: Django/Rails communities rely on repro repos and migration checklists for DB integrity issues. **2) Add automated integration coverage for social reply ingestion (Medium/high impact, medium effort)** - Tests that ingest a reply chain out of order (common in API webhooks) to ensure constraints don’t hard-fail. - Similar pattern: event-ingestion systems (Airbyte connectors) test out-of-order events heavily. **3) Provide a safe fallback behavior (Medium impact, medium effort)** - If parent tweet missing, store as “pending parent” rather than failing the transaction; reconcile later. --- ### E) Connector demand (Neon, n8n, MCP/A2A) + real-world workflows **1) Publish “reference integrations” (High impact, medium effort)** - Starter templates: Neon/Postgres → agent tool → query endpoint; n8n workflow that calls agent; MCP/A2A example. - Similar pattern: LangChain and n8n grow via cookbook-style examples that are copy/pasteable. **2) Define a connector interface + registry (High impact, higher effort)** - Even a lightweight manifest + versioning and a curated list would meet users where they are (“I need connectors”). - Similar pattern: Home Assistant and VS Code extension ecosystems thrive on registries + consistent interfaces. **3) Add “data source onboarding” docs (Medium impact, low effort)** - “How to point an agent at Neon” + schemas + recommended query safety patterns. --- ### F) Community/process friction (tone + PR demo rule) **1) Create a “Support Tone & Escalation” guideline (Medium impact, low effort)** - Especially for finance-adjacent topics (migration), require empathetic, non-inflammatory responses + a standard escalation path. **2) Add PR checklist requirements: demo artifact + test evidence (Medium/high impact, low/medium effort)** - Adopt cjft’s suggestion: screenshots/video required for UI-facing changes; add “how I tested” required fields. - Similar pattern: many OSS projects enforce PR templates + CI gates; Electron/VS Code communities benefit from mandatory repro/demos. **3) Add a lightweight “post-merge production verification” rotation (Medium impact, medium effort)** - A weekly on-call style for verifying merged PRs in staging/production reduces repeated failures. --- ## 4) Communication Gaps (expectations vs reality) 1. **“ElizaOS controls my CEX migration” vs reality (“exchange controls it”)** - Users expect ElizaOS to directly resolve Bithumb delays. - Fix: a single canonical migration FAQ + status page + recommended user scripts for contacting the exchange. 2. **“Migration site is safe by default” vs fear of malicious approvals** - Even unconfirmed reports create high panic. - Fix: preflight warnings, official link verification, and rapid security advisories. 3. **“If I installed elizaOS, it should just answer” vs plugin-based architecture** - TEXT_LARGE triggered by missing inference provider reads like a platform defect. - Fix: onboarding doctor + better errors + “Choose provider” guided flow. 4. **“Latest codebase has SQL fixes” is not actionable without version mapping** - Fix: always answer with version numbers and link to release notes/PRs. 5. **Cloud vs local confusion** - “Do I need to connect that [OpenAI API key] to elizacloud?” shows unclear boundaries. - Fix: a simple matrix: Local (env vars) vs Cloud (managed keys), when each is required. --- ## 5) Community Engagement Insights ### Power users / helpers observed (and what they need) - **satsbased**: community triage + scam identification; needs better mod tooling and clear official resources to point to. - **DorianD**: wallet migration troubleshooting; needs an official, linkable hardware-wallet guide to reduce repetition. - **sayonara**: technical support for plugin setup; needs better onboarding docs and error messages. - **Kenk / NeonVortex**: integration help (Neon + agent); needs reference integrations and connector docs. - **cjft**: process/quality improvements; needs maintainers to adopt PR gates and testing norms. - **Odilitime / Redvoid**: infra + DB fix guidance; needs version clarity and changelog linking. ### Common newcomer questions indicating onboarding friction - “Why do I get TEXT_LARGE on ‘hi’?” - “Which version is ‘latest codebase’?” - “Do I need to connect my OpenAI key to elizacloud?” - “Why don’t my tokens show up when using Ledger?” ### Converting passive users into contributors - Create an “Eliza-Alpha” preview channel (as proposed) with: - clear entry criteria (builders, integrators, docs writers) - bite-sized tasks (“test migration UX,” “verify Ledger steps,” “try Neon template”) - recognition: contributor role + changelog callouts - Tag “good first issue” items explicitly around docs improvements and connector examples. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** is effective for rapid troubleshooting, but high-stakes issues (migration/security) create rumor cascades and repeated questions. - **GitHub issues/PRs** capture actionable engineering work, but user pain often arrives first in Discord and doesn’t become structured tickets. ### Improvements to gather structured, actionable feedback 1. **Add a “Migration Issue Intake” form** (Google Form or GitHub Issue template) - Required fields: wallet type, CEX/self-custody, tx hashes, screenshots, domain used, time. 2. **Add a “Support Snapshot” bot command** (e.g., `/faq migration`, `/faq ledger`, `/faq text_large`) - Reduces repeated explanations and keeps answers consistent. 3. **Weekly “Top 5 pain points” Discord poll** - Lightweight quant signals; helps prioritize docs vs features vs fixes. ### Underrepresented segments - **Non-English users** (Korean users surfaced strongly here) need localized migration/status comms. - **Non-crypto “pure OSS” agent builders** are likely underrepresented in Discord discussions dominated by migration; consider a separate “builders” onboarding survey to ensure framework UX doesn’t get overshadowed. --- ## Prioritized High-Impact Actions (next 1–2 weeks) 1. **Publish a canonical Migration Status + FAQ page** (CEX responsibility, Ledger steps, official links, revocation guidance) and pin it across Discord channels. 2. **Implement a security advisory protocol** (timestamped updates, confirmed/unconfirmed separation) and add official domain verification + signed link post. 3. **Ship `elizaos doctor` + upgrade error messages** for missing inference plugins / key config (eliminate TEXT_LARGE confusion and Cloud-vs-local ambiguity). 4. **Standardize “versioned support answers”** (never “latest codebase” without a version/tag) and link fixes directly to releases/PRs. 5. **Adopt PR quality gates** (demo artifact + testing evidence) to reduce “works in PR, fails in production” regressions and improve reviewer confidence.