EmDash 1.0：插件目录不必拥有发布权

结论#

EmDash 1.0 把插件作者身份、发布记录和插件目录拆开。作者保留签名发布记录，目录负责索引和展示，安装端再独立校验记录与包内容。

这套结构解决了两个常见问题。第一，目录不再同时控制作者身份和权威发布历史。第二，插件被发现以后，运行权限仍由独立的 sandbox 和 capability 规则决定。

30 秒看懂#

传统插件市场经常把开发者账号、权威发布记录和用户发现入口放在同一个平台里。平台一旦关闭服务或下架账号，作者很难把同一份身份和发布历史带到别处。

EmDash 1.0 把这些职责拆开。插件作者把签名后的包记录和发布记录保存在自己的 AT Protocol 账户里。EmDash 的插件目录负责索引。其他服务也可以索引同一批记录。

安装时，客户端不会只相信目录返回的结果。EmDash 会继续验证签名记录、checksum、包名、版本、权限声明，以及需要时的构建来源信息。目录可以换，作者身份和发布历史不需要跟着换。

事实核验#

EmDash 是 emdash-cms 维护的开源 CMS，基于 Astro 和 TypeScript。Cloudflare 在 2026 年 9 月 28 日发布 EmDash 1.0，并把它描述为 stable、free、open source。项目采用 MIT License。

官方仓库提供本地创建命令 npm create emdash@latest。官方同时提供 Playground 和 EmDash Build Demo。

1. 插件目录基于 AT Protocol。插件作者使用自己的账户发布，包记录和发布记录由作者签名并保存在作者账户中。
2. 不同服务可以索引同一批发布记录，建立自己的目录。
3. 安装端会核对签名提交，并检查 checksum、包名、版本、请求权限和需要的 build provenance。
4. 插件运行在隔离环境中。默认不能读取站点内容、媒体、用户、密钥、环境、文件系统或网络。
5. 插件声明需要的能力后，由站点管理员批准，运行时再开放对应能力。
6. Cloudflare 部署使用 Dynamic Worker。Node.js 部署使用独立的 workerd 进程。
7. 当前插件目录支持免费插件。付费插件仍属于后续计划。

这些信息来自 Cloudflare 的 EmDash 1.0 发布文章、EmDash 官方仓库、插件目录和官方 Demo。

为什么这个分层值得看#

插件生态里有两个不同的问题。一个是“用户在哪里找到插件”，另一个是“谁拥有作者身份和发布历史”。

如果目录同时承担账号、发布记录和分发入口，它就会成为唯一的信任中心。EmDash 把发布记录放回作者账户，再让目录做索引。目录仍然可以做审核、排序和隐藏，但它不能替作者改写已经签名的发布记录。

安装端再做一次独立校验也很关键。目录返回一个插件，不等于客户端必须直接信任它。客户端继续核对记录、包内容和权限声明，能把“发现结果”和“可安装结果”分开。

四层职责#

这四层可以由同一套产品提供，但职责不应该混成一个权限。

三个可复用的设计#

1. 把身份、发布记录和目录拆开#

作者身份和发布历史可以迁移。目录只负责发现和自己的审核策略。这样更换目录不会自动切断作者已有的发布记录。

2. 安装端重新校验#

目录给出结果后，客户端仍验证签名记录、checksum、版本、权限声明和构建来源。目录不是唯一信任根。

3. 把发现和执行权限拆开#

一个插件被目录收录，只说明用户能够找到它。插件真正运行时，仍然需要通过 sandbox 和 capability 规则获得对应能力。收录不等于获得站点全部权限。

边界#

EmDash 1.0 已经公开并可创建本地项目，但插件生态仍在继续建设。付费插件没有在当前 1.0 方案里完成。

“去中心化目录”也不等于没有平台治理。目录仍然可以决定索引、排序、隐藏和审核规则。变化在于作者签名的发布记录不由某一个目录独占。

安装端校验也不能代替运行时权限控制。签名和 checksum 主要解决“下载到的内容是否对应作者发布的记录”。插件能访问哪些数据、文件和网络，仍由运行环境决定。

主要来源#

• Cloudflare：EmDash 1.0: the stable CMS with a secure plugin registry ↗
• EmDash 官方仓库 ↗
• EmDash 插件目录 ↗
• EmDash Playground ↗
• EmDash Build ↗