# ElizaOS Intel — 2026-05-13

## 1) Data Pattern Recognition

### Development velocity & trend
- **May-to-date (repo: `elizaos/eliza`, 2026-05-01 → 2026-06-01 interval snapshot)**  
  - **PRs:** 144 opened / **90 merged** (**62.5% merge rate**)  
  - **Issues:** 14 opened / **13 closed**  
  - **Active contributors:** 15  
- **Change profile (same interval snapshot)**: **+30,795 / -4,107 LOC** across **378 files** (net +26,688). Indicates high feature throughput and large-surface refactors (e.g., cloud + plugin migration work) with elevated regression risk.

### Community engagement patterns (Discord, 2026-05-10 → 2026-05-12)
- Engagement skewed toward:
  - **Introductions / recruiting** (multiple engineer intros; low technical follow-through).
  - **Operational Q&A** (plugin submission path blocked; sandbox testing permissions).
  - **Security alarms** (compromise/scammer concerns) with repeated mentions across days.
- Technical support load concentrated on a small number of responders (notably **odilitime**), suggesting a **single-point-of-failure** for community ops + infra triage.

### Feature adoption / usage signals
- **Third-party plugin ecosystem demand is active**: at least one plugin (`plugin-undesirables@2.0.3`) fully prepared with generated registry metadata and awaiting submission.
- **Sandboxed agent testing demand emerging**: request to run a read-only research agent using A2A + MCP integrations (Tavily/fetch/DDG/arXiv). Indicates community appetite for “agents-in-Discord” experimentation, contingent on governance and security controls.

### Pain point correlation across channels
- **Plugin distribution bottleneck** (v2 registry 404) correlates with:
  - licensing constraints (BUSL-1.1 cannot PR into monorepo) → **hard block** for some plugin authors.
  - unclear policy (“v2 registry vs PRs to monorepo”) → repeated questions, stalled releases.
- **Security concerns** correlate with:
  - increased desire for bot testing + OAuth/whitelisting → higher attack surface at the same time moderation capacity is strained.

---

## 2) User Experience Intelligence

### Feedback themes (categorized by impact)

**A. P0 / Critical: Plugin publication path broken**
- Symptom: **404** on `elizaos-plugins/registry` and `plugins.elizacloud.ai`.
- User impact:
  - Blocks shipping of third-party plugins (immediate developer frustration + ecosystem slowdown).
  - Disproportionately affects BUSL-licensed plugins that *cannot* use monorepo PR workflow.
- Sentiment: confusion + waiting; expectation that infra is private/behind beta, but no clear status.

**B. P0 / Critical: Discord trust & safety**
- Reports of “compromised admin accounts” and scammers. Even if “no admins” is accurate, user perception = governance uncertainty.
- UX consequence: reduced willingness to click links/install plugins/test bots; reputational damage.

**C. P2 / Moderate: Cost/operability clarity**
- Twitter bot cost discussion: costs reported as **~$100/mo → ~$10/mo** now, driven by reply volume/config.
- Opportunity: convert ad-hoc discussion into a small “cost model” doc/preset configs.

**D. P2 / Moderate: Token/project confidence (unanswered)**
- Concern about token support and leadership signaling (“removed from X bio”) received no response → can metastasize if unaddressed.

### Usage patterns vs intended design
- Intended: v2 registry as primary third-party distribution channel.  
- Observed: infra downtime + licensing constraints push community to request reverting to **direct PRs**—but that’s incompatible with some licenses, creating a **policy dead-end** unless an alternative path exists.

### Implementation opportunities (UX-facing)
- Single, canonical “How to publish a plugin” flow with:
  - license-aware branching (MIT/Apache vs BUSL)
  - status page / uptime indicator for registry
  - staging/testing steps before publication
- Security posture surfaced in-Discord: clearer roles, official links, and a bot verification/testing protocol.

---

## 3) Strategic Prioritization

### Priority queue (impact × risk × dependency)

