Extension document (extension publish): hm://<author>/<path> with metadata

{name, summary: manifest.description, seedExtension: <manifest>} and the README as body. The manifest is stored as
nested metadata attributes (seedExtension.kind, seedExtension.permissions, …); permissions is a real array. The
entry HTML is uploaded as a UnixFS file and referenced as seedExtension.entry = "ipfs://<cid>".

Install record (extension install): extensions.<mount> on the site's home document —

{ext, version?, title?, nav?, settings?}, one attribute per leaf. uninstall writes null to every leaf of the
record (the same op shape the desktop metadata editor uses), which removes it from the metadata entirely.

Schemas live in frontend/packages/client/src/extensions.ts; see design.md §3.

Publishes the extension package in <dir> under the signing key's account.

What it does:

Reads seed-extension.json (the manifest without entry; a $schema key is ignored), the entry HTML and the

README.

Refuses entries over 4 MiB and warns when the HTML references relative src=/href= paths (./, ../, /): the

entry is loaded through srcdoc in a sandboxed iframe, so nothing relative resolves — bundle to one file (e.g.
vite-plugin-singlefile).

Chunks the entry into IPFS blocks, sets manifest.entry = ipfs://<root cid> and validates the manifest with

ExtensionManifestSchema.

Creates the document at hm://<account>/<path> if it does not exist, or updates it in place if it does (metadata

diff + body replace, same as document update -f), so republishing keeps the document's history and lets pinned
installs be updated. A README whose first line is # <name> has that heading dropped from the body since the name is
already the page title.

Prints the id, the new version, the entry CID (plus its /hm/api/file/<cid> URL) and a copy-pasteable install

command:

With --json the same fields come back as {id, version, name, entry, entryUrl, web, action, install}.

The signing key's own account is always the publishing space. To publish under another space, publish the document with
document create -a <space> using a capability and add the seedExtension metadata there — the extension commands do
not take --account.

Fetches an extension document and prints its manifest. A ?v=<version> on the URL inspects that exact version (what a
pinned install runs). Non-documents and documents without a seedExtension manifest exit 1.

--json returns
{id, name, version, requestedVersion, manifest, permissions, entry: {cid, url}, authors, readme, install}.

Writes an install record into the home document of the signing key's account (the site).

Behaviour:

Fetches the extension first and validates its manifest; a non-extension is refused. A ?v= on the URL pins that

version; otherwise the current version is pinned. Pinning is the default — the site keeps running exactly the code
it approved until extension update (or the desktop's "update") re-pins it.

Validates the mount with EXTENSION_MOUNT_PATH_RE (board, tools/board; lowercase letters, digits, dashes).

Warns when a document (or redirect) already exists at hm://<site>/<mount>: the extension page shadows it in the site

UI, the document stays readable through the API (extensions often use that document as their data store).

Warns when the mount overlaps another install (board vs board/x); the longest match wins per request path.

Refuses to overwrite an existing record without --force (even an identical one); with --force, re-installing an

identical record publishes nothing (no-op).

On a site with its own domain the extension is served at https://<domain>/board.

Verify with seed-cli document get hm://z6MkmySite... --json → document.metadata.extensions.board.

Removes the record at extensions.<mount> by writing null to each of its leaves. Errors when nothing is installed
there.

Without a site argument it lists the signing key's own site. For every mount it fetches the extension document (at the
pinned version when there is one) to show its name and permissions, and reports when a newer version is available.

--json:
{site, extensions: [{mount, ext, version, pinned, title, nav, settings, name, permissions, latestVersion, error}]}. An
extension that cannot be fetched is listed with error set instead of failing the whole command.

Re-pins the install at <mount> to the extension document's current version by writing extensions.<mount>.version.
Prints a no-op message (exit 0) when the pin is already current, and when the install follows latest (there is nothing
to pin; use install --force to pin one). The new version's permissions are printed so a site owner sees what changed.

The extension commands publish under the signing key's own account only (no --account/capability flow yet).

settings values are written as nested attributes; arrays inside settings are stored whole (the daemon accepts any

CBOR value) but the desktop metadata editor cannot author arrays.

The CLI does not run the extension; use ?extdev= on the web app or the desktop dev override to iterate, see

design.md §7.