You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenBKN is an open-source business knowledge-network platform. Its DeepSeek Harness integration is being developed as a formally publishable, out-of-tree plugin: https://github.com/openbkn-ai/bkn-dsh
The plugin uses the documented Typert pattern: a Host service extends TypertRemoteService and marks safe Client-facing methods with Remote. The methods cover only authentication status, authorized network selection, immutable session binding, and lazy provenance reads; credentials and arbitrary command execution remain Host-only.
Problem
With dsh-v0.1.2-rc.1, the Typert source analyzer recognizes Remote metadata only when dsh-typert-protocol is registered inside the DSH monorepo. A third-party plugin correctly importing the installed official protocol package is therefore rejected during artifact generation with: publishes Remote artifacts but has no Remote methods.
This blocks strict generated Host-to-Client contracts for external plugins and leaves an undesirable choice between handwritten bridges and weaker source fallback behavior.
Proposed compatibility boundary
Treat a resolved declaration as official Remote metadata when, and only when, its installed package identity is exactly @deepseek-ai/dsh-typert-protocol. Do not accept arbitrary packages that export a similarly named Remote decorator.
The implementation is intentionally small: retain the existing in-workspace recognition path and add the exact external package-identity check.
Validation
A local reference patch is available in the OpenBKN maintainer fork:
The regression coverage includes both a positive installed-official-protocol case and a negative lookalike-package case. The OpenBKN plugin has seven Remote methods, all discovered by the patched analyzer with TypeScript diagnostics enabled.
Questions
Would this exact-package recognition be an acceptable compatibility rule for formally published third-party DSH plugins? If so, could it be carried in a future release of the Typert generator?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Background
OpenBKN is an open-source business knowledge-network platform. Its DeepSeek Harness integration is being developed as a formally publishable, out-of-tree plugin: https://github.com/openbkn-ai/bkn-dsh
The plugin uses the documented Typert pattern: a Host service extends TypertRemoteService and marks safe Client-facing methods with Remote. The methods cover only authentication status, authorized network selection, immutable session binding, and lazy provenance reads; credentials and arbitrary command execution remain Host-only.
Problem
With dsh-v0.1.2-rc.1, the Typert source analyzer recognizes Remote metadata only when dsh-typert-protocol is registered inside the DSH monorepo. A third-party plugin correctly importing the installed official protocol package is therefore rejected during artifact generation with: publishes Remote artifacts but has no Remote methods.
This blocks strict generated Host-to-Client contracts for external plugins and leaves an undesirable choice between handwritten bridges and weaker source fallback behavior.
Proposed compatibility boundary
Treat a resolved declaration as official Remote metadata when, and only when, its installed package identity is exactly @deepseek-ai/dsh-typert-protocol. Do not accept arbitrary packages that export a similarly named Remote decorator.
The implementation is intentionally small: retain the existing in-workspace recognition path and add the exact external package-identity check.
Validation
A local reference patch is available in the OpenBKN maintainer fork:
The regression coverage includes both a positive installed-official-protocol case and a negative lookalike-package case. The OpenBKN plugin has seven Remote methods, all discovered by the patched analyzer with TypeScript diagnostics enabled.
Questions
Would this exact-package recognition be an acceptable compatibility rule for formally published third-party DSH plugins? If so, could it be carried in a future release of the Typert generator?
Related out-of-tree plugin context: #5672.
All reactions