Plugins and catalogue
Application support ships as signed packages from a synchronised catalogue, with capabilities you grant explicitly.
A plugin is the installable package. An adapter is that package bound to a running application. Core KalaReach supplies transport, process and terminal primitives, the authority checks and the standard interface components. It does not carry a list of every application anyone might run.
That means a vendor can add detection, event interpretation, buttons, commands, file handling and voice context for its own tool without waiting for a KalaReach release. The first-party plugins use exactly the same contract.
The catalogue synchronises as metadata
A host fetches the complete signed metadata snapshot: descriptions, match rules, capability declarations and the hash and size of every payload. Because the whole index is held locally, matching an installed application against a package needs no network. Executable payloads and large assets are fetched by content hash when you install or enable a package, when an already authorised match activates one, or when you deliberately mirror a repository in full. None of them runs before the package verifies and its grants are in place.
- Bundled, installed, pinned and currently bound payloads stay available offline. A payload that is not cached reports
PACKAGE_UNAVAILABLE_OFFLINErather than pretending the capability is active. - An interrupted sync leaves the previous valid index and the installed packages working. Index activation happens once the metadata verifies; each package activates separately once all of its payloads verify.
- A full offline mirror is an explicit setting with its own budget, not the default sync strategy.
# Adopting a root is the owner’s decision, made from an owner device.
$ kr plugin repo sync <repository>
# Fetches the newest generation inside the trust already adopted.
$ kr plugin install <repository> <plugin> <version> --digest <hash>
$ kr plugin list
Signing and trust
Repositories use the TUF metadata roles: root, timestamp, snapshot and targets. A vendor can hold a delegated role beneath a repository’s root, scoped to its own publisher path. Each repository keeps its own root, which you adopt deliberately, and adopting a second root never widens the first. Expired metadata blocks new generations while already installed pinned packages keep working offline under the grants they already have.
Synchronising runs no installation scripts. Unsafe extraction paths, links, colliding names and undeclared size expansion are rejected. A signature establishes provenance; it is not a claim that the code is safe.
Capabilities are granted, not assumed
Enrolling a repository sets a ceiling, so thousands of passively downloaded definitions do not turn into thousands of permission prompts. The default ceiling allows metadata matching, declarative presentation and semantic events that were already authorised. Everything beyond that is an explicit grant:
- raw terminal streams and transcript tails
- filesystem, network and process access
- sending input, mutating anything upstream, or approving an operation
- a new executable bridge, or any increase in privilege
Downloading the whole catalogue does not activate any of it. Match rules are indexed by executable and distribution, and only matching, enabled packages are instantiated. Your explicit choice always wins a conflict, and a live binding stays pinned to the exact package hash it started with.