## User Feedback — 2026-04-20 (covering latest available community + repo signals through 2026-04-19) ### Data snapshot (what we actually saw) - **Discord themes (Apr 17–19):** token staking availability, repeated scam/phishing incidents, security vuln reporting process, org/restructure comms, social media inactivity. - **GitHub activity (monthly context, Apr 1–May 1):** **221 PRs (184 merged), 43 new issues, 43 contributors** (high development velocity). Strong signal that builder-facing work is active even when social channels appear quiet. --- ## 1) Pain Point Categorization (top recurring friction areas) > Quant note: Discord summaries for Apr 17–19 contain **~5 high-salience recurring topics**. Percentages below are computed as “mentions across these recurring topics,” not unique users. ### 1) Community — Scam/phishing noise + trust breakdown (High severity, high frequency) **Observed:** Scam airdrop/phishing attempts on Apr 18 and Apr 19; impersonation of known members (e.g., “kenk”), fake “Solana airdrop from Odilitime.” Mods repeatedly stated: “any airdrop tags in Discord are always scams.” **Frequency:** ~2/5 of recurring topics (~40%) and appears repeatedly across days. **Impact:** Direct user harm risk; reduces trust in Discord as a support channel; increases moderator load. **Most affected users:** newcomers and traders who join for token info/airdrops. --- ### 2) Documentation / Community — No clear security disclosure policy + bug bounty expectations mismatch (High severity, medium frequency) **Observed:** Researcher (**kullai**) asked about bug bounty; none exists. Initial suggestion from a community member to file a public PR/issue was corrected (security should be private). **Frequency:** ~1/5 topics (~20%), but **very high severity** (risk of accidental public disclosure). **Most affected users:** security researchers, integrators deploying agents in production. --- ### 3) Community / Integration — Token “staking” confusion and product/token expectation mismatch (Medium severity, high frequency) **Observed:** Multiple users asked about **staking for ElizaOS tokens**; moderators confirmed it’s **not available**. **Frequency:** Appears as a primary question in Apr 19 discussion (~1/5 topics, ~20%), but likely broader given typical crypto community dynamics. **Most affected users:** token holders, newcomers arriving via token channels rather than builder docs. --- ### 4) Community — “Where is the team?” comms gap (Twitter inactivity; org changes) (Medium severity, medium frequency) **Observed:** Concern that Twitter/X was inactive for ~3 weeks; response: priority is “Milady development.” Separate thread: dissolution of “Eliza Labs,” shift back to open contribution model; users needed reassurance that dev continues and where to look (GitHub). **Frequency:** ~2/5 topics (~40%) combined (org restructure + social inactivity). **Most affected users:** passive followers, non-coders, token community. --- ### 5) Technical Functionality — Agent orchestration/memory edge cases and reliability improvements (Medium severity, medium frequency) **Observed (repo/dev summary):** - Subagent synthesis changes (end_turn reading; remove task-heartbeat module) - InMemoryDatabaseAdapter fix for memory updates when `roomId` changes - Discord routing/submodule dependency updates These are “under-the-hood” fixes that often correlate with user-visible reliability issues (lost memory, inconsistent multi-room behavior, orchestration weirdness). **Frequency:** not explicit in Discord chat, but repeatedly present in engineering updates (suggests ongoing underlying pain). **Most affected users:** builders running multi-room agents (Discord), multi-agent orchestration, long-running deployments. --- ### 6) Integration — Plugin ecosystem growth creates discoverability + quality uncertainty (Medium severity, emerging) **Observed:** New plugins (e.g., **plugin-hiveexchange** for prediction markets), pending registry additions (deepblue, plugin-elizaos), and proposals around **agent-to-agent commerce** (Merxex). Users are pushing integrations quickly; governance/quality expectations are unclear (official vs community maintained). **Most affected users:** builders trying to pick “the right” plugin and trust it. --- ## 2) Usage Pattern Analysis (actual vs intended usage) ### What users are actually doing 1. **Using Discord primarily as a token/security helpdesk** rather than a developer support venue: - staking questions - airdrop legitimacy checks - migration backstory (ai16z token migration tweets) 2. **Using elizaOS as an “agent commerce / trading / prediction” framework**: - plugin-hiveexchange (prediction markets) - DeepBlue x402 API proposal (paid crypto intelligence) - Merxex commerce proposals (agent-to-agent trade) 3. **Treating the project as open-contribution again** (post-Labs dissolution), but needing clearer “how to contribute” pathways. ### Intended vs actual mismatch - Intended: open-source agent framework for builders. - Actual (from community surface area): many participants join for token-related utility and scams/airdrops; builders show up via plugin proposals and collaboration posts, not via structured onboarding. ### Feature requests aligned with actual usage - **Trust / identity / anti-impersonation** (community-level and agent-level) aligns with scam incidents and commerce/prediction use cases. - **Safer autonomy / scoped permissions** (seen in delegation-chain proposals, security concerns) aligns with agents interacting with money and external systems. --- ## 3) Implementation Opportunities (solutions per major pain point) ### Pain Point A: Scam/phishing in Discord (High impact) **1) Ship an “Official Links & Airdrop Policy” enforcement layer (High impact / Low-medium effort)** - Add a locked, read-only channel: **#official-links** (website, docs, GitHub, X, announcement mirrors). - Enforce a rule: *no airdrops announced in Discord*; all token events only from signed/verified posts (see below). **2) Automod + link hygiene (High impact / Medium effort)** - Auto-delete messages with “airdrop” + external links outside allowed domains; quarantine new accounts posting links. - Require account age / server membership duration before posting links in high-visibility channels (arena/discussion). - Similar approach: many OSS Discords (e.g., large web3 SDK communities) use **domain allowlists + “first week no links”** policies. **3) Cryptographic/verified announcements (Medium-high impact / Medium effort)** - Publish announcements that include a **signed checksum** (PGP/SSH signature) or “posted simultaneously to GitHub Releases + X + website RSS.” - Similar approach: security-conscious projects distribute updates via **GitHub + website canonical pages** and treat Discord as non-canonical. --- ### Pain Point B: Security vulnerability reporting uncertainty + no bug bounty (High impact) **1) Add `SECURITY.md` + private intake mailbox (High impact / Low effort)** - Provide: reporting channels, what qualifies, expected response time, embargo guidance. - Include “Do not file public issues for security bugs.” - Similar approach: GitHub’s standard `SECURITY.md` workflow; most serious OSS projects adopt it even without bounties. **2) Lightweight “recognition” program before cash bounties (Medium-high impact / Low effort)** - If no budget: Hall-of-fame acknowledgments, swag, “security contributor” Discord role. - This reduces the “why report responsibly?” friction while remaining feasible. **3) Consider partnering for bounties later (Medium impact / High effort)** - Longer term: OpenSSF / Immunefi-style program if token/community expectations make it necessary. --- ### Pain Point C: Token staking confusion (Medium impact) **1) Put staking status in one canonical FAQ (High impact / Low effort)** - Pin: “Staking is not available; beware scams claiming staking/airdrops.” - Add to website/docs and Discord welcome flow. **2) Replace “staking” demand with transparent token utility roadmap (Medium-high impact / Medium effort)** - Even if staking remains “no,” publish what *is* planned (governance, fees, plugin marketplace, etc.), or explicitly state “no token utility commitments.” **3) Add a Discord bot auto-reply for “staking/airdrop” keywords (Medium impact / Low effort)** - Reduces moderator burden and limits user confusion. --- ### Pain Point D: Comms gap (Twitter inactivity + org changes) (Medium impact) **1) “Weekly shipping note” auto-posted from GitHub activity (High impact / Low-medium effort)** - Since GitHub is active, auto-generate a weekly digest (merged PR titles, releases, security notes) and post to Discord + X. - Similar approach: projects like Homebrew/Kubernetes rely heavily on **automated release notes + changelog discipline**. **2) Publish a short “Org structure & contribution model” page (Medium impact / Low effort)** - Clarify: Labs dissolved, core focus, how to contribute now, where decisions happen. **3) Set expectations: what channels are canonical (High impact / Low effort)** - “Discord is community chat; GitHub + docs site are source of truth.” --- ### Pain Point E: Reliability edge cases (memory/orchestration/Discord routing) (Medium impact) **1) Add regression tests for “roomId change” and multi-room memory consistency (High impact / Medium effort)** - Convert the recent fix into a test suite so it doesn’t recur. **2) Provide an “orchestrator health” debug page/log bundle (Medium impact / Medium effort)** - One command to export: plugin versions, routing table, memory adapter state, recent errors. **3) Document orchestration primitives with “known failure modes” (Medium impact / Low-medium effort)** - Especially around subagent synthesis, end_turn behavior, and removed heartbeat behavior. --- ### Pain Point F: Plugin discoverability + trust (Medium impact, growing) **1) Registry metadata standards (High impact / Medium effort)** - Require: maintainer, support status, security notes, minimal test badge, compatibility matrix with core versions. - Similar approach: VS Code marketplace and Home Assistant HACS both rely on **metadata + ownership clarity**. **2) “Official / Verified / Community” tiers (Medium-high impact / Medium effort)** - Make expectations explicit to reduce “is this supported?” confusion. **3) Security linting for plugins (Medium impact / High effort)** - Automated scans (SBOM, vuln scanning, permission usage declarations). --- ## 4) Communication Gaps (expectations vs reality) ### Recurring mismatches - **Expectation:** staking exists (or will be announced in Discord). **Reality:** no staking; “airdrops” in Discord are scams. - **Expectation:** security reports should go to GitHub issues/PRs. **Reality:** private disclosure is required; current process is informal (DM a maintainer). - **Expectation:** inactivity on Twitter implies project inactivity. **Reality:** GitHub is highly active; org changed (Labs dissolved, core refocus). ### Documentation/onboarding gaps indicated by repeated questions - “Is staking available?” indicates missing **token FAQ** and missing “official announcements policy.” - “Where do I report a vuln?” indicates missing **SECURITY.md** and visible reporting instructions. - “Is dev still active?” indicates missing “Where to track progress” onboarding step. ### Targeted improvements - Add a **“Start Here: official links + security + token FAQ”** page and pin it in Discord. - Add a Discord **/security** and **/scams** slash command that returns canonical guidance. --- ## 5) Community Engagement Insights ### Power users / key roles observed - **odilitime** (moderator/core dev): primary responder for staking + scam removal + security receipt. - **satsbased** (mini mod): rapid scam response; shared migration context; key “community trust” node. - **doriand0963** (partner/community): answered staking question; helps reduce repeated load. - **kullai** (security-minded contributor): surfaced vulnerabilities responsibly; needs a formal path. - **stan0473** (core dev): engaged on reporting approach; opportunity to standardize “security triage playbook.” ### Newcomer patterns (onboarding friction) - Newcomers arrive with **token-first questions** (staking, airdrops) rather than “how to build an agent.” - They rely on Discord as authoritative, which scammers exploit. ### Converting passive users into contributors - Provide “first contribution” paths tied to observed needs: - docs PRs for SECURITY.md / FAQ / anti-scam banner - automod config contributions - plugin registry metadata PRs - Highlight collaboration posts (like the Apr 19 dev seeking collaborations) in a dedicated **#collab-board** channel with a template (skills, project need, repo link). --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord:** fast, high-volume, but unstructured; dominated by scams/token Qs; hard to convert into actionable issues. - **GitHub issues:** active, but mixed between real bugs and broad plugin proposals; users may not know where to post what. ### Improvements (more structured, actionable) 1. **Discord-to-GitHub intake form (Low-medium effort)** - A simple form with categories (Security / Bug / Docs / Feature / Token FAQ). - Auto-creates a GitHub issue with correct labels *except security*, which routes privately. 2. **Monthly “Top 5 questions” report (Low effort)** - Track repeated Discord questions (“staking,” “airdrop,” “is this official,” “where report vuln”). - Use it to drive docs updates. 3. **Underrepresented segments to proactively sample** - **Non-Discord builders** (those integrating via NPM/PyPI only) - **Ops teams** deploying long-running agents (need reliability + security posture docs) - **Plugin maintainers** (need registry standards, compatibility tooling) --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Publish `SECURITY.md` + private reporting channel** (email alias or security form) and pin it in Discord (highest risk reduction, low effort). 2. **Implement Discord anti-phishing hardening**: domain allowlist + new-account link restrictions + auto-delete “airdrop” link patterns; add locked **#official-links** channel. 3. **Create a canonical Token FAQ** (staking status, “no airdrops in Discord,” official announcement sources) and add bot auto-replies for staking/airdrop keywords. 4. **Automate a weekly “Shipping/Activity Digest” from GitHub to Discord + X** to close the “project is quiet” perception gap. 5. **Add plugin registry metadata requirements + “official/verified/community” tiers** to reduce integration trust confusion as commerce/prediction-market plugins expand.