Building Plugins
This section is for developers building Mydia plugins. If you just want to use a plugin someone else wrote, install and configure it as an operator; you do not need any of this.
Mydia plugins are small, sandboxed programs that react to what happens in your library. When a movie is added, a download completes, a file is imported, or someone finishes watching something, Mydia hands the event to your plugin and lets it do something useful: post a notification, call an external API, enrich the event with library data. Plugins can also run on a fixed schedule, keep a little durable state, link a per-user third-party account, and sync watched state both ways. The bundled Simkl plugin does all of this.
A plugin is a WebAssembly component written in Rust against the
mydia-plugin-sdk crate. You write one typed handler function; the SDK turns it
into a component the host can load. The plugin runs in a sandbox with no ambient
network, filesystem, or OS access. The only way out is through a small set of
capability-gated host functions you declare up front. Operators approve what a
third-party plugin may do before it runs, while plugins bundled with Mydia get
their declared permissions on discovery; the plugin model
explains the trust rules.
Where to start
-
New to plugins
Follow the tutorial and have a working plugin logging on
media_item.addedin about 10 minutes. -
Have a specific task
The how-to guides cover sending notifications, reading media and event data, building a two-way sync, custom pages, home shelves, a setup wizard, and the test and iterate loop. To distribute plugins yourself, see publishing your own plugin source.
-
Need the contract
The manifest, events, capabilities, host functions, guest exports, limits and plugin source format pages cover the runtime contract.
-
Want to know why
The plugin model explains the sandbox, the capability system, and what the host-version floor is for, including its current limitations.