You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plugins currently consist of a single .so file placed in .plugins/native/. The plugin manifest (plugin.yml) lives separately in the source tree under plugins/native/<id>/ and is only used at build/packaging time. This creates a disconnect: at runtime, the server has no way to discover a plugin's declared asset types, models, or other metadata without a separate manifest file being present alongside the .so.
Problem
A bare .so file in .plugins/native/ has no associated manifest at runtime.
The plugin asset registration system (PR feat: plugin-driven asset registration system #253) requires plugin.yml to be read at load time to discover asset types. Currently this is handled during the initial spawn_load_existing scan and marketplace install, but local development plugins placed directly as .so files don't have their manifests available.
As plugins evolve to potentially include custom UI, models, and other resources, a single-file convention becomes increasingly limiting.
Proposal
Adopt a plugin directory convention where each plugin is a directory containing its artifacts:
This aligns with the marketplace bundle format (which is already a tar.gz containing both files) and provides a natural extension point for future plugin capabilities.
Migration path
Update the plugin loader to scan directories under .plugins/native/<id>/ instead of individual .so files.
Fall back to bare .so files for backward compatibility during a transition period.
Update the marketplace installer to extract bundles into the directory structure (it may already do this).
Update justfile build targets to output plugins into the directory structure.
Alternatives considered
Embed manifest in .so via C ABI: Plugin exposes a plugin_manifest() symbol. Single artifact, but requires ABI extension and doesn't work for WASM plugins.
Discussion from PR #253 (plugin-driven asset registration). The directory convention was identified as the natural evolution given that plugins will eventually become bundles that could ship custom UI.
Summary
Plugins currently consist of a single
.sofile placed in.plugins/native/. The plugin manifest (plugin.yml) lives separately in the source tree underplugins/native/<id>/and is only used at build/packaging time. This creates a disconnect: at runtime, the server has no way to discover a plugin's declared asset types, models, or other metadata without a separate manifest file being present alongside the.so.Problem
.sofile in.plugins/native/has no associated manifest at runtime.plugin.ymlto be read at load time to discover asset types. Currently this is handled during the initialspawn_load_existingscan and marketplace install, but local development plugins placed directly as.sofiles don't have their manifests available.Proposal
Adopt a plugin directory convention where each plugin is a directory containing its artifacts:
This aligns with the marketplace bundle format (which is already a tar.gz containing both files) and provides a natural extension point for future plugin capabilities.
Migration path
.plugins/native/<id>/instead of individual.sofiles..sofiles for backward compatibility during a transition period.justfilebuild targets to output plugins into the directory structure.Alternatives considered
.sovia C ABI: Plugin exposes aplugin_manifest()symbol. Single artifact, but requires ABI extension and doesn't work for WASM plugins..soembeds minimal metadata,plugin.ymlextends. More complex merge semantics.Context
Discussion from PR #253 (plugin-driven asset registration). The directory convention was identified as the natural evolution given that plugins will eventually become bundles that could ship custom UI.