Community Marketplace

Phase З.3 of the GA roadmap: the skill marketplace from Phase Б.4 grew up. Five categories now share the same publish + sign + verify + sandbox install pipeline.

Categories

The catalogue is extensible — marketplace_categories is a real table; future categories slot in with their own permission validators + installer adapters.

Installing

1. Marketplace in the OS dock.
2. Pick a category tab — search / filter / sort within it.
3. Click an item → drawer with full description, manifest, permissions, reviews.
4. Install. Behind the scenes:
   • SHA-256 of the package verified.
   • Manifest Ed25519 signature verified against the author’s public key.
   • Per-category dispatcher hands off to the right installer (apps → app installer, themes → themes registry, etc).
   • License-cap check (per-category — marketplace_install_<category>_cap).

Submitting

1. Control Center → Marketplace → Submit.
2. Pick category. Upload package. CP fills in package_sha256, signs the manifest with your verified-author Ed25519 keypair.
3. Submission lands in the admin moderation queue with moderation_status='pending'.
4. Admin approves → published. Reject → you see the reason; resubmit after fixing.

Plans

License gates: marketplace_browse (always on), marketplace_install_<category>_cap (per-category), marketplace_publish (Pro+). Legacy marketplace_install_cap from Phase Б.4 aliased for one release.

Manifest schema

pkg/marketplace-manifest/manifest.go is the shared package between OS + CP. The Kind field selects the category:

kind: widget                         # apps | skills | widgets | themes | plugins
name: my-widget
version: 1.0.0
author_id: …
package_sha256: …
permissions:
  - data:read.metrics
  - refresh:30s
manifest_signature: …                # Ed25519 over canonicalised manifest

Per-category permission validators reject mismatched manifests at publish time:

• apps accepts docker capabilities + ports + mounts.
• skills accepts the Phase Б.4 sandbox capabilities (network, chat_inject, fs:tmp).
• widgets accepts data:read.* + refresh:* only.
• themes rejects all permissions (pure presentation).
• plugins accepts MCP-tool strings.

API

GET  /api/v1/marketplace/categories                                 → bootstrap data (id, name, description, icon)
GET  /api/v1/marketplace/{category}/items                           → list
GET  /api/v1/marketplace/{category}/items/{slug}                    → detail
POST /api/v1/marketplace/{category}/items                           → submit (Pro+ author auth)

GET  /cp/api/v1/admin/marketplace/queue                             → moderation queue
POST /cp/api/v1/admin/marketplace/queue/{id}/approve   { note }     → 204
POST /cp/api/v1/admin/marketplace/queue/{id}/reject    { note }     → 204
POST /cp/api/v1/admin/marketplace/queue/{id}/flag                   → 204 (mark for review)

Legacy /api/v1/marketplace/skills/... paths from Phase Б.4 remain as 301 redirects for one release cycle.

Sandbox + integrity

Unchanged from Phase Б.4. Every installed item runs through the same isolation layer; package_sha256 and Ed25519 signature verify before unpacking. Per-category permissions map to sandbox capabilities; the installer rejects on mismatch.

Per-category installer status

Manifest signing, moderation queue, and the gallery UI work for all five categories regardless. The stub categories will accept a submission, queue it, and surface it in the OS gallery — only the actual installation step no-ops until the registry-side adapter wires up.

Out-of-scope follow-ups

• Paid listings + revenue share.
• Auto-update channels (manual update only at v1).
• Private marketplace registries.