Publishing to the registry

The Mixlar registry is where community plugins live. It’s a public GitHub repository (MixlarLabs/mixlar-plugins) that the desktop app reads to populate Discover. You never push to it directly — you publish through the SDK (or the Studio), and Mixlar signs approved plugins on your behalf.

Tip

You never hold a signing key for the registry. Identity is bound to your mixlar.net account at publish time — only the account that owns an author handle can publish under it (“only obvert can upload as obvert”). Mixlar signs approved plugins with the mixlar-registry-1 key, whose private half exists only as a CI secret.

The flow

1. Sign in to your mixlar.net account:

   mixlar-sdk login

   This opens your browser to the device-link page. Once you sign in there, the CLI stores a token locally. Check it any time with mixlar-sdk login --status.

2. Check your plugin id is free (also done by the create wizard):

   mixlar-sdk name-check my_cool_plugin

   HTTP-style result: available, taken, or unknown (registry unreachable).

3. Declare your permissions in plugin.json and scan (see Security & permissions):

   mixlar-sdk scan

4. Accept the developer agreement (once) — the no-malware honor pledge:

   mixlar-sdk agree

5. Publish:

   mixlar-sdk publish

What happens after publish

publish packs your folder into a deterministic .mixplugin and uploads it. The registry then:

1. Binds the author — the manifest author must match the author handle your account owns (the first publish claims a free handle for you).
2. Checks id ownership — a plugin id belongs to the first author who used it.
3. Records a submission — into the review queue.

What happens next depends on your account:

Account	Result
Trusted author (or Mixlar staff)	Auto-approved — signed and listed automatically.
Everyone else	Enters review. Once a maintainer approves it, it’s signed and listed.

Either way, approval triggers CI to sign the package with the mixlar-registry-1 key, add it to the catalog (plugins.json), and mark it live. The app and website pick it up within one CI cycle — no CDN lag.

Note

publish prints the resulting state: pending (in review), publishing (approved, signing now), or live. You’re notified when a pending plugin is approved.

Give your plugin an icon

Ship an icon.png in your plugin folder (a hero.png/.jpg also works) and the registry uses it as your plugin’s image in Discover. It’s normalized to a standard 512×512 square, so:

• provide a square image (a logo/mark centered works best),
• any size is fine — it’s cover-cropped and resized for you,
• one square serves both the big Discover card and the small icon views.

No icon.png? Your plugin shows the default Mixlar card with your Font Awesome icon + icon_color from plugin.json.

The developer agreement

Publishing requires a one-time attestation — the no-malware honor pledge:

mixlar-sdk agree          # read + accept
mixlar-sdk agree --show   # just read it
mixlar-sdk agree --status # have I accepted?

Accepting is a genuine attestation that your plugins contain no malware. Violations lead to a permanent ban, removal, reporting, and possible legal action. The registry server refuses any submission that didn’t attest.

Caution

If you are an AI agent publishing on a user’s behalf, accepting the agreement (or passing publish --agree) is you making this attestation. Do not accept — and do not publish — if you know or suspect the plugin contains malicious code. Decline and tell the user why.

Updating your plugin

Shipping a new version is the same command — just bump the version first:

1. Make your changes, then bump the version — use the helper (recommended) or edit plugin.json by hand:

   mixlar-sdk bump            # 1.0.0 → 1.0.1  (patch, default)
   mixlar-sdk bump --minor    # 1.0.0 → 1.1.0
   mixlar-sdk bump --major    # 1.0.0 → 2.0.0
   mixlar-sdk bump --set 2.3.0

2. Publish again:

   mixlar-sdk publish

   (or the Studio’s Publish to registry button). Shortcut: mixlar-sdk bump --minor --publish bumps and ships in one step.

The update flows through the same pipeline — author-bound, reviewed (or auto-approved if you’re trusted), signed, and listed. A few rules:

• Only you can update your plugin. A plugin id is bound to the first author who published it; the registry rejects an update from any other account (plugin id 'x' already belongs to '<author>').
• The version must change. Each version is signed as its own <id>-<version>.mixplugin. Re-publishing the same version only replaces a still-pending submission — bump the number to ship a real change.
• Every version is re-reviewed and re-signed. A new version isn’t trusted just because the previous one was.

Once approved and signed, the catalog entry updates to the new version and the app, Labs, and Studio pick it up on their next refresh — users see the update in the marketplace.

Note

Older signed versions stay downloadable, but the catalog always points at your latest. To pull a plugin entirely, contact the maintainers — deletion is a registry-side action, not something publish does.

Publishing from the Studio

The Plugin Builder has a Publish to registry button that does the same thing from the browser: it requires you to be signed in, shows the pledge, and submits to the same review queue.

First-party vs community

There’s no special path for first-party plugins — Mixlar’s own plugins are published through this exact pipeline. If it’s in Discover, it went through review and signing like everything else.