Plugin Marketplace

The Spirefy marketplace is where you find plugins and where authors publish them. The same plugin format runs in the desktop app and from the spirefy command line, so a plugin you install for interactive work is the same one you can run headlessly in a script.

The plugin engine, the package format, the signing pipeline, the public index, the in-app browse-and-install flow, and author payouts all work as one path: build a plugin, sign it, publish it, and it is installable the same minute. The sections below describe how it works.

Find and install

Browse by category (importers, exporters, curation engines, pages, and tools), search by name, or filter by the interface a plugin provides. Each listing shows what the plugin does, the interface it targets, and the capabilities it requests, so you know what it can reach before you install it.

Installing is one step in the app, or one command from the CLI.

spirefy search openapi
spirefy install <publisher>/<plugin>
spirefy install <publisher>/<plugin>@1.2.0

Publish a plugin

Publishing is the same four steps you already use to build a plugin, with one more at the end.

spirefy init my-plugin --lang=zig   # scaffold a project
spirefy build                       # compile to WebAssembly
spirefy pack                        # package it for distribution
spirefy verify ./my-plugin-0.1.0.zp # check the signature
spirefy publish                     # sign and submit to the marketplace

On publish, the marketplace validates the package, records its version and dependencies, and lists it. You manage versions and releases from a publisher view; older versions stay available so installs do not break.

Typed by its interface

This is what makes the marketplace more than a file host. Every plugin carries its WIT, the typed contract of what it provides and what it needs. On publish, the marketplace reads that WIT and indexes the plugin by interface.

Two things follow. First, discovery is by capability: search for an interface, for example a storage provider or an OpenAPI importer, and you find every plugin that implements it. Second, compatibility is checked up front: the engine knows whether a plugin’s contract matches the app or plugin that wants to consume it, so a mismatch is caught before install rather than at runtime.

Charge for your work

List a plugin at no cost, or set a price. Authors earn an 80 percent revenue share that rises to 90 percent as a plugin reaches a larger audience, and payouts are handled through Stripe Connect so you do not run billing yourself.

You are not limited to the public market. Keep a plugin internal and proprietary to your organization, so your team gets it without it ever being listed. Both paths use the same format and the same signing.

Signed and verified

Every plugin is signed with ML-DSA-65 (NIST FIPS 204, post-quantum). The signature is verified before the plugin’s code is decompressed, so a tampered package never runs. Signing happens as part of spirefy publish, and the engine records a SHA-256 hash of every plugin file it loads.

Capabilities you can see

Plugins run in WebAssembly sandboxes with explicit capability grants. A plugin declares the hosts, files, and variables it needs, and you approve them at install. After that, the plugin reaches only what it declared and you allowed.

# A plugin declares what it needs; you see this before installing
capabilities:
  http:
    enabled: true
    allowed_hosts:
      - "api.example.com"
  filesystem:
    enabled: false

Versioning and dependencies

Plugins use semantic versioning and can declare dependencies on other plugins by interface and version. The engine resolves what a plugin needs at install, and keeps versions side by side so an update never silently breaks a workflow that relied on the old one.