dsh-std

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:

• A Command protocol handles how commands are registered and executed;
• A Model protocol governs how LLM providers are plugged in;
• A Presentation protocol handles UI dialogs, questions, and approvals.

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":

• It defines universal primitives: how protocols are identified (apiVersion + kind), how participants declare what they need (requires) and what they provide (supports), and how to run pure-function negotiations to output a structured compatibility report.
• An analogy: It works like the USB interface specification. The core only cares about physical pinouts, slot dimensions, and handshake negotiation. Whether you plug in a mouse, keyboard, thumb drive, or webcam, the core never needs to know or change.

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:

• Upstream DSH focuses on rapid innovation: Its mission is to build the fastest, most capable Agent execution engine, requiring frequent iteration over model scheduling, context engineering, and internal architecture. The core should not have its hands tied by external UI variations or third-party interop standards.
• Downstream plugins need stable contracts: Plugin authors want to focus on feature logic without worrying that their code will break with every upstream update.

Adapter functions and implementation An adapter maps internal product services to the standard protocols the product adopts. Reusable adapters can reduce repeated product API integration work for third-party plugins. Each project can design its own adapter or use an existing implementation.

Third-party plugins target the protocol contracts they adopt; adapter internals and package names are not a shared entrypoint. @dsh-std/adapter-dsh provides a set of mappings for DeepSeek Harness. TUIs, Web frontends, remote runners, and other integrators can provide their own implementations. Compatibility depends on protocol versions, live capabilities, and product mappings.

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

Separating protocol contracts from product implementations supports the following development patterns:

• Less repeated platform integration: Plugins can reuse business logic that follows protocol contracts, while each product's mappings connect it to local capabilities.
• On-Demand Activation & Zero Leaks (Facet model): A single plugin package can contain both frontend UI and backend logic. A host only activates the facets it needs (e.g., a headless server never loads frontend UI code). When a plugin is disabled or uninstalled, all listeners, timers, and resources are automatically garbage-collected by the scope.
• Know Before Installing (No crash roulette): With static manifests (dsh-plugin.json), marketplaces, hosts, and CI tools calculate compatibility in milliseconds without running a single line of plugin code. No more installing a plugin only to find out it crashes at runtime.
• Blazing-fast Headless Unit Tests: The protocol core consists entirely of pure data structures and pure-function negotiators. Testing plugins or hosts takes tens of milliseconds in lightweight Node.js/CI—no need to spin up a full DSH instance or heavy browser.
• Decentralized Ecosystem Growth: Want to create a novel Agent capability (like special multimodal streaming or bespoke tool hooks)? Define your own protocol and run with it—no need to wait for approval or central releases.

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)

• Adoption is voluntary: No project is forced to adopt this standard; but once claiming conformance to a protocol version, it must pass the corresponding conformance suite.
• Radical Agent exploration welcomed: Headless clusters, long-running daemon agents, and distributed collaborative systems can all grow naturally on top of the meta-protocol.
• Projects wanting a familiar "Host + Plugin Manifest" experience can follow the relevant Profile; those with other architectures remain completely unrestricted.

Start here

• Read the architecture for the boundary between the meta-protocol, independent protocols, and product implementations.
• Read the cross-profile application guide to see how one plugin package relates to the several profile compositions that may mount it — browser, terminal, desktop, or no user interface at all.
• The current design work is indexed in the Chinese proposal index.
• See the Endpoint Connection proposal for connection negotiation and attachments.
• Use the package index to select the smallest implemented package surface.
• Adapter code for DSH lives in @dsh-std/adapter-dsh.

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

Releasing

Published package versions are maintained directly in each packages/*/package.json; the release workflow does not rewrite them. A push to main compares those versions with the pre-push commit, then packs, OIDC-publishes, tags, and creates a GitHub Release for every increase. Prerelease versions use their prerelease identifier as the npm dist-tag (rc, alpha, or beta); stable versions use latest.

The release job is restricted to this repository's GitHub ID, so ownership transfers do not disable it and forks do not publish packages. GitHub Releases target the repository running the workflow through GH_REPO.

For the transfer to T-Auto/dsh-std, each published npm package's trusted publisher must use owner T-Auto, repository dsh-std, and workflow release.yml (with no environment). Configure this in the package's npm settings before publishing from the transferred repository; GitHub ownership transfer does not update the npm configuration. See npm trusted publishing.

License