dsh-market/dsh-market

dsh-market

English | 中文

The plugin market inside DeepSeek Harness. Open Settings → Plugin Market → browse, search, one-click install.

One-click themes: install, switch live, no restart.

Install

dsh plugin --profile web add dshmarket

Restart dsh web, then open Settings → Plugin Market.

Requires dsh web 0.1.0-rc.6 or newer. On an older host the market disables itself and says so in the browser console rather than rendering against primitives that are not there — if the Plugin Market entry never appears, that is usually why. Worth checking when a desktop build bundles its own dsh: it may be older than the one npm would give you (#139).

What you get

• Browse & search the full community catalog (4200+ plugins, growing daily) — category filters, star counts, top/new sorting, bilingual descriptions that follow your UI language
• Host-aware discovery — cards show the DSH requirement declared by engines.dsh or lockstep @deepseek-ai/dsh-* peers; an opt-in filter hides only confirmed mismatches with the running host. Undeclared, malformed, unavailable, and GitHub-only entries remain visible rather than being guessed incompatible
• Screenshots — AppStore-style screenshots, auto-carousel when there's more than one, click to preview full-size: author-curated shots show right on the card (zero extra requests); plugins without curated shots fall back to automatic README extraction once you open the install dialog. Images load from GitHub hosting only
• Comments — every card opens the plugin's discussion thread in place. It is the same thread its pages on dshmarket.com and the catalog show, so a plugin has one conversation rather than three. Backed by GitHub Discussions through giscus: it loads when you open it, needs a GitHub account only to post, and the note above it says plainly that opening it contacts giscus.app and GitHub. On local dsh web, reading stays embedded while a dedicated GitHub action opens the exact discussion in a new tab for sign-in and posting, so the cross-site return never carries or depends on the host session
• Favorites — bookmark plugins and themes from Discover or the Themes tab; a dedicated Favorites tab lists them with search, sort, and install actions. Bookmarks persist in the profile's market state (state.json); entries that leave the catalog can be cleared in one click
• Groups — organise installed plugins into named groups (rename, delete, and per-group search); a plugin lives in one group and ungrouped is the default. Purely organisational: the panel says so, and nothing about enable state changes. The grouping itself is local state in the profile's state.json
• Notes — write your own one-line description for any installed plugin and it replaces the author's on that row, so a shelf of forty plugins answers "why did I install this" in your words. Stored locally beside groups and favorites, never sent anywhere
• Themes — a dedicated tab for community themes and skins: install → active immediately, switch with one click (themes are mutually exclusive, your choice survives restarts), uninstall to revert
• One-click install — confirm the source, watch live progress; most plugins go live after a page refresh, no restart
• Backup & restore — export your profile's plugin list and configuration as readable JSON, import it on another machine, store it on WebDAV with daily auto-backup, or sync through a private GitHub Gist; restores merge (plugins installed after the backup are kept), validate before writing, and roll back on failure
• Updates — per-plugin update checks (npm version or pinned commit vs HEAD), one-click update, or update everything at once; the market updates itself the same way. A plugin installed from an archive link is updated only through its own source: a catalog entry that merely shares the name is never offered as its update, so updating cannot silently replace it with a different plugin. Each row with an update pending carries a What changed link — the release notes, or the commits when the version cannot be aligned to one. A notice you are not acting on can be ignored for the rest of the boot instead of being dismissed again on every reload — scoped to the running host, so a restart brings the reminder back and ignoring it is never the same as turning it off
• Resilient GitHub routes — in the China download region, Git refs, README content, and avatars each keep their own fallback order. The market remembers the last working route, switches only after transport/HTTP/payload validation fails, and rejects proxy error pages disguised as HTTP 200. If every built-in route fails, Settings → Plugins → Plugin configuration → GitHub acceleration accepts one persistent custom HTTPS prefix; DSHM_GITHUB_PROXY remains the operator-owned override
• Public update API — plugin-owned settings pages can use the versioned, capability-gated update API v1 (beta) instead of copying package-manager logic or depending on private Market UI responses
• Uninstall — two-step confirm; plugins installed this session are removed live
• Hot disable / enable — toggles write - id: … + disabled: true|false into the profile's cordis.patch.yml (the official patch layer, mechanism ported from dsh-plugin-hub): DSH's HMR re-composes within ~1s, no restart, and the loader re-applies the choice on every boot; hand-edited patch rows show as badges, host-infrastructure plugins are protected from toggling, and a malformed patch file is never made worse
• Restart when needed — changes that cannot hot-load show a one-click restart beside the pending-change banner; the action is restricted to same-origin loopback requests
• Recovery when a restart does not come back — DSH's boot is all-or-nothing: one plugin that cannot load stops the whole process, and the market's own UI dies with the host it was serving from. Now that failure prompt offers Adjust plugins: the ones DSH blamed are marked red and left unticked, you choose what should be enabled at the next start, the choice is written through the same cordis.patch.yml rows the market's own toggles use (plus dsh.profile.bundles for a disable-carrier), and the boot is retried. It is served by the detached restart helper on the same address the page was already polling, so it works even though the host is gone — and opening the URL fresh renders a standalone version of the same page. When DSH starts normally, none of it appears
• Zero jargon — if a component is missing (pnpm), the market detects it and offers a one-click automatic setup
• Log export — one click produces a sanitized plain-text log for bug reports (home paths and credential shapes are masked; nothing is ever sent anywhere). The market's version sits next to the page heading, so a screenshot of a problem already carries it
• Settings card — on dsh 0.1.0-rc.7 and newer the market manages itself from Settings → Plugins → Plugin configuration, next to every other plugin: see the running version, pick a release channel (stable, or beta to try builds still being verified — the market only, never your other plugins; a third dev channel appears once developer mode is switched on, and carries builds published straight off a branch), update, or remove the market — with an opt-in cleanup that also drops the disable rows it wrote, so plugins it switched off start running again rather than staying off with no UI left to switch them back on
• Diagnostics — the plugin load order and conflict surface, one page: bundle stack with official/community badges, duplicate loader entries, dependency version mismatches, multi-version core packages, overrides and invalid config entries, and leftover directories — a package directory an interrupted update left without its package.json, and pnpm's own *_tmp_* staging directories. Nothing there stops a start, so it is listed rather than warned about, and it is the only place that names what is on disk. Plain-language terms, problem blocks highlighted, everything collapsible