## Issue Triage — 2026-02-17

### 1) [Bug] URL in message triggers duplicate LLM calls — processed as both text and attachment (webapp) — elizaos/eliza#6486
- **Current Status:** OPEN (reported, needs confirmed root-cause + fix PR)
- **Impact Assessment:**
  - **User Impact:** High (any webapp user sending URLs)
  - **Functional Impact:** Partial (chat still works but response is duplicated + extra spend)
  - **Brand Impact:** High (visible “broken” behavior + cost blowups)
- **Technical Classification:**
  - **Issue Category:** Bug, Performance (cost), UX
  - **Component Affected:** Webapp + Server message pipeline (attachment/preview handling), SSE streaming aggregation
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, message normalization pipeline, SSE streaming, test writing (integration/e2e)
  - **Dependencies:** Clarify where URL preview/metadata is injected (client vs server) and where LLM call is initiated (text handler vs attachment handler)
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add a minimal reproducible test (Cypress or server integration) for “message with URL ⇒ exactly 1 LLM request + 1 response chunk stream”.
  2. Trace message object through: UI → API → `convertToUIMessages`/attachment parsing → LLM call(s) → SSE emitter.
  3. Implement a single-source-of-truth rule: URL is either (a) inline text OR (b) attachment preview, never both; add dedupe guard keyed by messageId + content hash.
  4. Add metrics/logging: count LLM calls per inbound message; alert if >1 in non-tool scenarios.
- **Potential Assignees:** **lalalune** (runtime/message flow), **odilitime** (client/server integration), **anchapin** (defensive guards + tests), **thewoweffect** (reporter validation)

---

### 2) Discord scam attempts via threads; restrict thread creation + ban known scammer — DISCORD-SEC-001
- **Current Status:** OPEN (action item identified; no confirmed enforcement changes documented)
- **Impact Assessment:**
  - **User Impact:** Critical (direct financial/social engineering risk)
  - **Functional Impact:** No (product), **Yes** for community safety operations
  - **Brand Impact:** High (trust and legitimacy perception)
- **Technical Classification:**
  - **Issue Category:** Security, UX (community)
  - **Component Affected:** Discord community operations (roles/permissions, moderation workflows)
  - **Complexity:** Simple fix (permissions + moderation), plus moderate ongoing process
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling, security comms
  - **Dependencies:** Identify current thread creation permissions + audit recent incidents; align mod coverage
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Immediate:** Ban user ID **364718078946312192** (reported scammer) and delete/lock scam threads.
  2. Restrict thread creation in high-risk channels (e.g., coders) to trusted roles; add slowmode where needed.
  3. Pin an “Official Support Policy” message: no DMs, no external Discord/Zoom, no wallet asks, where real support happens.
  4. Create an incident template (who/what/links/actions taken) and a private mod log channel.
- **Potential Assignees:** **Odilitime** (ops), **Kenk** (community leadership), Discord moderators/admins (server owners)

---

### 3) Integration Proposal: MoltBridge Trust & Discovery Layer (response to “341 malicious skills bypassed vetting”) — elizaos/eliza#6501
- **Current Status:** OPEN (proposal stage; integration testing recruitment underway externally)
- **Impact Assessment:**
  - **User Impact:** High (marketplace/plugin consumers; anyone running third-party skills)
  - **Functional Impact:** Partial (core runtime works, but ecosystem safety is compromised)
  - **Brand Impact:** High (plugin ecosystem integrity)
- **Technical Classification:**
  - **Issue Category:** Security, Feature Request (platform hardening)
  - **Component Affected:** Plugin System / Marketplace, Agent-to-Agent identity, discovery/trust scoring
  - **Complexity:** Architectural change
- **Resource Requirements:**
  - **Required Expertise:** Applied cryptography (Ed25519), identity modeling, reputation/trust systems, plugin signing/distribution, threat modeling
  - **Dependencies:** Decide target scope (runtime-level identity vs marketplace-level signing); align with existing JWT/auth/data-isolation work; define trust signal inputs (e.g., Security Oracle)
  - **Estimated Effort (1–5):** 5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Produce a 1–2 page RFC: goals, threat model, “minimum viable trust” (signing + verification) vs “full trust graph”.
  2. Define integration surface in ElizaOS: where agent identity keys live, how plugins/skills are signed, how verification is enforced (warn vs block).
  3. Prototype: optional signature verification for plugin manifests + display trust status in UI/CLI.
  4. Set up a pilot with a small number of “founding agents” to validate SDK + identity linking flows.
