# ElizaOS Developer Update - August 25, 2025

## Core Framework

This week marked significant improvements to ElizaOS's core infrastructure with the migration from LocalStack to MinIO for storage, addressing a critical persistence issue where LocalStack was wiping buckets on every container restart. This change provides more reliable storage for agents and has been fully integrated with the image generation flow, which now saves directly to the gallery.

The runtime received a valuable enhancement with the addition of the `getServiceLoadPromise` interface, allowing developers to more effectively manage service dependencies and initialization order. Component queries in `plugin-sql` were also made more flexible, improving the robustness of database interactions.

A cross-environment logger refactoring ensures the logger module now functions seamlessly across both browser and Node.js environments, supporting ElizaOS's cross-platform strategy.

```typescript
// Example of the new getServiceLoadPromise API
const myService = runtime.getServiceLoadPromise('myServiceName');
await myService; // Wait for service to be fully loaded
// Now safely use the service
```

## New Features

### Tools Plugin with OAuth Integration

A significant new tools plugin has been developed that enables OAuth-based connections and disconnections with full multi-connection support. This system provides:

- Dedicated authentication for each user per tool
- Plan/dependency graph analysis for determining required tools
- Tool-chaining based on user requests
- Context persistence through a provider for previous tool executions

```typescript
// Example of registering a tool with OAuth requirements
runtime.registerTool({
  name: 'github',
  description: 'Interact with GitHub repositories',
  authType: 'oauth',
  authConfig: {
    authUrl: 'https://github.com/login/oauth/authorize',
    tokenUrl: 'https://github.com/login/oauth/access_token',
    clientId: process.env.GITHUB_CLIENT_ID,
    clientSecret: process.env.GITHUB_CLIENT_SECRET,
    scopes: ['repo', 'user']
  },
  execute: async (params, context) => {
    // Implementation using authenticated client
  }
});
```

### Sessions API

Work has continued on the new Sessions API, which now features comprehensive timeout management, auto-renewal capabilities, and robust error handling. This API provides developers with greater control over user sessions and simplifies the messaging process between users and agents.

```typescript
// Example of creating and using a session
const session = await sessionsApi.createSession({
  agentId: 'agent-uuid',
  userId: 'user-uuid',
  metadata: { ethAddress: '0x123...' }
});

// Send a message using the session
await sessionsApi.sendMessage(session.id, {
  content: 'Hello agent!',
  type: 'text'
});

// Receive messages
const messages = await sessionsApi.getMessages(session.id);
```

### Asynchronous Embedding Generation

A significant performance improvement has been implemented with asynchronous embedding generation via a queue service. Previously, embedding generation was blocking the runtime for 500ms+ per message, creating noticeable latency. With this change, the embedding process is now offloaded to a background queue, allowing the agent to continue processing without delay.

```typescript
// Example of how the system now processes embeddings asynchronously
runtime.on('message:received', async (message) => {
  // Immediately queue embedding generation without blocking
  embeddingService.queueEmbedding(message);
  
  // Continue processing the message without waiting
  await runtime.processMessage(message);
});
```

## Bug Fixes

Several critical bugs were resolved this week:

1. **Entity Creation SQL Error**: Fixed a database error during entity creation where SQL parameter counts were mismatched, causing queries to fail.

2. **Plugin Compatibility Issues**: Identified and documented compatibility issues between certain plugins (particularly Telegram) and specific AI models (Local AI/Ollama). Users attempting to use these combinations now receive clear guidance.

3. **Publisher Module**: Corrected a bug related to comma placement in `index.json` when adding new plugin entries to the registry, improving the reliability of the publishing process.

4. **TEE Integration**: Resolved argument handling issues in the Phala CLI wrapper and fixed the `tee` starter Docker build, restoring full functionality to the `tee` command.

## API Changes

The plugin-sql component queries have been refactored to be more flexible, allowing for more natural handling of date fields and improving compatibility with different database backends. Previously strict parameter requirements have been relaxed to provide a more developer-friendly interface.

The Sessions API has been enhanced to propagate metadata throughout the message processing pipeline, enabling plugins and actions to access custom session metadata like `ethAddress` or other user-specific information.

## Social Media Integrations

Users discovered compatibility issues between the Telegram plugin and certain AI models, specifically Local AI/Ollama. When using these models, the Telegram plugin fails to initialize properly. A workaround has been identified: switching to Anthropic for AI and OpenAI for embedding resolves the issue. This limitation has been documented and will be addressed in a future update.

Additionally, work continues on integrating with Ethereum networks through the EIP 8004 standard, which was discussed in a session with the Ethereum Foundation and Metamask. This will eventually enable more sophisticated Web3 integrations across social platforms.

## Model Provider Updates

We've identified that when using Local AI (Ollama) as the primary AI model, certain plugins have compatibility issues. The issue appears to be related to how these models handle plugin initialization and embedding generation. As a temporary solution, users should:

1. Use OpenAI or Anthropic for embedding generation when working with Local AI models
2. Consider using a different AI provider if you need full plugin compatibility
3. Check plugin documentation for specific model compatibility notes

## Breaking Changes

While the migration from LocalStack to MinIO for storage improves reliability, it introduces a potential breaking change for developers who were directly interacting with the storage backend. If you were:

1. Manually configuring LocalStack storage in custom deployments
2. Directly accessing storage buckets through the LocalStack API
3. Using custom scripts that assume LocalStack's specific behavior

You'll need to update your code to work with MinIO instead. The core API remains the same, but connection parameters and some behavioral aspects differ. Key differences include:

```javascript
// OLD: LocalStack configuration
const storageConfig = {
  endpoint: 'http://localhost:4566',
  forcePathStyle: true
};

// NEW: MinIO configuration
const storageConfig = {
  endpoint: 'http://localhost:9000',
  forcePathStyle: true,
  credentials: {
    accessKeyId: 'minioadmin',
    secretAccessKey: 'minioadmin'
  }
};
```

Full migration documentation is available in the updated storage service documentation.