DSH Plugin Store — native Community and Installed views for 2,900+ plugins

[denial123789]

We have open-sourced DSH Plugin Store, a native Settings experience for discovering and managing the growing DeepSeek Harness plugin ecosystem.

Repository: https://github.com/sandbaseai/dsh-plugin-store

Real preview: the Community view filtered by the Desktop tag.

What the preview includes

• Community and Installed tabs inside DSH Settings
• Search across name, repository, description, and category
• Server-side tag filters and pagination
• Sorting by leaderboard rank, GitHub stars, and weekly growth
• Catalog data covering more than 2,900 community repositories
• Local profile installation with validation and explicit error feedback
• Live Cordis Loader inventory
• Agent tools for programmatic catalog discovery

Current compatibility boundary

The native integration is being developed against the DeepSeek Harness 0.1.0-rc.5 source tree. This is a preview, not an official DeepSeek project or a stable package-release claim. We will document a stable installation command only after the public Harness package versions and reproducible package checks align.

Feedback we need

• Plugin authors: is your repository metadata and category accurate?
• Users: which discovery, installation, update, or uninstall workflow matters most?
• Operators: which trust signals should appear before third-party code is installed?
• Enterprise teams: what allowlist, private catalog, audit, and policy controls are required?

Launch notes and discussion: sandbaseai/dsh-plugin-store#5
Early tester template: sandbaseai/dsh-plugin-store#1

If a native plugin marketplace would make DSH more useful for you, please star the repository and share one workflow or compatibility issue we should prioritize.

[denial123789]

Source readiness update: commit e4c517c replaces the old host-only snapshot with the complete native Host + Web client source and a real dsh.bundle / client manifest.

Verified in the DeepSeek Harness 0.1.0-rc.5 workspace:

pnpm --filter @sandbaseai/dsh-plugin-store typecheck  # passed
pnpm --filter @sandbaseai/dsh-plugin-store bundle     # passed
Host ESM: lib/index.js
Web client: lib/client.js

The README now documents the reproducible source-checkout integration path in English and Chinese. The stable package command is still intentionally withheld until public DSH package versions align.

[denial123789]

Installability update: DSH Plugin Store is now live in the public DSH 1024Store catalog.

dsh plugin --profile web add github:sandbaseai/dsh-plugin-store

Catalog result: https://api.deepseek1024.com/v1/plugins/search?q=sandbaseai%2Fdsh-plugin-store&limit=10
Preview 2: https://github.com/sandbaseai/dsh-plugin-store/releases/tag/v0.1.0-preview.2

The release includes verified Host and Web client artifacts plus the complete native Store source. If you test it, the shortest useful report is whether Community catalog loading, tag filtering, install feedback, and Installed-state detection work in your DSH profile: sandbaseai/dsh-plugin-store#1

[denial123789]

Preview 2 discovery update:

• The catalog now exposes 4,000+ plugin packages across 3,400+ repositories, with search, tag filtering, sorting, and pagination in the native Store view.

• The immutable preview install target is:

  dsh plugin --profile web add github:sandbaseai/dsh-plugin-store#v0.1.0-preview.2

• Public project page: https://sandbaseai.github.io/dsh-plugin-store/

• Independent catalog/leaderboard entry: https://dshpluginleaderboard.com/plugins/sandbaseai-dsh-plugin-store

• Install-safety roadmap (preflight resolution, profile snapshot, rollback): Install safety: preflight resolution, profile snapshot, and automatic rollback sandbaseai/dsh-plugin-store#6

This remains a community Preview rather than a stable-package claim. We would especially value one real profile test covering catalog loading, a tag filter, install feedback, and Installed-state detection: sandbaseai/dsh-plugin-store#1

[denial123789]

Preview 4 now has a complete public 0.1.0-rc.8 install and runtime verification rather than only a package import check.

The disposable-profile test covered bundle reconciliation, --dump-config, DSH Web boot on an OS-assigned loopback port, browser client serving, and the live catalog Host route. It also caught and fixed Preview 3’s invalid old-style patch row.

Verified install path:

curl -fL https://github.com/sandbaseai/dsh-plugin-store/releases/download/v0.1.0-preview.4/sandbaseai-dsh-plugin-store-0.1.0-preview.4.tgz -o /tmp/sandbaseai-dsh-plugin-store-0.1.0-preview.4.tgz
dsh plugin --profile web add -w /tmp/sandbaseai-dsh-plugin-store-0.1.0-preview.4.tgz

Release and evidence: https://github.com/sandbaseai/dsh-plugin-store/releases/tag/v0.1.0-preview.4

The standalone source-build workflow remains tracked separately from this now-reproducible prebuilt trial path.

[denial123789]

Preview 5 separates catalog trust from local-profile safety and makes the Store's downstream Install action enforceable on public DSH rc.8.

Before invoking the DSH plugin CLI, the Store now requires a verified catalog record, a matching runtime_verified detail record, and exactly one npm package spec. URLs, git specs, whitespace, shell syntax, and repository-identity mismatches are rejected. Installer output is bounded and the process has a two-minute timeout.

The public rc.8 end-to-end test covered both paths:

• amruthpillai/reactive-resume resolved to dsh-plugin-reactive-resume@0.1.0, was written to the isolated profile, and its bundle activated;
• nexu-io/open-design, whose catalog status was action_required, was rejected with HTTP 400.

Release and immutable asset:

• https://github.com/sandbaseai/dsh-plugin-store/releases/tag/v0.1.0-preview.5
• SHA-256: a046b0443c32ff4ed2078ea6238ca788be624b28223f5ce6b8a0ce7a61ce1b1a

Important boundary: this proves package provenance and restricted install input; it does not prove that every dependency resolves in the user's resulting profile or that the profile will boot. A concrete community review helped separate those gates. The next transaction is tracked as pre-mutation snapshot → local resolvability → offline composition → isolated boot/health probe → atomic rollback:

sandbaseai/dsh-plugin-store#7

Reports that include the DSH version, profile type, selected catalog entry, and the first failing gate are especially useful.

[ylwl1997]

Native Community/Installed views inside Settings is the right UX bet — discovery that never leaves the app wins on conversion.

From the catalog side we focus on a narrower slice: clean-profile install → load → boot/Q&A, then mark verified / pending / webonly, with copy-paste dsh plugin add commands (EN/ZH): https://dshbase.com/plugins/directory/

Happy to cross-link or share machine-readable dumps if useful (https://dshbase.com/api/plugins.json). Ecosystem is big enough for store UX + install-test directories to coexist.

[denial123789]

Thanks — this is a useful complement, and we should keep the evidence boundaries explicit rather than merge every signal into one opaque “verified” badge.

The Store can treat the dshbase dump as an independent clean-profile execution source while retaining its own catalog identity/provenance fields. The minimum join contract that would let us consume it safely is:

• canonical repository identity and exact install spec;
• DSH version/profile used for the run;
• separate install, load, boot, and Q&A outcomes;
• verification timestamp and an evidence URL;
• explicit pending / webonly states rather than inferring failure or compatibility.

That maps directly to our trust-evidence work in sandbaseai/dsh-plugin-store#11. We will preserve source attribution in the UI and never equate catalog presence with runtime verification. For non-npm/GitHub-subdirectory entries, the safe manual-install boundary is tracked separately in sandbaseai/dsh-plugin-store#10.

Happy to add reciprocal links once the field mapping is stable. If the current JSON fields are intended as a stable public contract, we can draft the adapter against the published dump and send back any identity or versioning ambiguities we find.