Plugins system

[SKOLIAK]

Edit for a better explanation.

Let users create custom plugins that extend or manage whatever they need while preserving updateability. This avoids modifying the Odysseus source code directly, making updates much easier and reducing merge conflicts.

Example use case

1. A user wants to integrate an agentic harness with custom planning, orchestration, or temporal memory.
2. They implement it as a plugin using a documented API instead of patching the core application.
3. Odysseus discovers and loads the plugin at startup (or enables it from Settings).
4. Future Odysseus updates don't overwrite or break the user's custom implementation, provided the plugin API remains stable.

Possible capabilities

• Another way to register custom tools.
• Hook into chat or agent events.
• Create background services or scheduled jobs.
• Add UI panels or settings pages.
• Register custom API endpoints.
• Package plugins in a dedicated plugins/ directory with versioning and dependency metadata.

A stable plugin API would encourage community extensions while keeping the core project maintainable and easier to update.

[SjoerdNijboer]

I believe I saw this in another request with a demand of an architectural refactor so that new plugins or integrations,

I'd prefer this as well.
A plugin ecosystem that works somewhat similar as say Jenkins server plugins would work great.
Jenkins plugins have their own DSL extensions in the rest of the application, which would be great for an AI Agent to interact with.
Everything where a user interacts with a Jenkins plugin is through the DSL first, and otherwise through GUI elements.
The Jenkins marketplace is also pretty cool in its dependency management however I'm not sure if something similar for Odysseus would work since Odysseus has the potential to integrate far far deeper and with much more complex systems.
I can foresee Odysseus integrations requiring a (docker) hosted component that might or might not be available on thesame computer.
A good plugin architecture should in principle be extendable to work with such an architecture.
Any plugin architecture worth its salt should also have crashes and vulnerability isolated to the plugin itsself, regardless if it's stateless or statefull.
For Agentic AI this requires a permissions system that's totally integrated with the AI harness as well.
Since the scope of what a plugin could be is huge, theoretically exists of all programs with GUIs and all programs without, this can become really complicated.
That easily spirals into requiring k8s for hosting simple plugins, which shouldn't be the case.

All with all I want to propose that any valid plugin architecture should concider the following architectural drivers:

• Unifying interaction with LLM's, including configuration(inspection) through LLM's.
• Proper isolation from the hardware it runs on.
• Fine-grained AI permission system for what are and what are not allowed actions for agentic AI to take.
• • Some good defaults should help here too. (Default read all, write none?)
• Some unified plugin store with single download/install buttons to retain the ease-of-use.
• Some way to host a plugin runner on a different PC. (either directly or through retianing that plugin the freedom to do so.)
• Loads and loads of plugins that are high-quality. (I wanna controll my smart-thermostat with AI.)

[SINE]

I'd like to add a few ideas I also had around a potential plugin ecosystem.

• Sub-menu to manage plugins
  • Search & install whitelisted and reviewed plugins
  • Allows to add alternative plugin review sources to the official Odysseus one
  • Optional local override for whitelist plugins. To see them even if not officially reviewed (allows commit-pinned whitelisting)
  • Warning in the UI if any requirements have known vulnerabilities
    • Auto-check CVEs on a regular basis. This could also be useful for Odysseus own requirements.
    • Option to auto-disable plugins that rely on vulnerable requirements
  • Architecture
    • For plugin publishers
      • The plugin must have a manifest
        • The internal plugin version
        • Which Odysseus version it was last tested with/developed for
        • If the plugin alters existing Odysseus functionality
          • Checklist which parts of Odysseus are being altered
            • UI
            • Settings
            • Deep Research
            • etc.
        • If the plugin is tested as compatible with Docker, Windows, Linux, Mac, etc.
      • The GitHub repository for the plugin must have some sort of GitHub action that validated various standards are upheld.
        • Checks for malicious code
        • Checks for vulnerable dependencies
        • Python requirements can only be officially approved python modules, that are well maintained.
    • For Odysseus
      • A plugin whitelist managed by the repository maintainers
      • New plugins can be added using a pull-request (simple text file with list of plugins and commit hash pinning)
      • A GitHub action to check all reviewed or whitelisted repositories
        • Check if their manifest claims are correct
        • Mark whatever commit of the repository as reviewed, rather than the repository itself
      • A plugin repository owner and repository blacklist
      • A plugin reputation system.

[SINE]

Nevermind. I'm late to the party. Which is apparently here https://github.com/pewdiepie-archdaemon/odysseus/discussions/4439