Plugin Configuration

YedMQ's plugin system is process-based. The broker discovers plugin directories, starts child processes, and communicates with them over a local socket.

Broker-side settings

[plugin]
dir = "./plugins"
local_socket_path = "/tmp/yedmq_plugin.sock"
default_authorize_result = true
default_authenticate_result = true

Configuration Item	Description
dir	Root directory scanned for plugin subdirectories. Each plugin must live in its own first-level directory.
local_socket_path	Local IPC address used between the broker and plugin host. On Windows you can use a named-pipe style path or let YedMQ derive one from the configured value.
default_authorize_result	Fallback authorization result when no plugin answers the request.
default_authenticate_result	Fallback authentication result when no plugin answers the request.

Directory layout

plugins/
  my-plugin/
    plugin.toml
    my-plugin

The directory name should match plugin.name in practice, because the current loader resolves the runtime executable relative to that plugin directory.

Plugin manifest

[plugin]
name = "my-plugin"
version = "0.1.0"
description = "Example YedMQ plugin"
author = "Your Name"
license = "Apache-2.0"

[runtime]
type = "process"
executable = "my-plugin"
working_dir = "."
timeout_secs = 12

Runtime notes

• Only process runtime is supported today.
• The executable path is resolved relative to the plugin directory.
• Plugins connect back to the host over the configured local socket.
• The current runtime uses built-in request and heartbeat timeouts, so timeout_secs should be treated as descriptive metadata rather than a complete runtime policy switch.

Current integration model

Plugins declare hooks during initialization, and YedMQ orders them by priority. The current broker-side integration focuses on:

• authentication
• authorization
• message publish handling
• disconnect and related event-style flows

For protocol details and hook definitions, continue with the Plugin Developer Guide.