Sandboxed plugins

[erlend-sh]

EmDash features a promising evolution of WordPress’ extensibility:

WordPress plugins have full access to the database, filesystem, and user data. A single vulnerable plugin can compromise the entire site. EmDash plugins run in isolated Worker sandboxes via Dynamic Worker Loaders, each with a declared capability manifest. A plugin that requests read:content and email:send can do exactly that and nothing else.

This sandbox design started out as limited to Cloudflare’s platform, but that is no longer the case:

• feat: Node.js plugin isolation via workerd sandbox emdash-cms/emdash#426

To go along with this plugins architecture there is a plan for an atproto/plc-based plugins registry:

• RFC: Decentralized Plugin Registry emdash-cms/emdash#694
• Registry roadmap: fill the lexicon-to-UI gap emdash-cms/emdash#1026

Similar affordances would be great for Blento, allowing for new functionality to be added via plugins rather than by PR.

This is a large change though, so may as well wait for the EmDash plug-in registry to fully land and then assess from there.

[disnet]

Here's a sketch of a potential plugin system motivated by thinking through a polar integration:

The shape

Plugins declare themselves with definePlugin(), ship a capability manifest (secrets:read, fetch:external, …), and run server-side in a sandbox. Capabilities are what make per-plugin secrets tractable: Blento holds the storage and the plugin asks for access; the plugin never sees the raw token outside its sandbox. Each plugin registers one or more card types against the existing CardDefinition interface, so they drop into the grid like built-in cards.

A "Polar card" then becomes one plugin among many, and Blento becomes an integration platform rather than the maintainer of every integration.

What we'd build

Plugin runtime — loader that boots a plugin into a sandbox and brokers capability requests (getSecret, kv.*, fetch with allowlist/SSRF guards, cache.*).
Capability enforcement — manifest declared at install, enforced at every host-API call; user sees and approves before install.
Secrets infrastructure — per-DID encrypted KV, an auth path (session cookie or DPoP verification), settings UI; cards reference a secret key, never the value.
Distribution — bootstrap on the emdash registry model: plugin records live in the author's PDS, artifacts are author-hosted and signature-verified, an aggregator subscribes to the firehose for search, takedowns are atproto labelers. No protocol changes. The atproto-native version of this is dramatically cheaper than running a registry would be otherwise.

For the sandbox, the architectural commitment should be to a SandboxRunner interface, not a specific runtime — emdash demonstrates this with parallel Cloudflare Dynamic Worker Loader and standalone-workerd backends sharing one security model. That keeps the door open to wasm runners or isolate-based options later without re-doing the plugin contract.

Pros

One-time cost amortizes across every future integration — zero marginal Blento engineering per new card type once the runtime exists.
Capability manifest is an auditable answer to "what can this plugin do?" — strictly better than "trust the maintainers" for third-party code.
Externalizes maintenance — Polar changes their API, the Polar plugin author fixes it.
Atproto-native distribution is nearly free — identity, signing, and labeler takedowns are primitives Blento already lives inside.

Cons

Scope. This is a "Blento becomes a platform" decision. If we don't expect a long tail of integrations, it's a loss.
Sandbox correctness is load-bearing. A capability bug means a malicious plugin pivots through the host or reads other users' secrets. The bar for untrusted authors is materially higher than for first-party code.
Distribution still costs something. DID-rooted signing handles the worst version, but we still need install-time UI that surfaces author + capabilities clearly, and a labeler policy for compromised plugins.
API stability. Once external plugins exist, breaking CardDefinition or the host API has a real cost. Today it's an in-repo refactor.