中文 | English
The DSH plugin ecosystem is growing quickly. The more plugins there are, the more their ability to work together matters: if every plugin assumes or even overrides another plugin's internals, installing a few plugins starts to conflict and the ecosystem fragments. This is nobody's fault — it is the natural result of missing shared conventions.
We want to build an open, composable, and sustainable DSH plugin ecosystem:
- Open: anyone can participate; official, desktop, and third-party plugins compose on the same platform as equals.
- Composable: plugins extend against the same conventions, so they can be installed together and work together without interfering with each other.
- Sustainable: upgrades stay backward compatible, so the ecosystem can evolve long-term without being rebuilt from scratch.
- Composition first: compose capabilities through official slots, services, and patches; do not assume or override other plugins' internals.
- Declare clearly: state the services and slots you depend on; do not rely on runtime coincidences.
- Compatibility first: keep upgrades backward compatible and never break existing compositions.
WorkDSH Desktop uses Electron to carry a pinned official DSH runtime. The shell owns windows, installation, and packaging; WorkDSH features are composed as DSH plugins and Profile packages through official extension APIs alongside other compatible plugins. The Electron shell itself is not a DSH plugin.
This manifesto is not a unilateral rulebook. It is a living document: it follows ecosystem practice and accepts community discussion and revision. Any author can propose changes through issues, discussions, or pull requests.
Once the plugin marketplace ships, plugins that follow this manifesto will be easier to discover, install, and trust. We want convention-driven development to be the beneficial choice for every author, not an extra burden.
Plugins currently use the published DSH/Cordis APIs. Any future shared manifest or catalog should first be validated against real plugins, compatibility tests, and user needs. Capability declarations can help with compatibility, consent, and audit, but cannot present in-process JavaScript as a security sandbox. Only a Host with evidence of real isolation may claim technical permission enforcement.
There is no online market page or installer today. Future catalog inclusion would mean that a project met catalog rules, not that it passed a security review or received an endorsement.
- Learn how plugins are written in plugin development.
- Learn how to install and manage plugins in the user guide.
- Share your thoughts on this manifesto through issues and discussions.