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…

Что это?DSH Standard — набор универсальных протоколов взаимодействия, который позволяет DSH-плагинам, фоновым рантаймам и разным пользовательским интерфейсам (TUI, Web UI, десктоп-приложения, headless-демоны) отвязаться друг от друга и при этом работать вместе.
Это рантайм или просто спецификация протокола с референсными пакетами?Это спецификация мета-протокола плюс набор референсных npm-пакетов (типы, валидаторы, переговорщики на чистых функциях), которые реализации могут использовать по желанию; соответствующий код не обязан зависеть от этих пакетов или работать внутри DeepSeek Harness.
Как начать использовать это в плагине или хосте?Возьмите индекс пакетов и выберите наименьший реализованный набор пакетов, который вам нужен, затем соберите монорепозиторий через pnpm (например, `pnpm -r build`).
Что нужно установить для сборки?Для работы с репозиторием нужны Node.js версии ^22.19 или >=24 плюс pnpm.
Стандарт уже завершён и стабилен?Нет, код и предложения прямо помечены как ранние черновики, так что интерфейсы ещё могут меняться; каждый пакет отслеживает изменения в своём CHANGELOG.md.
Для кого это — для авторов плагинов или разработчиков хостов?Для тех и других: авторы плагинов хотят, чтобы их код работал без изменений в TUI, Web, удалённых SSH- и headless-хостах, а создатели хостов и инструментов — проверять совместимость плагинов, не исполняя код плагина.
Зачем нужен слой адаптеров (Adapter)?Адаптер (например, @dsh-std/adapter-dsh) впитывает ломающие изменения из быстро меняющегося апстрим-рантайма DSH, чтобы нижестоящие плагины и другие хосты сохраняли стабильный контракт.
Что такое модель фасетов (Facet)?Один пакет-плагин может содержать несколько фасетов (например, UI и логику бэкенда), а хост активирует только те фасеты, которые ему действительно нужны: headless-сервер никогда не загрузит код фронтенда, а неиспользуемые ресурсы не будут расходоваться.
Могут ли инструменты проверить совместимость плагина до его установки?Да: поскольку плагины везут статические манифесты (dsh-plugin.json), маркетплейсы и CI-инструменты вычисляют совместимость за миллисекунды, не исполняя ни строчки кода плагина.
Обязательно ли следовать этому стандарту, чтобы сделать DSH-плагин?Нет, принятие добровольное; проект волен использовать свою архитектуру, но если он заявляет соответствие версии протокола, то обязан пройти набор проверок соответствия этого протокола.
Creator
T-Auto
Size
0.8 MB
Stars
158
Updated
CommitOct 10
Age
2mo
Commits · 90 Days