- **Potential Assignees:** **borisudovicic** (platform roadmap), **lalalune** (core architecture), **odilitime** (plugin ecosystem), external collaborator **Dawn/Justin (SageMind AI)** as design partner

---

### 4) Clarify policy on autonomous AI agent participation in Discord (disclosure requirements, allowed behaviors) — DOC-COMM-001
- **Current Status:** OPEN (community confusion raised; no written rule referenced)
- **Impact Assessment:**
  - **User Impact:** Medium/High (community-wide trust + moderation overhead)
  - **Functional Impact:** No (product), but impacts community support quality
  - **Brand Impact:** High (transparency + safety expectations)
- **Technical Classification:**
  - **Issue Category:** Documentation, UX (community governance)
  - **Component Affected:** Community guidelines / moderation policy
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Community governance, moderation, comms clarity
  - **Dependencies:** Align with existing server rules; decide enforcement (tags/roles, disclosure format)
  - **Estimated Effort (1–5):** 1
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a written rule: AI agents must disclose they are AI (and operator) in profile and/or first message in threads.
  2. Define allowed behaviors: no impersonation, no unsolicited DM support, no trading/financial advice unless explicitly permitted, rate limits.
  3. Add an “AI Agent” role and a lightweight verification process (manual approval).
- **Potential Assignees:** **Kenk**, **Odilitime**, Discord moderators

---

### 5) Solana plugin usability + website integration path unclear (Kalshi/Moltbook plugin blocked); evaluate mcp-gateway and alternatives (x402) — PLUG-SOL-001
- **Current Status:** OPEN (questions unanswered; integration risk for ecosystem builders)
- **Impact Assessment:**
  - **User Impact:** Medium (Solana integrators/builders), potentially High for trading-agent segment
  - **Functional Impact:** Partial (blocks a class of integrations and partner momentum)
  - **Brand Impact:** Medium (perceived “hard to integrate”)
- **Technical Classification:**
  - **Issue Category:** Bug/UX (DX), Documentation (if functionality exists but unclear), Feature (if missing)
  - **Component Affected:** Plugin System, **plugin-solana**, website embedding, **mcp-gateway**
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Solana integration, ElizaOS plugin architecture, web embedding/security model, MCP gateway knowledge
  - **Dependencies:** Determine current supported flow for browser/websites (wallet adapters, auth tokens, CORS, server proxy)
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a canonical “Solana plugin integration status” doc: supported features, examples, known limitations.
  2. Decide recommended website path: (A) server-side agent + web client, (B) mcp-gateway, or (C) alternative plugin/standard.
  3. Add/refresh an example project showing end-to-end website integration (connect wallet → sign → agent executes).
  4. If gaps exist, open concrete GitHub issues per missing capability (website auth, tx signing flow, sandboxing).
- **Potential Assignees:** **odilitime** (Solana/plugin work), **lalalune** (architecture), plugin-solana contributors (as available)

---

### 6) Implement agent authentication approach for Security Oracle API; align with cryptographic identity vs API keys — SEC-ORACLE-001
- **Current Status:** OPEN (beta released; auth model questioned; integration not defined)
- **Impact Assessment:**
  - **User Impact:** Medium (trading-agent developers), High if positioned as ecosystem safety primitive
  - **Functional Impact:** Partial (not blocking core runtime; impacts security integrations)
  - **Brand Impact:** Medium (security posture credibility)
- **Technical Classification:**
  - **Issue Category:** Security, Feature Request
  - **Component Affected:** External API integrations, identity/auth layer, potential MoltBridge synergy
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** API auth design, cryptographic signatures (optional), rate limiting/abuse prevention, JSON schema contracts
  - **Dependencies:** Decision on identity standardization (Ed25519 keys, JWT, API keys) across ecosystem
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define minimal auth requirement for beta testers (API key today) and a migration plan to signed requests (Ed25519) if desired.
  2. Create a reference ElizaOS plugin wrapper that enforces strict JSON schema + backoff to satisfy rate limits.
  3. Evaluate which oracle signals become first-class “trust inputs” (Sybil farms, insider concentration) and map into a trust scoring interface.
