EmDash plugin compatibility and WiseWig AI

WiseWig treats the EmDash sandboxed-plugin package as the portable plugin contract. A compatible package keeps its canonical emdash-plugin.jsonc, package version, publisher identity, capabilities, allowed hosts, storage declarations, hooks, bundle, and registry provenance. EmDash remains authoritative for validating that manifest and package. WiseWig does not fork those fields into a competing marketplace format.

AI and MCP are an optional, additive capability in the same package. A plugin may include wisewig-plugin.jsonc beside the EmDash manifest. EmDash can ignore that sidecar and run the plugin normally; WiseWig validates both files and exposes the declared tools, resources, and prompts through the site’s physically separate public and private MCP gateways.

Trust rule

The sidecar never grants authority. Every MCP declaration must fit within the canonical EmDash trust contract:

• content-changing tools require EmDash content:write;
• media-changing tools require EmDash media:write;
• network access remains limited by EmDash network:request and allowedHosts;
• plugin records remain limited to storage declared in the EmDash manifest;
• public declarations may read sanitized public_content only and carry no private permission;
• private declarations require OAuth scope plus the current WiseWig role permission on every request.

Unknown capabilities, hooks, storage shapes, or MCP data scopes fail closed. A package does not become installable by adding a permissive WiseWig sidecar.

Package shape

my-plugin/
├── package.json
├── emdash-plugin.jsonc     # canonical identity and authority
├── wisewig-plugin.jsonc    # optional AI/MCP exposure
└── src/plugin.ts           # EmDash plugin implementation

The initial sidecar schema is:

{
  "schemaVersion": 1,
  "mcp": {
    "tools": [],
    "resources": [],
    "prompts": []
  }
}

Each entry uses WiseWig’s existing MCP tool/resource/prompt schema, including visibility, permission, data-scope, and collection declarations. This preserves the hard public/private data boundary while allowing a sermon, commerce, survey, or other EmDash plugin to contribute AI-native site capabilities.

Source validation is not installation

wise-wig plugin validate is a developer command for source the operator already trusts. EmDash’s build pipeline probes the plugin module to discover hooks and routes, so this command may execute plugin code with the developer process’s authority. Never run it in a production Worker, against an untrusted registry download, or with platform credentials in the environment. Registry installation needs a separate checksum/publisher verification step and an isolated bundle runner; that boundary remains a beta gate.

The SDK’s artifact downloader is a narrower primitive for the later installation path. It accepts only unauthenticated HTTPS, rejects obvious local/private targets, refuses redirects, enforces both declared and streamed byte limits, supports the EmDash-required base32 sha2-256 multihash, and compares the downloaded bytes before returning them. It proves artifact integrity only. A checksum copied from an untrusted aggregator proves nothing about publisher identity.

The Node 22+ operator CLI now supplies the identity stage. wise-wig plugin verify-release resolves the publisher DID without a stale cache, locates its PDS and current AT Protocol signing key, requests the exact com.atproto.sync.getRecord CAR proof, caps that proof at 4 MiB, verifies the signed commit and MST membership with the AT Protocol reference repository library, validates the record against EmDash’s release lexicon and requested package/version, and only then invokes the artifact checksum gate. Identity, proof, and artifact network operations have hard timeouts. Obvious local/private PDS and artifact targets, redirects, authenticated artifacts, and redirect-oriented release assets fail closed. Deployers must still apply an outbound network policy because hostname checks alone cannot defeat DNS rebinding.

Current compatibility level

Implemented now:

• EmDash publisher/slug identity preservation;
• canonical capability, host, storage, hook, and version compilation;
• optional versioned AI/MCP sidecar validation;
• fail-closed authority checks that prevent the sidecar from broadening access;
• CLI scaffolding for the dual-compatible package shape;
• an upstream developer-source plugin validate gate using pinned EmDash buildPlugin and bundlePlugin({ validateOnly: true }) APIs;
• a current EmDash 0.31/plugin-cli 0.8 fixture that builds before its sidecar is compiled;
• a bounded, redirect-denying artifact downloader compatible with the upstream sha2-256 multihash format;
• authoritative publisher DID-key, signed-commit, and MST record-membership verification in the Node operator CLI;
• generated signed-repository fixtures covering valid, wrong-key, mismatched-identity, and private-PDS cases;
• in-memory tar.gz ingestion that checks tar headers, rejects traversal, links and duplicate entries, caps compressed/expanded/backend sizes, and binds manifest.json identity to the verified release before exposing backend.js;
• tests for identity collision resistance, capability mapping, unsupported grants, storage limits, and MCP escalation attempts.

Still required before claiming drop-in runtime compatibility:

• execute the validated backend.js through a compatible Dynamic Workers sandbox adapter and capability bridge;
• add upstream-published registry fixtures when the experimental registry exposes stable fixtures, in addition to the generated cryptographic fixture.

Until those runtime gates land, “compatible” means package identity/trust metadata and AI sidecar compatibility—not that every existing EmDash executable bundle can already run inside WiseWig.

References: EmDash plugin overview, manifest, capabilities, registry, hooks, AT Protocol repository format, and sync semantics.