## ElizaOS Developer Update (2025-12-14 → 2025-12-18)

This update summarizes the most relevant engineering changes and discussions across the ElizaOS monorepo and plugin ecosystem, plus actionable notes from Discord development threads.

---

## 1) Core Framework

### Unified runtime message entrypoint (serverless-friendly)
The monorepo has been moving toward a single “send/handle message” surface area to reduce divergence between server, serverless, and standalone examples. The key enabling work is the **Unified API** added to `@elizaos/core` ([PR #6201](https://github.com/elizaos/eliza/pull/6201)). This consolidates message execution paths and makes it easier to embed ElizaOS in serverless Node.js environments without pulling in the full server package set.

### Migration away from legacy event-based message handling
Examples and plugins are being updated from the deprecated `MESSAGE_RECEIVED` event flow to `messageService.handleMessage()` ([PR #6202](https://github.com/elizaos/eliza/pull/6202)). This is important because newer features (notably streaming + action execution UX) depend on consistent message lifecycle hooks.

```ts
// New pattern (preferred)
await runtime.messageService.handleMessage({
  // ...message payload...
});

// Old pattern (deprecated; avoid in new code)
runtime.emit("MESSAGE_RECEIVED", message);
```

### SQL plugin stabilization + idempotent migrations
If you maintain deployments that span older schema versions (pre-1.6.5 camelCase), the SQL plugin received a major migration hardening pass to ensure upgrades are safe, repeatable, and compatible with RLS (Row Level Security) setups:  
- [PR #6215](https://github.com/elizaos/eliza/pull/6215) — smooth pre-1.6.5 → 1.6.5+ migration, RLS handling, SQL organization, expanded test coverage  
- [PR #6202](https://github.com/elizaos/eliza/pull/6202) — auto-create PGLite directories + migration to `messageService` API

This work is directly relevant to recent Discord support threads about local Postgres migration failures (permissions / migrations getting stuck). If you’re still seeing failures, confirm you’re on a build including these changes and re-run migrations from a clean state.

---

## 2) New Features

### CLI: ElizaOS Cloud as the default model/provider path
The CLI now treats **ElizaOS Cloud** as the first/recommended provider and adds a browser-based login flow to provision API keys more seamlessly ([PR #6208](https://github.com/elizaos/eliza/pull/6208)).

This impacts developer onboarding and automation scripts: if your tooling assumed OpenAI-first prompts, you may need to update docs or team instructions.

### Server: JWT authentication + multi-tenant entity isolation (in progress)
A full JWT verification system (Ed25519 / JWKS / HS256 “secret” modes) has been implemented behind a feature flag and is currently in an open PR:  
- [PR #6200](https://github.com/elizaos/eliza/pull/6200) — `ENABLE_DATA_ISOLATION=true` enables JWT-required mode and derives `entityId` from `sub`.

If you’re building hosted multi-tenant apps on top of ElizaOS server APIs, track this PR closely; it’s the foundation for ACLs and true tenant isolation.

### Streaming: runtime + cloud streaming now works for simple messages/actions (UX still pending)
Core dev discussion confirms streaming is working for:
- “simple messages”
- “actions” (execution path streams correctly)

…but **Actions UI rendering** still displays all-at-once instead of incremental token streaming (Discord dev note, 2025-12-16/17). There are PRs in both `eliza-cloud-v2` and the monorepo referenced by the team (links not included in this dataset). If you’re building custom UIs, you can already wire token events; the remaining gap is the bundled Actions UI behavior.

### Plugin authoring: extending agent actions (Starknet plugin workflow)
Discord guidance this week clarified the expected steps to extend a plugin with new actions:
1) Clone the plugin repo into the monorepo `packages/` folder (if it isn’t present locally).
2) Add a new action file under the plugin’s `actions/` directory.
3) Export/register it from the plugin’s `src/index.ts`.

Docs reference: https://docs.elizaos.ai/plugins/components

Example action skeleton:

```ts
// packages/plugin-starknet/src/actions/zpaceship.ts
import type { Action } from "@elizaos/core";

export const zpaceship: Action = {
  name: "zpaceship",
  description: "Example action added by a plugin author",
  // schema: z.object({ ... }) // if your plugin uses validation
  handler: async (runtime, message, state) => {
    // implement Starknet calls / side-effects here
    return {
      text: "zpaceship executed",
      data: { ok: true },
    };
  },
};
```

```ts
// packages/plugin-starknet/src/index.ts
import { zpaceship } from "./actions/zpaceship";

export const plugin = {
  name: "plugin-starknet",
  actions: [
    zpaceship,
    // ...other actions
  ],
};
```

---

## 3) Bug Fixes (critical / high-impact)

### UI: edit-mode chat suggestions triggering agent responses
A bug where “edit mode” suggestion interactions could trigger actual agent responses was closed:  
- [Issue #6243](https://github.com/elizaOS/eliza/issues/6243) (closed)

Impact: prevents accidental agent execution / message dispatch while users are editing or previewing suggestions. If you maintain forks with custom suggestion components, ensure you replicate the fix: suggestion selection in edit contexts must not dispatch into the live runtime message pipeline.

### UI: avatar mismatch between edit view and sidebar
Visual mismatch bug closed:  
- [Issue #6242](https://github.com/elizaOS/eliza/issues/6242) (closed)

Impact: reduces confusion when editing a character/profile and validating which agent identity is currently active. This matters for multi-agent dashboards where identity drift creates incorrect operator actions.

### UX terminology: replacing “RAG” with plain language
Terminology change issue closed:  
- [Issue #6240](https://github.com/elizaOS/eliza/issues/6240) (closed)

This is part of a broader UX simplification wave (see also “Knowledge → Files” [#6237](https://github.com/elizaOS/eliza/issues/6237), “Services instead of MCP” [#6241](https://github.com/elizaOS/eliza/issues/6241)). If you expose these terms in plugin UIs or docs, align language to avoid confusing end users and to match upcoming UI.

---

## 4) API Changes (developer-facing)

### `messageService.handleMessage()` is now the preferred entrypoint
While not a single hard-breaking API removal this week, the ecosystem direction is clear: plugins/examples should use `messageService.handleMessage()` instead of legacy event emission patterns ([PR #6202](https://github.com/elizaos/eliza/pull/6202)). This affects:
- standalone examples
- plugin integration tests
- custom message server adapters

### CLI test harness signature alignment
The CLI’s end-to-end tests were failing due to a `startAgents` signature mismatch and were fixed:  
- [PR #6207](https://github.com/elizaos/eliza/pull/6207)

If you vendor or emulate CLI e2e harness code in CI, pull this change to avoid phantom failures.

### Dependency ecosystem update (drizzle compatibility)
A repo-wide dependency update addressed conflicting `drizzle-orm` versions and related tooling compatibility:  
- [PR #6210](https://github.com/elizaos/eliza/pull/6210)

If you maintain private plugins depending on `drizzle-orm`, re-check peer dependency ranges and lockfile behavior after updating.

---

## 5) Social Media Integrations (Twitter / Telegram / Discord / Farcaster)

### Discord plugin: large PR ready to merge
A long-running Discord plugin PR is flagged as merge-ready but large (66 commits) and awaiting final review:  
- https://github.com/elizaos-plugins/plugin-discord/pull/30

Additionally, there is ongoing refactor work mentioned in weekly contributor summaries:
- `elizaos-plugins/plugin-discord#32` (open; refactor toward unified messaging API—PR number referenced in contributor activity summary, link not present in dataset)

Recommendation: if you’re integrating Discord in production, pin to a known-good commit and test against your gateway intents + message update events before fast-forwarding to the merged mega-PR.

### Telegram plugin: refactor in progress + Railway fix
Contributor summaries mention:
- `elizaos-plugins/plugin-telegram#22` (open; refactor/unified messaging path—link not present in dataset)
- Telegram bot Railway fix PR exists in the monorepo: [PR #6214](https://github.com/elizaos/eliza/pull/6214) (referenced by contributor summary; ensure your Railway deploy uses updated config)

### Farcaster: local hub plugin added to registry
A new Farcaster-related plugin entry landed in the registry:
- `elizaos-plugins/registry#243` (added `plugin-farcaster-local-hub`; link not included in dataset summary, but PR number is)

---

## 6) Model Provider Updates

### Cloud-first provider selection in CLI
As noted above, the CLI now nudges new projects to ElizaOS Cloud by default ([PR #6208](https://github.com/elizaos/eliza/pull/6208)). This is the most meaningful provider-related developer change this week: onboarding, environment variables, and “first run” behavior may differ from prior OpenAI-centric expectations.

### DeepSeek API request closed (status: not tracked as active work)
A previously requested DeepSeek API capability was closed earlier this month:
- [Issue #6156](https://github.com/elizaos/eliza/issues/6156)

If you need DeepSeek today, confirm whether you can use it via an OpenAI-compatible endpoint configuration or a custom provider plugin; otherwise, expect to implement a provider adapter.

---

## 7) Breaking Changes / V1 → V2 Migration Warnings

### Action + message lifecycle expectations are tightening
If you’re migrating older agents/plugins (or maintaining internal forks), watch for these “soft breaks” that commonly surface as runtime behavior bugs rather than compile errors:

1) **Legacy message events vs `messageService.handleMessage()`**  
   - Old event hooks may no longer fire in the same order (or at all) as newer components expect.  
   - Symptoms: actions not running, streaming not emitting, or UI not updating.

2) **SQL schema upgrades across pre-1.6.5 installs**  
   - If you skipped multiple versions, rely on the hardened migrations in [PR #6215](https://github.com/elizaos/eliza/pull/6215).  
   - Symptoms: migration loops, missing columns/tables, RLS policy mismatches.

3) **Auth mode bifurcation (legacy header vs JWT)**
   - If/when [PR #6200](https://github.com/elizaos/eliza/pull/6200) merges, deployments enabling `ENABLE_DATA_ISOLATION=true` will require JWT-bearing clients.  
   - Symptoms: 401s on previously working API calls; Socket.IO auth failures.

### Token migration issues are not software breaking changes, but do impact developer ops
Discord reports continued confusion due to exchange-specific handling differences (Bithumb vs Kraken) for AI16Z → ELIZAOS. While not an ElizaOS runtime change, it affects developer/community support load and operational guidance. If you maintain tooling/docs that mention migration flows, ensure you clearly separate:
- on-chain migration capability (confirmed still possible on Solana)
- centralized exchange snapshot/distribution behavior (exchange-controlled)

---

### References / Links
- Discord plugin mega-PR: https://github.com/elizaos-plugins/plugin-discord/pull/30  
- Plugin components & actions docs: https://docs.elizaos.ai/plugins/components  
- Unified API (serverless Node.js): https://github.com/elizaos/eliza/pull/6201  
- SQL plugin: messageService migration + PGLite dir creation: https://github.com/elizaos/eliza/pull/6202  
- SQL plugin: pre-1.6.5 migration + RLS + tests: https://github.com/elizaos/eliza/pull/6215  
- CLI: Cloud as default provider: https://github.com/elizaos/eliza/pull/6208  
- CLI: e2e test signature fix: https://github.com/elizaos/eliza/pull/6207  
- Auth (JWT / data isolation) PR (open): https://github.com/elizaos/eliza/pull/6200  
- Closed UI/UX issues:  
  - https://github.com/elizaOS/eliza/issues/6243  
  - https://github.com/elizaOS/eliza/issues/6242  
  - https://github.com/elizaOS/eliza/issues/6240