#### P0 — Restore plugin registry availability + clarify submission policy (ecosystem critical path)
**Why now**
- Registry 404 is a **hard blocker** for third-party growth and specifically blocks BUSL plugins entirely.
- Ongoing ambiguity creates repeated support overhead and delays.

**Actions (48–72h)**
1. **Triage 404 root cause** (DNS/routing, repo visibility, auth gating, CI deploy) and publish an ETA.  
2. **Define interim submission policy** (until registry returns):
   - If reverting to monorepo PRs: publish explicit exception handling for **BUSL** (e.g., external registry-only lane, or separate private ingestion repo).
   - If keeping v2 registry: provide a **temporary staging repo** + documented process.
3. **Ship a “status + workaround” announcement** in Discord + docs pinned message:
   - Current state (outage vs private)
   - Where to submit now
   - What to do for BUSL plugins

**Success metrics**
- Time-to-first-successful third-party submission after fix (target: <24h).
- Reduction in repeated “404 / how to submit” questions (qualitative + count).

**Risks**
- Policy flip-flopping increases distrust; pick one path with a published timeline.

---

#### P0 — Discord security & governance hardening (trust protection)
**Why now**
- Active scammer activity + perceived admin compromise. Combined with upcoming bot/OAuth tests → heightened risk.

**Actions (24–72h)**
1. **Immediate containment**
   - Audit roles, privileged accounts, webhook integrations, bot permissions.
   - Lock down invite links; rotate tokens where applicable.
2. **Establish a “Verified bots / OAuth testing” protocol**
   - Mandatory sandbox channel
   - Explicit permission template (read-only, no DMs, rate limits, mention-only replies)
   - Public checklist for whitelisting + owner contact
3. **User-facing clarity**
   - Pin “Official links + security guidance” (how to verify domains/repos; how to report scams).

**Success metrics**
- # of scam reports/day (target downward trend).
- # of newly approved test bots with documented owners and scopes (target: 100% compliance).

**Dependencies**
- Community ops bandwidth; ideally distribute to 2–3 moderators/helpers to remove single-thread dependency.

---

#### P1 — Formalize “Agents-in-Discord” experimentation lane (captures community energy safely)
**Why**
- The orchestrator testing request is well-scoped (read-only research agent; mention-only). This is a good template for broader experimentation—if governed.

**Actions (1–2 weeks)**
- Create a lightweight program:
  - “Experimental Agents” category, standard bot manifest, logging requirements, escalation path.
  - Encourage porting to Eliza only after proof-of-value and safety review.

**Success metrics**
- # experiments run → # that graduate to plugins/features.
- Moderator time per experiment (target: predictable, bounded).

---

#### P2 — Convert cost chatter into operational presets (retention/activation)
**Actions (1 week)**
- Document Twitter bot cost drivers:
  - reply volume caps, backoff strategies, caching, model selection.
- Provide 2 presets: “Low-cost” (~$10/mo target) and “High-engagement”.

**Success metrics**
- Reduced repeat questions; improved successful deployments.

---

## Resource Allocation Recommendation (next 7 days)
- **Core/Platform (1–2 engineers):** registry 404 fix + submission policy + docs/pinned message.
- **Community Ops/Security (2 people minimum):** Discord audit + scam mitigation + bot testing protocol.
- **DX/Docs (0.5–1 person):** plugin submission decision tree (license-aware) + registry status guidance.
- **Optional (1 engineer):** formalize sandbox testing channel automation (permissions, logging hooks).

---

## Key Risks & Watch Items
- **Ecosystem stall risk:** If registry remains down and policy remains ambiguous, third-party momentum drops; BUSL developers are uniquely blocked.
- **Trust risk:** Security uncertainty in Discord can spill into reluctance to install plugins or test agents.
- **Single-point support risk:** Concentration on one helper for OAuth + policy answers increases cycle time and burnout.

---

## “Next update should confirm”
1. Registry endpoints/repo accessibility status (public/private/outage) + resolution ETA.  
2. Interim plugin submission path, including BUSL-safe route.  
3. Discord security actions taken (what changed, how users can verify safety).