Skip to main content
Yazi’s Data Distribution Service (DDS) provides a built-in publish-subscribe system that enables communication between multiple Yazi instances and plugins. It’s built on a client-server architecture with no additional server process required.

Overview

DDS enables:
  • Cross-instance communication - Share data between multiple Yazi instances
  • State persistence - Maintain state across all instances
  • Plugin messaging - Plugins can publish and subscribe to events
  • Lua integration - Full Lua API for pub/sub operations
  • Automatic discovery - Instances find each other automatically

Architecture

DDS uses a hybrid client-server model:
  • First instance - Starts DDS server automatically
  • Additional instances - Connect as clients to existing server
  • No separate daemon - Server embedded in first Yazi process
  • Unix socket - Communication via filesystem socket

Message Types (Embers)

DDS messages are called “embers” and include:

System Events

  • hi - Client announces capabilities
  • hey - Server broadcasts peer list
  • bye - Client disconnects gracefully

File Events

  • cd - Directory change
  • load - Folder loading complete
  • hover - File hover/selection
  • rename - File renamed
  • move - Files moved
  • duplicate - Files duplicated
  • trash - Files moved to trash
  • delete - Files permanently deleted
  • download - Remote files downloaded

Special Events

  • yank - Files yanked to clipboard (cut/copy)
  • bulk - Bulk file changes
  • tab - Tab switched
  • mount - Filesystem mounted/unmounted
  • custom - User-defined events

Client-Server Implementation

The DDS system is implemented in yazi-dds/:

Server

The server (yazi-dds/src/server.rs:17) manages connections:

Client

Clients (yazi-dds/src/client.rs:34) connect and communicate:

Publish-Subscribe API

The pub/sub system (yazi-dds/src/pubsub.rs) provides:

Subscribe (Local)

Subscribe to events in the current instance:

Subscribe (Remote)

Subscribe to events from all instances:

Publish

Send events to subscribers:

Unsubscribe

Built-in Event Publishing

Yazi automatically publishes events using the pub_after_* pattern:
This ensures events are:
  1. Delivered locally if subscribed
  2. Broadcast to remote peers if they subscribe
  3. Persisted if static event

State Persistence

Static events (prefixed with @) are persisted:
When new clients connect, they receive all persisted state:
This enables:
  • Shared clipboard - Yank state synced across instances
  • Plugin state - Persistent data between restarts
  • Configuration sync - Runtime config changes propagated

Peer Discovery

Instances track each other via hey messages:
Each instance knows:
  • Peer IDs - Unique identifier for each instance
  • Capabilities - What events each peer can receive
  • Connection status - When peers join/leave

Ya CLI Integration

The ya command-line tool uses DDS to communicate with running instances:

Send Single Message

Implemented in yazi-dds/src/client.rs:81:

Listen to Events

Implemented in yazi-dds/src/client.rs:141:

Connection Management

Automatic Reconnection

Clients automatically reconnect if connection lost:

Heartbeat

Server sends periodic heartbeats to detect dead connections:

Graceful Shutdown

Clients send bye message before disconnecting:

Environment Variables

DDS sets environment variables for child processes:
This enables:
  • Nested detection - Know if running inside another Yazi
  • Parent tracking - Find parent Yazi instance
  • Nesting level - Track recursion depth

Version Compatibility

DDS checks version compatibility:
This prevents communication errors between different Yazi versions.

Plugin Examples

Cross-Instance Notification

Synchronized State

File Synchronization

Performance

DDS is designed for efficiency:
  • Async I/O - Non-blocking communication
  • Unix sockets - Fast local IPC
  • Binary format - Compact message encoding
  • Connection pooling - Reuse connections
  • Selective delivery - Only send to interested peers

Debugging

Monitor DDS activity:

Security Considerations

  • Local only - Unix socket accessible only to same user
  • No authentication - Processes under same UID trusted
  • No encryption - Data not encrypted (local socket)

See Also