dsh-std README

The project's README from github.com/T-Auto/dsh-std. As one markdown file: README.md.

DSH Standard

English | 中文

In plain terms, DSH Standard is a set of universal interoperability protocols. Its goal is simple: let DSH plugins, background runtimes, and various user interfaces (TUI terminals, Web UIs, desktop apps, headless daemons) decouple cleanly and work together smoothly.

@dsh-std/core is a "meta-protocol" (the protocol about protocols). Domain-specific protocols—like Command, Tool, Model, and Presentation—sit on top of this meta-protocol substrate for discovery and negotiation, each versioned independently. Different hosts and applications only implement the parts they actually need.

Reference packages provide types, validators, and pure-function negotiators. Conforming implementations are not required to depend on these npm packages, nor do they need to run inside DeepSeek Harness.

What is a "Meta-protocol" (The Protocol About Protocols)?

Most protocols you deal with handle specific domain tasks:

In contrast, @dsh-std/core knows zero domain business fields (it doesn't even know what a command or a model is). It is purely the "protocol about protocols":

Why is this powerful?
Monolithic frameworks hardcode every capability (commands, storage, events) into a central SDK; whenever a new domain arises, the entire framework requires a release or a breaking change. Under a meta-protocol architecture, the protocols themselves are pluggable plugins: public standards, community extensions, and private protocols alike register as standalone protocol definitions. The core never changes, letting the ecosystem evolve boundlessly on its own.

Why Decouple via Adapters?

The upstream DSH core and downstream ecosystem plugins have inherently different engineering priorities:

The Adapter serves as a single-point shock absorber: It isolates the upstream runtime from the universal protocol layer. DSH is free to refactor aggressively; all potential breaking changes are absorbed within a single adapter layer (@dsh-std/adapter-dsh), shielding the broader ecosystem from code churn. Similarly, standalone TUIs, Web frontends, and remote runners can plug in via their own adapters on equal footing.

What else is great about this (Beyond stable dependencies)?

Shielding plugins from upstream breaking changes is just the baseline. In day-to-day development, this architecture brings several concrete superpowers:

Vision: Layered, Optional, Non-coercive

Meta-protocol (core)   only defines how protocols are declared and negotiated; no domain concepts, no fixed roles
        |
Domain protocols       connection / command / tool / session / presentation / agent ...
        |              independently versioned, implementable and replaceable; future protocols may supersede them
        |
Profiles               admission and interoperability specifications for concrete product shapes,
                       carried by ecosystem projects (e.g. dsh-ecosystem-spec provides the TUI Profile)

Start here

Status

The code and proposals are early drafts.

Each package records changes in its own CHANGELOG.md. Public contract modifications must update the corresponding changelog.

Development

Node.js ^22.19 || >=24 and pnpm are required.

pnpm install
pnpm check

License

MIT

dsh-std (T-Auto/dsh-std)

Searching Database…

157 ·GitHub
Dsh-std
What is this?DSH Standard is a set of universal interoperability protocols that lets DSH plugins, background runtimes, and different user interfaces (TUI, Web UI, desktop apps, headless daemons) decouple from each other and work together.
Is this a runtime, or just a protocol spec with reference packages?It is a meta-protocol specification plus a set of npm reference packages (types, validators, pure-function negotiators) that implementations can optionally use; conforming code does not have to depend on these packages or run inside DeepSeek Harness.
How do I start using this in a plugin or host?Use the package index to pick the smallest implemented package surface you need, then build the monorepo with pnpm (for example `pnpm -r build`).
What do I need installed to build it?Node.js version ^22.19 or >=24, plus pnpm, are required to work with the repo.
Is this standard finished and stable?No, the code and proposals are explicitly labeled early drafts, so interfaces can still change; each package tracks changes in its own CHANGELOG.md.
Who is this meant for — plugin authors or host developers?Both: plugin authors who want their code to run unchanged across TUI, Web, remote SSH, and headless hosts, and host/tool builders who need to check plugin compatibility without executing plugin code.
What is the Adapter layer for?An adapter (like @dsh-std/adapter-dsh) absorbs breaking changes from the fast-moving upstream DSH runtime so that downstream plugins and other hosts keep a stable contract.
What is the Facet model?A single plugin package can bundle multiple facets (e.g. UI and backend logic), and a host only activates the facets it actually needs, so a headless server never loads frontend code and unused resources are never leaked.
Can tools check plugin compatibility before installing it?Yes, because plugins ship static manifests (dsh-plugin.json), marketplaces and CI tools can compute compatibility in milliseconds without running any plugin code.
Do I have to follow this standard to build a DSH plugin?No, adoption is voluntary; a project is free to use its own architecture, but if it claims conformance to a protocol version it must pass that protocol's conformance suite.
What are similar projects?dsh-plugin-bridge, dsh-plugin-shop, dsh_desktop, dsh-synapse, awesome-deepseek-harness-plugins, deepseek-harness, deepseek-harness-desktop, pi2dsh
Which topics is it in?specification, protocol, architecture, dsh, plugin-system, dsh-plugin, github-actions, monorepo, deepseek-harness, ci, json, testing
Creator
T-Auto
Size
0.8 MB
Stars
157
Updated
CommitOct 10
Age
2mo
Commits · 90 Days