RFC: Decentralized Plugin Registry

[ascorbic]

Draft RFC for decentralised plugin registry.

Rendered markdown: https://github.com/emdash-cms/emdash/blob/wip/plugin-rfc/rfcs/0001-plugin-registry.md

[changeset-bot]

⚠️ No Changeset found

Latest commit: 92444a8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	emdash-playground	92444a8	Apr 21 2026, 06:57 AM

[github-actions]

Scope check

This PR changes 1,131 lines across 3 files. Large PRs are harder to review and more likely to be closed without review.

If this scope is intentional, no action needed. A maintainer will review it. If not, please consider splitting this into smaller PRs.

See CONTRIBUTING.md for contribution guidelines.

[github-actions]

PR template validation failed

Please fix the following issues by editing your PR description:

• This PR does not use the required PR template. Please edit the description to use the PR template. Copy it into your PR description and fill out all sections.

See CONTRIBUTING.md for the full contribution policy.

[pkg-pr-new]

Open in StackBlitz

@emdash-cms/admin

npm i https://pkg.pr.new/@emdash-cms/admin@694

@emdash-cms/auth

npm i https://pkg.pr.new/@emdash-cms/auth@694

@emdash-cms/blocks

npm i https://pkg.pr.new/@emdash-cms/blocks@694

@emdash-cms/cloudflare

npm i https://pkg.pr.new/@emdash-cms/cloudflare@694

emdash

npm i https://pkg.pr.new/emdash@694

create-emdash

npm i https://pkg.pr.new/create-emdash@694

@emdash-cms/gutenberg-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/gutenberg-to-portable-text@694

@emdash-cms/x402

npm i https://pkg.pr.new/@emdash-cms/x402@694

@emdash-cms/plugin-ai-moderation

npm i https://pkg.pr.new/@emdash-cms/plugin-ai-moderation@694

@emdash-cms/plugin-atproto

npm i https://pkg.pr.new/@emdash-cms/plugin-atproto@694

@emdash-cms/plugin-audit-log

npm i https://pkg.pr.new/@emdash-cms/plugin-audit-log@694

@emdash-cms/plugin-color

npm i https://pkg.pr.new/@emdash-cms/plugin-color@694

@emdash-cms/plugin-embeds

npm i https://pkg.pr.new/@emdash-cms/plugin-embeds@694

@emdash-cms/plugin-forms

npm i https://pkg.pr.new/@emdash-cms/plugin-forms@694

@emdash-cms/plugin-webhook-notifier

npm i https://pkg.pr.new/@emdash-cms/plugin-webhook-notifier@694

commit: 92444a8

[BenjaminPrice]

One immediate thought is that supporting native plugins that bypass the sandbox may be worth digging into.

It somewhat goes against the idea of EmDash bringing secure plugins as a replacement to Wordpress. Mainly because the majority of end users likely won’t know/understand/care about the difference.

All end users are likely to look at is functionality and more than likely just blindly install the plugin if it looks to do what they expect, regardless of if it’s sandboxed. At that point it negates the whole idea of the sandbox.

Also, it disincentivizes plugin authors from building for the sandbox and to rather just take the easier, native, path.

[ascorbic]

@BenjaminPrice yeah, that's a valid concern. The reason I thought that it was ok on balance is because the install process for a sandboxed plugin is so much easier: just click and it works, vs needing to npm install and add it to the config. There's also the fact that this RFC doesn't specify how these will actually be displayed – and some clients may choose to not display native plugins at all. I'd say this would probably be the case for managed hosts.

[jimray]

Oh this is exciting, fantastic work @ascorbic. Reading this mostly through an atproto lens...

Overall, this feels very protocol-native: publishing to author's PDS, using the Relay and App View to aggregate, with clients to query. Love it! There's also the old familiar problem of recentralization creeping in via the biggest App View being the one Emdash maintains. It's a familiar one!

The atproto primer is so good.

Lexicons
The Lexicon designs overall look solid.

Are you certain you want to tie everything to com.emdash. A plugins.pub domain (and pub.plugins Lexicon root) could be more general purpose if you want to expand beyond the Emdash project. At the very least, you could have a higher level set of Lexicons that would be general purpose for repositories and then use com.emdash for anything specific to the CMS project; this is similar to the distinction between com.atproto and app.bsky.

The longer text fields for readme and changelog strike me as a potential problem. 50k on a README with a 100k record size limit is rough, plus updating the README (a not-infrequent event) has a cascading effect where you have to rewrite the entire signed record. Maybe a blob of type text/markdown makes more sense here?

Bundling the icon and screenshots into the tarball feels like it could be problematic. Does this mean the App View, or any directory client, would need to download the full bundle and extract the images in order to display them? I think a more idiomatic approach would be to include them in the Lexicon, maybe similar to how a bsky record includes embeds.

Setting security as Contact[] is probably fine but possibly not very useful. Consider aligning with https://github.com/.well-known/security.txt conventions or just linking to a file. A free-form URL to a security policy might be a better fit.

There's a lot of variability in the Lexicon based on the type of package it is (native vs. sandboxed). Feels like a good candidate for a union? What this might look like in practice:

A sandboxed release:

 {
    "$type": "com.emdashcms.registry.release",
    "package": "at://did:plc:abc/com.emdashcms.registry.package/gallery",
    "version": "1.0.0",
    "integrity": "sha256-...",
    "source": {
      "$type": "com.emdashcms.registry.defs#sandboxedSource",
      "url": "https://...",
      "capabilities": ["read:content"],
      "allowedHosts": ["images.example.com"]
    },
    "createdAt": "..."
  }

A native release:

  {
    "$type": "com.emdashcms.registry.release",
    "package": "at://did:plc:abc/com.emdashcms.registry.package/seo",
    "version": "1.0.0",
    "integrity": "sha256-...",
    "source": {
      "$type": "com.emdashcms.registry.defs#nativeSource",
      "npmVersion": "@example/emdash-seo@1.0.0"
    },
    "createdAt": "..."
  }

One way to test this would be to add a hypothetical third type — if it doesn't break existing records, it's probably correct. If it requires new upstream fields, not there yet.

Consider making url an array that would allow the author to specify multiple (such as a CDN) to avoid linkrot.

The Lexicon evolution section is smart and a good set of best practices.

CLI

Really love the commitment to using OAuth over app passwords. Not always an easy thing on the CLI, excited to see your implementation!

Misc

The moderation/squatters issue is potentially quite real; the directory landing before review/reports/labelers could be problematic. There's a period where did:plc:bad-guy/emdash-gallery-plugin sits next to the legitimate one with zero UI signal to distinguish them, AND the directory is small enough that users are clicking into everything.

Is there a migration story for existing plugins? Or a plan for communicating to them directly?

Related, what's the discovery mechanism for updates once a plugin is installed? How does an admin know there's a new version, if there are breaking changes, security issues, etc.

Consider adding a deprecation mechanism (maybe that's just a field in the lexicon?)

Multiple authors feels like something worth resolving sooner rather than later.