[RFC] Ecosystem primitives: plugin discoverability, an optional identity seam, and a path to account-anchored sync

[jiangxingfan1-coder]

TL;DR — Three asks, ordered by cost. (1) A tiny package.json convention so the world's dsh plugins become machine-discoverable; (2) an optional Identity service seam beside the existing anonymous-user-id (untouched); (3) longer-term: OIDC device flow on the platform side, so settings/plugin sync can anchor to official accounts. We are building the interim layers in the open and will happily donate schemas/data/governance when official equivalents land.

Motivation

The plugin ecosystem is exploding — community shelves already list 1,800+ plugins (see the Blue-Whale catalog thread, #1728) and a store plugin shipped this week (#2256). The paper's motivation section frames the harness as self-evolving: it generates and deploys modifications to its own components while serving requests. But the deployment radius is currently one process on one machine. Users with several devices — different plugin sets per machine — have no way to compose across machines, and the ecosystem has no shared substrate for discovery, trust, or identity. Spatiotemporal composability shouldn't stop at the process boundary.

We are building three interim layers — personal cross-device sync of the declarative layer (shared + per-machine profile patch overlays; plain --patch/user-layer mechanics, nothing invented), a federated discovery/trust index, and a "compose" sharing unit (patch + preset + briefing + plugin refs — arguably the native shareable capability unit in a patch-layered harness). Each layer is designed with an explicit official-takeover point. Three things only upstream can do cheaply:

Ask 1 — package.json convention for plugin identification (near-zero cost)

There is currently no marker distinguishing a dsh plugin package on npm from any other package (we checked the monorepo for a keyword/field convention and found none — please correct us if we missed it). A one-line spec unlocks ecosystem-wide crawling/indexing for every registry effort:

{
  "dsh": { "plugin": true },          // or: "keywords": ["dsh-plugin"]
  // optional, enables richer indexing:
  "dsh": { "plugin": { "services": ["..."], "inject": ["..."] } }
}

We'll adopt whatever shape you bless, retroactively PR it to known community plugins, and encode it in our index's CI.

Ask 2 — an optional Identity service seam (anonymous layer untouched)

@deepseek-ai/dsh-anonymous-user-id is deliberately anonymous — "No cross-home identity" is listed as a known limitation, and the UUID already reaches DeepSeek as x-deepseek-harness-user-id. We are not asking to change it. We're asking for a core-blessed seam: an Identity service interface that third-party providers can implement (API-key-derived today, deepseek-oidc tomorrow), so consumers (sync plugins, publisher tooling) depend on the interface and providers hot-swap underneath — the exact provider-substitution story Cordis already tells everywhere else. If the seam exists, the eventual official account system inherits every consumer for free.

Ask 3 — longer-term: OIDC device flow + a home for ecosystem governance

When the platform team is ready: a device-code OAuth flow on the open platform would let harness installs bind to official accounts, upgrading the anonymous UUID server-side without breaking its privacy contract. Separately, our index repo is structured so its governance can be transferred wholesale to the org — the ClawHub incidents this spring (341+ malicious skills, ranking manipulation, registry saturation; scanning demonstrably not sufficient) argue for getting trust primitives right early, and for publisher-anchored rather than popularity-anchored trust. dsh plugins run with npm postinstall + Host-realm privileges, so the stakes are strictly higher.

What we've already built (interim, takeover-ready)

• dsh-hub-index — schema'd registry (plugins/skills/composes) with trust tiers (official/verified/community/unreviewed), popularity explicitly excluded from trust computation, CI validation, federation-ready for the existing community shelves: https://github.com/jiangxingfan1-coder/dsh-hub-index (browse: https://jiangxingfan1-coder.github.io/dsh-hub-index/)
• compose spec v1 — a shareable capability composition: patch + preset + briefing + plugin refs + security declarations (!!js usage, waterfall listeners, subagent spawning): schema. First exhibit: a 9-plugin two-phase scheduling family with 19 rounds of controlled experiments behind it.
• dsh-identity — the personal sync layer (private by design — the data plane is personal; the mechanics are: a resident sync plugin using ctx.effect for clean disposal, secrets never in the sync plane, and an official-cloud SyncBackend slot mirroring the credentials/credentials-local split).

Happy to donate any of it, or reshape to whatever the team prefers. The interim road exists to be replaced by the official one.

[jiangxingfan1-coder]

中文版 / Chinese version

太长不看 —— 按成本从低到高的三个请求：(1) 一个极小的 package.json 约定，让全世界的 dsh 插件可被机器发现；(2) 在现有 anonymous-user-id 之外（不动它）加一条可选的 Identity 服务缝；(3) 长期：平台侧提供 OIDC device flow，让设置/插件同步能锚定官方账号。我们正在公开地搭建这些过渡层，官方等价物落地之日，schema、数据、治理权随时捐赠。

动机

插件生态正在爆发——社区货架已收录 1800+ 插件（见 Blue-Whale 目录帖 #1728），本周还上线了一个商店插件（#2256）。论文动机一节把 harness 定位为自演化系统：在持续服务请求的同时生成并部署对自身组件的修改。但当前的部署半径只有一台机器上的一个进程。多设备用户（每台机器插件集不同）无法跨机器组合，生态也没有发现、信任、身份的公共底座。时空组合性不应止步于进程边界。

我们正在搭三个过渡层——个人跨设备声明层同步（shared + 每机 profile patch overlay；纯官方 --patch/用户层机制，零发明）、联邦式发现与信任索引、以及 compose 分享单元（patch + preset + 简报 + 插件引用——在一个以 patch 分层的 harness 里，这才是原生的可分享能力单元）。每一层都留了明确的官方接管点。以下三件事只有上游做起来成本最低：

请求 1 —— 插件识别的 package.json 约定（近零成本）

目前 npm 上没有任何标记能把 dsh 插件包与普通包区分开（我们查过 monorepo，未发现 keyword/字段约定——如有遗漏请指正）。一行规范就能为所有注册中心努力解锁全生态爬取与索引：

{
  "dsh": { "plugin": true },          // 或者: "keywords": ["dsh-plugin"]
  // 可选，支持更丰富的索引：
  "dsh": { "plugin": { "services": ["..."], "inject": ["..."] } }
}

官方定什么形状我们就采用什么形状，并给已知社区插件补 PR、写进我们索引的 CI。

请求 2 —— 可选的 Identity 服务缝（匿名层不动）

@deepseek-ai/dsh-anonymous-user-id 是刻意匿名的——README 把「No cross-home identity」列为已知限制，且该 UUID 已作为 x-deepseek-harness-user-id 到达 DeepSeek 服务端。我们不是要求改它。我们请求的是一条核心认可的缝：一个 Identity 服务接口，第三方 provider 可实现（今天是 API-key 派生，明天是 deepseek-oidc），消费者（同步插件、发布者工具）依赖接口、provider 在底下热替换——这正是 Cordis 在其他所有地方讲的 provider 替换故事。缝存在，未来的官方账号系统就免费继承所有消费者。

请求 3 —— 长期：OIDC device flow + 生态治理的归宿

平台团队就绪时：开放平台的 device-code OAuth flow 能让 harness 安装绑定官方账号，在服务端把匿名 UUID 升级，且不破坏其隐私契约。另外，我们的索引仓库在结构上支持治理权整体移交给官方——今年春天 ClawHub 的事故（341+ 恶意 skills、排名操纵、registry saturation；扫描被证明不够）说明信任原语要趁早做对，且要锚定发布者而非流行度。dsh 插件带着 npm postinstall + Host realm 权限运行，风险只高不低。

我们已经建好的（过渡性，随时可接管）

• dsh-hub-index —— schema 化注册中心（插件/技能/compose），信任分层（official/verified/community/unreviewed），流行度明确排除在信任计算外，CI 校验，可与既有社区货架联邦：https://github.com/jiangxingfan1-coder/dsh-hub-index （在线浏览：https://jiangxingfan1-coder.github.io/dsh-hub-index/）
• compose 规范 v1 —— 可分享的能力组合：patch + preset + 简报 + 插件引用 + 安全声明（!!js 使用、waterfall 监听、子代理派生）：schema。首个展品：一个 9 插件两相位调度家族，背后有 19 轮受控实验。
• dsh-identity —— 个人同步层（有意保持私有——数据面是个人的；机制为：常驻同步插件用 ctx.effect 干净卸载、机密永不进同步平面、预留官方云 SyncBackend 插槽，镜像 credentials/credentials-local 的拆分）。

以上任何部分都乐意捐赠，或按团队偏好重塑。过渡之路存在的意义就是被官方正路取代。

[jiangxingfan1-coder]

Follow-up on Ask 1, with new evidence from the codebase: the dsh package.json namespace already exists and carries structured metadata today — dsh.profile.bundles (profile packages), dsh.client (dual-face client declaration: inject / platform / immediately), and dsh.bundle.patch (a plugin-shipped patch that auto-joins the composition tree on install; community dual-face plugins like dsh-file-upload and dsh-archived-chats already rely on it).

So Ask 1 shrinks to: bless one more key in the namespace you already own — e.g. dsh.plugin: true (or treat presence of any dsh.* key as the discovery marker, which would make every existing plugin discoverable retroactively with zero PRs). We've since shipped a Settings-page store UI (dsh-hub-panel, built on the community dual-face recipe) and an agent-facing hub_search tool on top of the curated index — both would switch to registry-wide crawling the day a marker is blessed.

[qing3a]

验证层视角：支持三个 ask，补两点信任机制建议

以 DSH 插件验证工具（dsh-plugin-verify，manifest 静态校验 + 运行时行为验证）维护者的身份支持这个方向。RFC 的信任分层（尤其"排除 popularity"和"扫描≠安全"两条铁律）方向完全正确，补两点机制建议：

1. ask #1（dsh 字段）：建议 schema 单一来源，避免生态里出现多套互不兼容的 dsh 字段约定

目前生态里已有不同项目各自在定义"插件如何声明自己"的字段/规范，如果不先定一份权威 schema，dsh 字段可能会像插件格式一样分散。建议：RFC 采纳一个约定后，把它落地成一份独立的 JSON Schema 文件（放在官方 monorepo 的公开路径），索引、市场、验证工具、脚手架统一消费这一份，而不是各写各的。字段本身的建议也支持加 capabilities（声明式能力清单），验证器按 schema 校验，未知字段直接报错——"没声明的能力调用抛错"在 manifest 层就能先拦一层。

2. verified tier：建议把"运行时行为验证"作为可选晋级证据

现在的 verified 定义（发布者实名 + 仓库-npm 对应 + 构建溯源核验）覆盖了身份与来源维度，很好。但按你的铁律 3"扫描通过 ≠ 安全"，静态维度之外的行为维度目前是空的——而 dsh 插件是 Cordis 动态插件，行为（注册服务、监听事件、patch 调用）才是实际风险面。建议 verified 晋级流程接受第三方运行时行为验证报告作为可选证据字段（verifiedBy / verifiedAt / reportUrl，你的 entry schema 里已有这些占位）：验证工具在 mock-llm 下跑插件的真实行为判定（如 waterfall 事件流、工具调用、isError 状态），产出的报告挂在条目上。这样 CI 的 schema 校验之外多一层运行时证据，静态+行为两条线才闭合。verified 的最终定义权在你（这是你的索引），第三方只提供可引用的证据。

3. compose：security 声明是好的起点，运行时行为验证可延伸覆盖

super-fast 的 security 声明段（jsExpressions / listensWaterfalls）把 patch 面显式化了，这正是 compose 审计应该有的重心。复杂组合（多插件调度树）仅靠静态声明不够——同一套验证报告机制可以延伸覆盖 compose 的运行时行为，让"调好的组合树"和"单个插件"用同一把尺子度量。

对接意愿：如果 verified 晋级流程接受第三方运行时验证报告作为证据之一，dsh-plugin-verify 可以按你 entry schema 的字段约定输出报告（verifiedBy / verifiedAt / reportUrl / 判定明细），作为插件或 compose 条目的可选证据提交。索引的信任判定权始终在你的维护者手里，我们只做中立的数据来源。