community-extensions

Curator-signed registry index for Crux Daemon community extensions (Phase A external-tool + Phase B Wasm).

What this repo contains

.
├── index.json                              # signed registry index — the wire artefact
├── entries.json                            # input spec the curator runs through `build-index`
├── curator/
│   ├── Cargo.toml
│   ├── keypair.json                        # PUBLIC dev curator key (label-derived seed)
│   └── src/main.rs                         # `cargo run -p registry-curator`
└── extensions/
    ├── ext-quote/
    │   ├── manifest.json                   # the published manifest (Phase A)
    │   └── README.md
    └── ext-summarise/
        ├── manifest.json                   # the published manifest (Phase B / kind=wasm)
        ├── module.wasm                     # the Wasm bytes
        └── README.md

index.json is what corecruxctl extensions sync downloads and verifies.

Operator flow

corecruxctl extensions sync \
  --url        https://raw.githubusercontent.com/CueCrux/community-extensions/main/index.json \
  --pubkey-fpr p_4f5f8284d2af1610c1c382b2ab24c92a \
  --pubkey-hex 5a8fc6172cbc3660128cc8d83db579ab82185bfb61dd06eeb492d1e46afb1637 \
  --data-dir   ~/.cuecrux/crux

corecruxctl extensions list-registry --data-dir ~/.cuecrux/crux

Then install whichever extension you want by fetching its manifest URL and POSTing it to POST /v1/extensions/register. Install is always explicit per-extension — the registry sync does not auto-install.

Curator flow

To add or update an entry:

1. Edit entries.json. Each entry needs:

   • id, name, version, summary
   • manifest_url — the public HTTPS URL the operator's daemon will fetch the manifest from (typically a raw.githubusercontent.com URL pointing at this repo).
   • manifest_local_path — repo-relative path so the curator can read the file to compute its sha256.
   • repo_url — homepage / source-code URL.
   • kind — one of external_tool, wasm, etc.
   • trust_tier — FirstParty | LocallySigned | CommunityReviewed | Unknown.

2. Place the corresponding manifest.json (and, for kind=wasm, the matching module.wasm) under extensions/<dir>/.

3. Re-build the index:

   cargo run -p registry-curator

   This recomputes each manifest sha256, builds the CommunityExtensionsIndex document, signs it with the curator key from curator/keypair.json, and writes index.json.

4. Open a PR. CI verifies that the resulting index.json is valid by running cargo test -p crux-integrations (the community_index_sign_then_verify_round_trip test exercises the same code path the daemon's corecruxctl extensions sync uses).

Key rotation

curator/keypair.json carries a public, deterministically derived dev key. A real registry deployment would:

• Replace signing_key_seed_hex with a freshly-generated 32-byte random value, stored offline.
• Communicate the new fingerprint + public key out-of-band so existing operators can re-key their corecruxctl extensions sync invocation.

When that happens, every published index.json is re-signed with the new key (the entry contents stay byte-identical; only the signature changes), and operators verify the new signature succeeds before trusting any newly-published entries.

Adding the example extensions to the registry

The two example extensions live in their own GitHub repos and are intentionally licensed MIT (the daemon ships under CCL; the example templates need to be forkable):

• CueCrux/example-extension-quote-of-the-day — Phase A
• CueCrux/example-extension-wasm-summarise — Phase B

Their manifest.json files (and the .wasm bundle for the wasm one) are mirrored into extensions/<dir>/ here so the registry stays self-sufficient: a sync against this repo only needs to talk to GitHub.

Licence

MIT — see LICENSE. The registry contents (other operators' manifests) each carry their own licence; check extensions/<dir>/README.md for the per-extension one.