The platform

xQuakShell is a core of shared services with protocols attached to it. Everything beyond SSH arrives as a plugin: a separate process that uses the platform's services through a gated API and never reaches them directly.

Architecture

Core

Owns the vault, host and peer trust, the audit log, sync, the workspace and every security decision. Runs SSH, SFTP and the local shell itself.

Plugin process

One executable per plugin, or per session if it asks. Memory and handle limits, confined by the OS on Windows and Linux, killed with the application.

Channel

JSON-RPC 2.0 over the process's standard streams, plus a binary channel for byte streams. No shared memory, no code loaded into the core.

Manifest

plugin.json declares what the plugin contributes and every file, host, vault field and command it needs. The core enforces it on each call.

The core, not the plugin, decides compatibility at install and again at start. A version the plugin reports about itself is never trusted for enforcement.

Extension points

Connection protocols

A plugin registers a protocol with its label, default port and the fields it needs in the connection editor. Sessions render as a terminal tab or an embedded view: Telnet uses the first, VNC the second. The connection lives in the same tree, vault and sync as an SSH one.

Discovery under a connection

A plugin can draw a tree of groups and instances inside a connection's row, with actions on each node. The Docker plugin lists containers, images, volumes and networks under an SSH host this way. The host bounds depth, size and update rate.

Tabs, dialogs and node panels

A plugin can open tabs of its own (an interactive terminal or a read-only log with search and export), ask structured questions in a dialog, and fill the details panel of a discovered node. None of this grants access to the remote machine; it only decides where data the plugin already had may be shown.

Commands, status bar and panels

Commands appear in the palette under Ctrl+Shift+P. Status bar items and sidebar panels are declared in the manifest.

SSH authentication providers

A plugin can implement keyboard-interactive or public-key authentication steps for SSH connections. This requires your explicit consent, separate from installing the plugin.

Tunnel providers

A plugin can add a kind of forwarding rule next to local, remote and dynamic, with its own channel and bandwidth limits. It appears only after you grant tunnel consent on the plugin's row.

Channels over SSH

Through an open SSH session a plugin can run commands and relay TCP or UDP. Commands are declared as exact argument vectors with each parameter matched by a regular expression, so the plugin cannot compose a shell line of its own.

Network access

Plugins cannot open sockets. Outbound connections go through the core, to hosts on the manifest's allowlist; any-host and private-network access are separate flags that need consent at install.

Services a plugin uses

Service	How the plugin reaches it
Vault	Reads the connection fields and secrets its manifest names, for the session it owns
Peer trust	Reports the identity it saw; the core decides, asks you, and records the answer
Sync	Declares files under its data directory that follow the user between devices
Interface language	Is told the current language and may ship its own catalog
Audit	Its refused calls are recorded by the core, without secrets

Official plugins

Plugin	Extension point	Description	Links
VNC	Protocol, embedded view	Remote desktop in an embedded noVNC viewer: fit to window, quality and bandwidth controls, auto-reconnect	Releases, source
Telnet	Protocol, terminal	Plaintext terminal sessions with optional auto-login	Releases, source
Docker	Discovery, channels	Containers, images, volumes and networks under your SSH connections	Releases, source

Installing

Sources

GitHub or GitLab. Add a repository by URL, then install a release. Other hosts are refused.
File. A downloaded .xqsp bundle, or an unpacked directory while developing.
Your other devices. With sync on, a plugin installed elsewhere is offered, never installed by itself, and must match the exact build your other device installed.

Verification and consent

Every install runs download, checksum, signature and consent steps. A new vault accepts only signed plugins, and trusted publisher keys are yours to add. The install screen lists every grant before you agree; risky ones such as auth and tunnel providers need a separate approval.

The manifest

A plugin may only use what it declares. A Telnet-style connector needs a host and a password, and nothing on disk except its own data:

{
  "id": "com.example.telnet",
  "name": "Telnet",
  "version": "1.0.8",
  "engine": { "type": "go-binary", "entry": "telnet.exe" },
  "requires": { "pluginApi": "1.0.0" },
  "capabilities": {
    "filesystem": { "read": ["${pluginData}"], "write": ["${pluginData}"] },
    "vault": { "readConnectionFields": ["host", "port"], "getSecret": ["password"] },
    "session": { "connectProtocols": ["telnet"], "terminal": true }
  }
}

Building your own

Reference

Plugin API: IPC methods, session lifecycle, channels, discovery, UI surfaces
Manifest schema: every field and capability
Architecture: where plugins fit

Compatibility promise

pluginApi, capabilities, the manifest schema and bundleFormat are frozen
Changes are additive; a break needs a major version and two minors of deprecation
The application version and the API version move independently