Architecture Overview

mimOE is an operating environment for mims, serverless microservices, and AI Agents. Built on the Device-First Continuum (DFC) architecture, mimOE enables distributed applications that run directly on devices with seamless cloud escalation when needed.

What are mims?

mims (micro intelligence modules) are lightweight, serverless compute units that run on mimOE, from device to multi-cloud, without container overhead. Unlike traditional containers, mims are purpose-built for edge AI and distributed computing.

What is mimOE?

mimOE is a lightweight runtime that executes mims on devices such as smartphones, tablets, desktops, and embedded systems. Unlike traditional cloud-first architectures, mimOE implements a device-first approach where processing happens locally or on nearby devices, escalating to the cloud only when needed.

Core Characteristics

• Device-First Continuum: Processing starts on-device, with seamless escalation to cloud when needed.
• AI Agent runtime: Purpose-built environment for deploying and running AI Agents on-device.
• Serverless mims: Request-driven execution with automatic instance lifecycle management.
• Node-to-node communication: Devices discover and communicate directly without cloud intermediaries.
• Cross-platform: Runs on macOS, Linux, Windows, iOS, and Android.
• AI-ready: Built-in support for on-device ML inference with ONNX and GGUF models.

Device-First Continuum (DFC)

The Device-First Continuum represents a fundamental architectural shift from traditional cloud-centric computing.

Traditional Cloud-First Architecture

In cloud-first architectures:

• Data and processing happen in the cloud by default.
• Devices are thin clients that send requests to cloud servers.
• Edge computing is an optimization layer (caching, CDN).
• Offline capability is an afterthought.
• Every interaction requires internet connectivity.

Device-First Continuum Architecture

In the Device-First Continuum:

• Processing begins on the device where data originates.
• Devices are capable compute nodes, not just clients.
• Cloud services are available when needed (discovery, synchronization, and workloads that exceed local capacity).
• Devices can collaborate directly without cloud intermediaries.
• Offline-first is the default assumption.

The Continuum

DFC is not anti-cloud. It's about flexibility. Applications can operate anywhere on the continuum from fully local to fully cloud, based on the needs of each use case.

Example scenarios:

Scenario	Processing Location	Why
Private photo analysis	100% on-device	Privacy-sensitive data
Local device collaboration	Device mesh (P2P)	Low latency, no internet needed
Global user discovery	Cloud-assisted	Requires global coordination
Heavy ML training	Cloud offload	Exceeds device resources

A single application can use different points on the continuum for different operations.

Serverless-on-Device Architecture

mimOE implements a serverless execution model optimized for resource-constrained devices.

One Request, One mim Instance

Key principles:

1. On-Demand Instantiation: mims are created only when needed.
2. Request-Scoped Lifetime: Each instance lives for exactly one request.
3. Clean Termination: Instances are destroyed after response.
4. Memory Efficiency: Resources are immediately released.

State Management

mim instances are stateless across requests. Each instance is created on-demand and destroyed after the response is sent. This is a fundamental constraint of the serverless-on-device model.

For data that must persist, use:

• context.storage API (key-value database).
• External storage services.
• Client-side state management.

// ❌ WRONG - This will NOT work to retain data across calls
let requestCount = 0; // Lost after each request

export function handler(request, context) {
  requestCount++; // Always 1!
  return { count: requestCount };
}

// ✅ CORRECT - Use context.storage
export async function handler(request, context) {
  const count = await context.storage.get('requestCount') || 0;
  const newCount = count + 1;
  await context.storage.set('requestCount', newCount);
  return { count: newCount };
}

Runtime Components

mimOE consists of several integrated components:

1. Core Runtime

The core runtime handles:

• HTTP request routing.
• mim lifecycle management.
• Authentication and authorization.
• Resource monitoring and limits.

2. Execution Engines

mimOE supports two execution engines:

mimOE JavaScript Runtime

• ES5-compatible JavaScript engine.
• Lightweight and efficient.
• Full garbage collection.
• context object API injection.

WebAssembly (WASM)

• Standards-compliant WASM execution.
• Near-native performance.
• Custom import functions (not WASI).
• Memory-safe sandbox.

3. Built-in Services

Several services run alongside the core runtime:

MCM (mimik Compute Manager)

• Deploy and manage mims.
• Version control.
• Configuration management.

Model Registry (AI Foundation Package)

• Model registry and storage.
• ONNX and GGUF support.
• Model lifecycle management.

Inference Service (AI Foundation Package)

• On-device ML inference.
• Automatic model loading.
• Hardware acceleration when available.

Discovery & Networking (Mesh Foundation)

• Link local discovery (mDNS-based).
• Account-based discovery (via mDS cloud service).
• Proximity discovery (location-based).
• Tunneling service (NAT traversal).

Cross-Platform Architecture

mimOE is designed for true cross-platform deployment:

Desktop Platforms

• macOS: Native binary, standalone runtime.
• Linux: Native binary, standalone runtime.
• Windows: Native binary, standalone runtime.

Mobile Platforms

• iOS: Library integration within your application.
• Android: Library integration within your application.

Mobile Integration

On mobile platforms, mimOE runs as a library within your application, not as a standalone process. Example applications demonstrate the integration pattern.

Embedded Platforms

• QNX: Available through Enterprise Package.
• Custom RTOS: Available through Enterprise Package.

Enterprise Inquiries

For embedded platform support, contact mimik for Enterprise Package details.

Security Model

mimOE implements defense-in-depth security:

1. Authentication

• MCM API key: Auto-generated on first startup for deploying mims. See the MCM API reference for details.
• JWT access tokens: For clients that have completed this Account Association step.
• Addon API keys: Configurable per addon (AI Foundation, Mesh Foundation). See Addon Configuration.

2. Isolation

• Process isolation: mims run in isolated contexts.
• Memory safety: No direct memory access between services.
• Sandboxing: mims access the host system through context.* APIs only (HTTP, storage, info). See Design Trade-offs for details.

3. Encryption

• HTTPS/TLS: Supported for all network communication.
• Storage encryption: context.storage data encryption at rest is available when required.
• Token security: Secure token storage and rotation for mimOE platform services (mDS, authentication).

Platform Capabilities

What mimOE provides to your mims:

HTTP Client (context.http)

Make outbound HTTP requests to any endpoint:

const response = await context.http.get('https://api.example.com/data');

Persistent Storage (context.storage)

Key-value database for each mim:

await context.storage.set('userPrefs', { theme: 'dark' });
const prefs = await context.storage.get('userPrefs');

Discovery (Mesh Foundation)

Find and communicate with other mimOE nodes using the Mesh Foundation API:

curl -X GET "http://localhost:8083/mimik-mesh/insight/v1/nodes?type=linkLocal" \
  -H "Authorization: Bearer 1234"

Next Steps

Now that you understand the architecture, explore:

• Request Lifecycle: How requests are processed
• Design Trade-offs: Runtime design decisions for portability
• Getting Started: Set up your development environment
• JavaScript Development: Build your first mim