- **Potential Assignees:** **borisudovicic** (platform alignment), **lalalune** (identity/auth architecture), external **Vlt9** (API owner), external **Dawn/Justin** (trust-layer alignment)

---

### 7) Feature Request: Support custom OpenAI endpoint URL for OpenAI provider — elizaos/eliza#6490
- **Current Status:** OPEN
- **Impact Assessment:**
  - **User Impact:** Medium (users of OpenAI-compatible providers like SiliconFlow)
  - **Functional Impact:** No (workarounds exist via other providers), but blocks a common integration pattern
  - **Brand Impact:** Medium (integration flexibility)
- **Technical Classification:**
  - **Issue Category:** Feature Request, UX (DX)
  - **Component Affected:** Model Integration / OpenAI provider configuration
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Provider configuration patterns, env/config schema, tests
  - **Dependencies:** Ensure endpoint override doesn’t break auth headers, streaming, or multipart routes
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add `OPENAI_BASE_URL` (or provider-scoped config field) with validation + safe default.
  2. Add unit tests for URL normalization and integration test against a mock OpenAI-compatible server.
  3. Document supported compatibility expectations (ChatCompletions/Responses endpoints, streaming).
- **Potential Assignees:** **lalalune** (providers), **odilitime** (integration/testing), interested contributor **coolRoger** (reporter)

---

## Summary: Top Highest-Priority Issues to Address Now (5–10)
1. **P0:** elizaos/eliza#6486 — URL messages cause **duplicate LLM calls** (cost + UX regression).
2. **P0:** DISCORD-SEC-001 — **Scam containment** (ban offender, restrict thread creation, pin official support policy).
3. **P1:** elizaos/eliza#6501 — **Trust/identity layer** response to malicious skills bypassing vetting (security roadmap + pilot).
4. **P1:** DOC-COMM-001 — **Policy clarity** on autonomous AI agents in Discord (mandatory disclosure + guardrails).
5. **P1:** PLUG-SOL-001 — **Solana + website integration clarity** (unblock Kalshi/Moltbook-style integrations).
6. **P2:** SEC-ORACLE-001 — Security Oracle auth model + reference plugin wrapper.
7. **P2:** elizaos/eliza#6490 — Custom OpenAI endpoint URL support.

---

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Identity & trust are becoming first-class requirements** (malicious skills, A2A interactions, oracle trust signals), but currently appear fragmented across proposals (JWT auth, MoltBridge keys, external APIs).
- **Message normalization is fragile** (URL treated as both text and attachment), indicating unclear ownership boundaries between client preview generation, server ingestion, and runtime tool/attachment processing.
- **Integration readiness gaps**: builders ask basic questions (Solana plugin usability, website embedding, mcp-gateway) with no canonical answers, suggesting documentation and reference apps are lagging behind feature velocity.
- **Community security incidents drive urgent work** (scams, migration confusion), highlighting that operational risk can outpace code risk.

---

## Recommendations: Process Improvements
1. **Convert Discord action items into tracked GitHub issues** (with labels `security`, `docs`, `community-ops`) within 24 hours; assign owners and deadlines.
2. **Add regression tests for message ingestion** (URLs, attachments, previews, multi-modal) and a CI check that asserts “1 inbound message ⇒ ≤1 LLM call” unless explicitly multi-step/tool-driven.
3. **Publish canonical “integration status” pages** per major plugin (Solana/EVM/MCP gateway): supported scenarios, reference examples, known limitations, and upgrade path.
4. **Security ops playbook**: pinned “official support policy”, standard scam response checklist, and restricted permissions for high-risk channels/threads.
5. **Architecture RFC requirement for trust/identity changes**: mandate a short RFC + threat model before adopting new identity layers, ensuring JWT/data isolation, plugin signing, and A2A trust are aligned rather than parallel tracks.