Skip to content

Plugin Trust Model

Jump to bottom
Bobby Comet edited this page Aug 3, 2026 · 2 revisions

Plugin Trust Model

Conky Studio uses a declarative plugin system designed to expand the node ecosystem while keeping the core application stable.

Plugins are JSON-based definitions that describe nodes, properties, sockets, and code generation behavior. They are interpreted by Conky Studio rather than executed as application code.

This means community plugins can add functionality without having permission to modify the Studio editor itself.

How plugins work

A plugin provides a definition that tells Studio:

  • What nodes exist
  • Which category they belong to
  • What inputs and outputs they expose
  • Which properties appear in the editor
  • What data types they accept
  • How they generate Conky/Lua output

Example workflow:

Plugin JSON
      ↓
Conky Studio loads definition
      ↓
Node appears in palette
      ↓
User builds graph
      ↓
Studio generates normal Conky files

Plugins become part of the node language, not part of the application runtime.

Trust levels

Conky Studio separates plugins into two categories.

Official Plugins

Official plugins are maintained and distributed by the Conky Studio project.

They are:

  • Tested with supported Studio versions
  • Reviewed before inclusion
  • Distributed through the official plugin catalog
  • Expected to maintain compatibility with the current node system

Official plugins are the recommended source for users who want a curated experience.

The Planned Community Store Plugins

Community plugins will allow users to create and share their own nodes.

They can add:

  • New visual nodes
  • New data sources (future feature)
  • New logic nodes
  • And node properties

Community plugins use the same JSON format as official plugins.

However, they are not automatically considered part of the official Studio ecosystem.

Users should review community plugins before installing them.

Why plugins do not run Python code

Conky Studio intentionally does not allow plugins to directly modify the application through Python.

A Python plugin system would allow plugins to:

  • Change the editor workflow
  • Modify the user interface
  • Access Studio internals
  • Alter project behavior
  • Potentially execute arbitrary code

While this would provide more flexibility, it would also create a much larger compatibility and security burden.

Instead, Conky Studio keeps a clear boundary:

Plugin JSON
     ↓
Adds nodes and capabilities

Studio Core
     ↓
Controls editor, workflow, and project system

What plugins can do

Plugins can:

✅ Add new nodes ✅ Add custom properties ✅ Define sockets and data types ✅ Extend visual, source, and logic categories ✅ Generate additional Conky/Lua output

What plugins cannot do

Plugins cannot:

❌ Rewrite the Studio interface ❌ Modify the editor workflow ❌ Replace core systems ❌ Execute arbitrary application code ❌ Change how projects are stored

Plugin evolution

Conky Studio treats plugins as an incubation system.

A feature may start as a plugin:

Official/Community/Experimental Plugin
             ↓
       Tested in real projects
             ↓
       Evaluated for usefulness
             ↓
     Possible core integration

Features that become fundamental to the node system may eventually move into the core application.

Features that are specialized or niche remain plugins.

This keeps the core stable while allowing the ecosystem to grow.

Design philosophy

Conky Studio follows a simple rule:

Plugins should expand what users can create, not change what Conky Studio is.

The core defines the language. Plugins expand the vocabulary.

Clone this wiki locally