The plugin registry

The plugin registry is the decentralized successor to the central marketplace. Publishers own their records, and anyone can run the index that makes them discoverable — the aggregator. Each aggregator defines which labellers must approve a listing before it appears. When you point your site at a registry, the admin dashboard browses and installs plugins from there instead of from the marketplace.

It is built on the AT Protocol, the network behind Bluesky.

Both the marketplace and the registry let an administrator browse, install, update, and remove sandboxed plugins from the admin dashboard. The install experience — capability consent, checksum verification, the sandbox runner — is the same. They differ in who controls the catalog and who you trust.

You configure one or the other for a given site. When experimental.registry is set, the admin’s browse and install flows use the registry.

The registry requires a sandboxRunner, because registry plugins always run sandboxed. See Installing Plugins for the runner setup.

The following configuration points a site at the reference aggregator:

import { defineConfig } from "astro/config";
import emdash from "emdash/astro";

export default defineConfig({
  integrations: [
    emdash({
      sandboxRunner: "@emdash-cms/sandbox-cloudflare",
      experimental: {
        registry: "https://registry.emdashcms.com",
      },
    }),
  ],
});

The bare URL string is shorthand. Use the object form when you need to declare accepted labellers or set a release-age policy:

emdash({
  sandboxRunner: "@emdash-cms/sandbox-cloudflare",
  experimental: {
    registry: {
      aggregatorUrl: "https://registry.emdashcms.com",
      acceptLabelers: "did:web:labels.emdashcms.com",
      policy: {
        minimumReleaseAge: "48h",
        minimumReleaseAgeExclude: ["did:plc:yourfirstpartydid"],
      },
    },
  },
})

The aggregator URL must be HTTPS in production (http://localhost is allowed in development).

• acceptLabelers — an optional comma-separated list of bare labeller DIDs forwarded as a validated declaration and included in the client’s cache identity. When set, the list must include every source required by the aggregator. The declaration cannot change the aggregator’s approval, block, takedown, or withdrawal policy.
• policy.minimumReleaseAge — hold back releases newer than this age when choosing the version to install or update to, widening the window for a takedown to land before a compromised release reaches your site. Accepts a duration string ("24h", "7d") or a number of seconds.
• policy.minimumReleaseAgeExclude — DIDs exempt from the holdback, for publishers whose release tempo you have explicitly accepted (such as your own first-party plugins). Each entry is a bare publisher DID, or a <did>/<slug> pair to exempt a single package. Only DIDs are accepted, not handles.

1. Open the admin panel and navigate to Plugins > Registry.
2. Browse or search. Each approved result shows its listing name, approved author name or stable publisher DID, and latest version.
3. Open a plugin to see its README, screenshots, declared access, and release history.
4. Click Install and review the capability consent dialog.
5. Confirm.

Installation verifies the downloaded bytes against the release checksum, confirms the bundle’s plugin id and version match the release, and confirms its declared capabilities match what you approved. Updates and uninstalling work as they do for marketplace plugins.

The registry is decentralized, so trust is explicit. The reference labeller assesses only the publisher-controlled metadata and media shown in the admin. It does not fetch or assess plugin archives, source code, manifests, dependencies, software bills of materials, or provenance evidence. Its approval is bound to the exact content identifier (CID) of a profile or release record.

Plugin-code checks remain separate. Before activating a plugin, EmDash independently verifies that the artifact bytes hash to the approved release checksum, that the bundle addresses the plugin id and version it claims, and that its capabilities match the consent dialog.

• Installing Plugins — the marketplace and config-based install flows
• Bundling and publishing — publish your own plugin to the registry
• Querying the registry — build a plugin directory or search page against the registry’s discovery API
• Capabilities and security — the sandbox trust contract
• RFC 0001 — the protocol design, for contributors and aggregator operators