Publishing

Once a plugin works locally, you publish it by packaging a signed release, hosting it somewhere you control, and adding an entry to an index. StreamNook never hosts plugin artifacts. Authors do. The index just points at your files and pins your key.

The signing scheme, the full index.json field reference, and how key pinning works in detail live in Signing and the index format. This page is the workflow that uses them.

Which index

The official index is the streamnook-plugins repository.

Your tier (declared in the manifest, verified by the curator) decides where you can be listed. You cannot self-certify into a lower tier. See the tier table in The manifest.

Publish a release

minisign -G

my-plugin-1.0.0.zip
├── plugin.toml
├── my-plugin.exe     (or dist/main.js for a ui plugin)
└── assets/

minisign -Sm my-plugin-1.0.0.zip
certutil -hashfile my-plugin-1.0.0.zip SHA256

{
  "id": "yourhandle.my-plugin",
  "name": "My Plugin",
  "version": "1.0.0",
  "tier": "A",
  "description": "One or two plain sentences about what it does.",
  "homepage": "https://github.com/yourhandle/my-plugin",
  "host_min": "8.0.0",
  "released_at": "2026-06-10T00:00:00Z",
  "author": {
    "name": "yourhandle",
    "pubkey": "RW...your minisign public key..."
  },
  "artifact": {
    "url": "https://github.com/yourhandle/my-plugin/releases/download/v1.0.0/my-plugin-1.0.0.zip",
    "sha256": "...",
    "signature_url": "https://github.com/yourhandle/my-plugin/releases/download/v1.0.0/my-plugin-1.0.0.zip.minisig"
  }
}

"icon_url":   "https://raw.githubusercontent.com/yourhandle/my-plugin/main/assets/icon.png",
"readme_url": "https://raw.githubusercontent.com/yourhandle/my-plugin/main/README.md"

Multi-platform builds

A process plugin is a native binary, so ship one build per OS. An index entry can carry a platforms map keyed by <os>-<arch>, each with its own url, hash, size, and signature. The supported keys are:

The host installs the build matching the user's platform and shows the plugin as unavailable where there is no build. id, version, and tier must be identical across platforms.

A ui plugin is one artifact everywhere, so it needs no platforms map. The full shape is in Signing and the index format.

Updating and rotating keys

Ship a new version by uploading a new signed zip and opening a PR that bumps version, artifact, and updated_at.

An update that requests new capabilities re-runs the consent flow on the user's machine. Adding capabilities is a visible event, not a silent one.

Rotating your key

If you must change your key, the index entry lists the old key in previous_pubkeys, and the artifact carries a second signature by the old key (<artifact>.minisig.prev). With that rotation proof the host re-pins silently.

Without the proof, the update is blocked for everyone who has your plugin installed, and they see a prominent warning naming both fingerprints. So guard your key, and if you rotate, provide the proof.

Pre-publish checklist

• id is a unique lowercase dotted id (e.g. yourhandle.my-plugin), not under app.streamnook.
• version bumped (semver) since the last release
• [capabilities] lists only what the plugin actually uses
• network honestly reflects whether the plugin connects out
• tier matches what the plugin does
• host_min set to the lowest StreamNook version you tested against
• Plugin responds to initialize fast, answers ping, handles shutdown/exit (process kind)
• Plugin degrades cleanly when a capability is denied or a credential is revoked
• ui bundle aliases react, react/jsx-runtime, framer-motion to the host shims
• README leads with what it does and a screenshot
• Zip has plugin.toml at the root, signed with minisign, SHA-256 computed
• Artifact and .minisig hosted at stable URLs you control
• Index entry matches the manifest exactly

Related