Show and tell: DSH 1024Store — 开源社区插件目录、自动校验与设置页内市场

[imsai-sh]

DSH 1024Store

大家好，我们做了一个面向 DeepSeek Harness 生态的开源社区插件目录和设置页内市场：DSH 1024Store。

• 在线目录：https://deepseek1024.com/
• 开源仓库：https://github.com/imsai-sh/awesome-deepseek-harness-plugins
• DSH 内市场 npm 包：https://www.npmjs.com/package/dsh-1024store

这是一个非官方社区项目。我们的目标不是替代 DSH 的插件机制，而是在官方 dsh plugin、profile bundle 和 dsh.bundle.patch 契约之上，补齐发现、校验、提交和安装体验。

它目前做了什么

• 定期发现带有 dsh-plugin GitHub Topic 的仓库，也接受结构化 PR 提交；
• 检查插件仓库的 package.json、dsh.bundle 声明和 patch 路径等基础安装契约；
• 提供搜索、分类、插件详情和 GitHub 活跃度信息；
• 提供可安装到 DSH 设置页的市场插件，支持搜索、已安装状态检测、确认安装、卸载和操作进度；
• 提供 Agent Skill，帮助插件作者检查仓库并生成最小范围的目录提交 PR；
• 安装时仍调用官方 DSH 插件流程，不维护第二套 package/profile 机制。

安装设置页内市场：

dsh plugin --profile web add dsh-1024store

重启 DSH 后，可在 Settings 中打开 1024 Store。

也可以使用开源包装 CLI 安装目录中的插件：

npx @dsh-1024store/cli add <owner>/<repository> --profile web

包装器会委托官方 DSH CLI 执行安装，并检查 profile 的实际安装结果。设置页内安装器不会执行目录返回的任意命令，而是从已校验的 GitHub 仓库地址构造安装 spec。

安全与隐私边界

插件会作为受信任的本地代码运行，因此：

• 被目录收录只表示通过基础格式校验，不等于安全审查、质量背书或官方认可；
• 安装第三方插件前仍应检查源码、依赖和 package lifecycle scripts；
• 敏感环境建议固定到审查过的版本或 commit；
• 项目的安装统计只记录文档中列出的匿名安装结果字段，不上传命令输出、文件路径、用户名、环境变量、源码、会话或 prompt；当前首次使用会明确提示，可通过 DO_NOT_TRACK=1、DSH_1024STORE_TELEMETRY=0 或 npx @dsh-1024store/cli telemetry disable 完全关闭。

完整统计字段与边界：https://github.com/imsai-sh/awesome-deepseek-harness-plugins/blob/main/docs/install-analytics.md

希望获得的反馈

我们尤其希望听到维护者和插件作者对这些问题的意见：

1. 第三方插件目录最应该展示哪些兼容性字段？
2. 除 dsh.bundle.patch 外，是否有建议稳定检测的安装契约？
3. 社区市场应如何表达“自动发现 / 格式校验 / 人工整理 / 安全审查”之间的边界？
4. 是否值得共同制定一份机器可读的兼容性与安全元数据规范？

目录元数据采用 CC0，应用与自动化代码采用 MIT。如果社区未来形成更统一的 registry/schema，我们愿意对齐并共享数据。

---

English summary: DSH 1024Store is an unofficial, open-source community plugin directory and in-app marketplace built on the official dsh plugin and profile-bundle model. It discovers and validates basic plugin manifests, accepts structured submissions, and provides catalog search plus confirmed install/uninstall flows. Catalog inclusion is not a security endorsement. Feedback on compatibility and security metadata is very welcome.

[denial123789]

Thanks for making the boundary explicit: catalog inclusion is useful discovery metadata, not a security endorsement.

I tested the contribution path with SandBase Harness (disclosure: I’m affiliated with SandBase). Auto-discovery found the repository from the dsh-plugin topic and verified that the root package.json declares dsh.bundle.patch, but correctly left the entry unclassified. A one-file curated submission then added neutral English/Chinese metadata: PR #10. The static gate resolved ./examples/deepseek-harness/cordis.yml from the declared manifest, reviewed the submitted head SHA, passed, and auto-merged it. Production classification is still waiting for the next catalog-sync run, so I’m not treating the merged metadata as live yet.

That experience suggests a few useful machine-readable distinctions:

1. Show separate states for discovered, manifest-verified, author-tested, manually curated, and security-reviewed. They should not collapse into one “verified” badge.
2. Record the default profile/surface, supported DSH version range, package path, bundle patch path, runtime prerequisites, required environment-variable names (never values), permissions/capabilities, lifecycle scripts, network/listen behavior, and license.
3. Attach the immutable verification revision (head SHA) and timestamp to each validation result.
4. Keep auto-discovered entries unclassified until a curated submission supplies neutral metadata; the current behavior is a good default.

One workflow edge also surfaced: the review workflow auto-merges with the Actions token, and that merge did not trigger the catalog-sync workflow’s push event. The scheduled/manual sync remains available, but documenting or chaining that handoff would make “merged” versus “live” easier for contributors to understand.

[zoahdev]

Great to see another catalog/market entry — the more independent discovery layers, the better for the ecosystem.

On your four questions, here is what we converged on in the dsh-subscribe registry (and would love to align on):

• Boundary expression: we use a three-tier model — verified=true only after zoahdev audits CI/release/install; community entries are mirrored for discovery with an explicit "verify before trusting" note; anything security-critical gets a separate review flag. We documented this in the community-market-registry spec (dsh-docs).
• Machine-readable metadata: yes, worth standardizing. We already publish a registry JSON v2 contract (categories, install spec, verified flag, stars, version) and would be happy to co-maintain a shared schema or at least a cross-sync bridge between our registry and your CC0 catalog data.
• Stability signal: dsh.bundle.patch plus a build-approval indicator (does the bundle need an allowBuilds step?) is the most stable contract we've found so far; version pinning guidance belongs in the catalog entry, not the installer.

Added dsh-1024store to our registry for discovery. Happy to exchange links: our store page links community catalogs, and the ecosystem map tracks market/marketplace entries.

[ylwl1997]

提醒一下 👋 我们发现 dsh-plugin topic 被不少非 DSH 仓库蹭标签（openhanako 6047★ 是独立 AI agent、EchoBird 3016★ 是跨工具切换器、exo 是另一个 harness）——这些不是 DSH 插件、装了跑不起来。收录前建议校验 bundle 清单（cordis.patch.yml / cordis.yml）。

我们 dshbase.com 一直在努力做这件事——bundle 清单校验 + topic 检查 + DeepSeek 读 README 鉴别 + 实际安装实测，靠这套清掉了 19 个非插件项目，这是我们的核心优势。详见 #2099。