In DSH workflows, running multiple sessions concurrently is normal (for example, one for research and one for coding). The issue is not that sessions cannot “see” each other, but rather that there is no programmatic relationship layer to manage permission boundaries, shared resources, and loading capabilities. Existing approaches often hard-code these behaviors inside plugins, making them inflexible. dsh-connection-card-host aims to solve this problem.
Plugin Introduction¶
This plugin elevates “connections” to a first-class citizen in DSH. It defines sessions as nodes, connections as containers, and cards as connection-scoped plugins. In essence, it provides a “connection-level plugin host.”
- Maintainer: Noob-stupid
- License: MIT
- Category: Workflow
Core Features¶
This plugin provides multiple ways for two sessions to interact through the connection layer, without interfering with each other:
- Mutual visibility: Automatically collects the other party’s state, including running commands, recently edited files, plan progress, and so on. This information is pulled by the other party on demand and incurs no extra cost.
- Mutual communication: Supports multiple messaging methods (notification, queue, interruption, preemptive interruption), but sending a message forces the receiver to run a turn.
- Shared tools: Achieved through “cards” mounted on the connection. Cards can provide tools to sessions and are not limited by the plugin’s own size, supporting real dependencies of tens of MB.
- Shared conventions: Provides a “convention box” for storing agreements reached by both parties, such as interfaces, units, naming conventions, and resource ownership.
- Non-intrusiveness: The awareness mechanism is pull-based, so no overhead is generated unless the other party actively asks. Irrelevant connections will not interrupt the current session.
Typical Usage¶
Establish a Connection¶
Establishing a connection in the DSH interface is straightforward:
- Action: Press and hold the circle to the left of the composer, or the
...on the session row, and drag it to the target row in the session list. - Target: Dropping it on a target session row means “Connect”; if the row is already connected, it means “Disconnect”.
- Recovery: Connections are automatically restored the next time DSH starts.
Visuals and Permissions¶
After a connection is established, a “track” appears next to the session row, with a colored dot at each end indicating permissions for that direction. Permissions are determined jointly by both parties.
Applicable Scenarios and Notes¶
- Applicable scenarios: Suitable for scenarios where multiple sessions need to collaborate while remaining isolated and interacting on demand. For example, one session handles writing code, another runs experiments, and they share tools and conventions through a connection without interrupting each other.
- Notes:
- Pull-based awareness: Whether the other party can “see” your state depends entirely on whether they actively query it. If they do not ask, perceiving their state costs nothing.
- Message-triggered execution: In DSH, sending a message is not merely a notification; it forces the receiving session to enter the next run cycle.
- Card limitations: Cards mounted on a connection are constrained by the connection’s permissions, and all capabilities must be provided through the connection.
