Extensions Store

Aleph presents Skills, Plugins, and MCP servers as one user-facing concept: an Extension. The Hub lets users browse by function, inspect the kind and trust tier, disclose the install behavior, configure secrets, install, verify, toggle, and uninstall.

One concept, three kinds

The primary browse axis is functional category: Search, Developer, Data, Productivity, Writing, Communication, Knowledge, Files, Design, Automation, Finance, Utilities, and Other. Kind and trust tier remain filters and card badges.

Aleph Hub is the catalog source

The official catalog source is the single aleph-hub artifact:

https://hub.heyaleph.com/catalog.json

The daemon stores the normalized catalog in:

~/.aleph/hub_catalog.db

Each artifact contains a schema version, Hub ID, objective extension entries, trust tier, and an install_spec. Per-user fields such as installed and enabled are stamped locally and are not trusted from the wire.

At cold start, hub::primer fills the aleph-hub cache slot only when it is empty. It composes the bundled official MCP, skill, and plugin projections into that same slot. A successful non-empty fetch replaces the slot; a failed or empty fetch keeps the last-good cache. Ingestion performs schema validation and scans entry text for suspicious prompt-injection patterns.

The catalog layer is not a concurrent federation of independent providers. Installation resolution is a direct lookup of ExtensionEntry.install_spec in the local cache. Plugin marketplaces remain a plugin installation backend; they are not additional Hub catalog slots.

The retired MCP preset RPCs mcp.list_presets and mcp.install_preset are not the discovery path. MCP discovery and installation converge on the Hub catalog.

Installed-state reconciliation

extensions.catalog reads the cached catalog and overlays the live installed set. extensions.installed queries the MCP manager, plugin manager, and shared SkillSystem locally, so the installed view works without a network request.

Local entries use IDs of the form local:{kind}:{backend_id}. Catalog entries remain catalog IDs and are not accepted by toggle or uninstall; lifecycle operations require a local installed ID. Unmatched manual MCP servers and local skills remain visible as local, unlisted extensions.

MCP catalog entries match their deterministic derived server ID. Plugin and skill entries match the live backend by kind and case-insensitive name. Enabled state is always taken from the live backend.

Trust and disclosure

Every Hub install builds a disclosure before side effects occur. Trust tiers are:

• Official
• Verified
• Community
• Unverified

The disclosure includes the fields that apply to the install specification:

• exact stdio command and arguments
• required and sensitive secrets, with their purpose when declared
• network endpoint or declared filesystem/runtime reach
• version
• SHA-256 pin when supplied by the catalog or marketplace
• trust tier and provenance
• injection findings from entry text

Risk is derived from the install specification:

Community and Unverified command-running installs require an explicit user acknowledgement. A Git checkout used for a skill or plugin always requires a user gesture because it writes instructions or executable content. OCI/Docker MCP images are browsable as catalog entries but the current install router rejects them.

Secrets are written to the encrypted vault under a namespaced extension field key. MCP configuration stores a {{secret:NAME}} reference, never the plaintext value; the secret is resolved only at the process-spawn boundary.

The approval path also scans names and descriptions for zero-width characters, bidirectional overrides, and suspicious instructions such as requests to ignore earlier instructions, read .env, exfiltrate data, or reveal the system prompt.

Installation pipeline

catalog entry
  → resolve cached InstallSpec
  → build disclosure and injection findings
  → user acknowledgement when required
  → validate required configuration
  → store secret fields in the vault
  → route by InstallSpec
  → post-install verification
  → return outcome and approved pin

Routes are:

• McpStdio and McpRemote → add and start through McpManager
• GitDir with kind Skill → isolated checkout, copy into the skills directory, record source metadata
• GitDir with kind Plugin → marketplace installation with SHA-256 verification and atomic copy
• OciImage → rejected in the current version

For stdio MCP, the command must already resolve on PATH; a missing runtime fails before a server is persisted.

Built-in Hub tools and agent boundary

The active built-in tools are:

The current main branch does not register a separate hub-agent, and HUB_TOOLS is not an active agent-owned allowlist. These tools are registered in the main built-in tool registry; hub_install_run is operator-gated, while read-only verifier agents explicitly deny the Hub tools. An LLM-controlled call cannot supply user acknowledgement: an acknowledgement-required install returns a consent result with no install or secret-storage side effect.

hub_fetch_docs is implemented as a bounded, SSRF-checked, injection-scanned scaffold and is not wired to a user-facing long-tail install flow. Do not document it as an autonomous repository installer.

Gateway façade

The UI uses a thin extensions.* façade:

Advanced per-kind surfaces remain available, including the canonical singular plugin.* namespace and compatibility plugins.* aliases.

Related pages

• Extensions — Plugin kind and runtime host
• Extension System — discovery and registration architecture
• Skills — Skill kind authoring
• Skill System — Skill backend
• Capability System — declarations, permissions, and runtime ledgers