HiveCast Platform

Appearance

Dashboard: Packages ​

Status: target state. No registry UI today. Packages bundle with the wrapper. The Gitea-as-npm-registry is partially designed; the admin package view is unimplemented.

Target view ​

A package registry overview:

  • Every package the platform knows about.
  • Available versions per package.
  • Dependency graph between packages.
  • Per-package adoption: which Devices run which version.
  • Publish workflow buttons (operator-only).
  • Verification status (signature, integrity).

Drill-in to one package:

  • Version history.
  • Download/install counts.
  • Dependent packages.
  • Compatibility matrix (target).
  • Source manifest.

What exists today ​

A package is whatever lives under <host-home>/.matrix/packages/<package-name>/. The wrapper bundles a known set on install (per Overview / Package deployments). There is no registry to list, no version picker, no install-from-registry op.

Where packages exist on the platform Host ​

bash
ls /var/lib/hivecast/host-home/.matrix/packages/
# system, host-control, system-gateway-http, matrix-web, matrix-edge,
# director, chat, inference-settings, flowpad, smithers, ...

Each directory has a package.json with name, version, and a matrix.json describing actor / webapp metadata.

Per-Device adoption (workaround) ​

To find out which Devices run which version of a package today:

bash
# For each Device's <host-home>, inspect the package directory.
# Or read system.devices.devices.list and join with hivecast --version per Device.

There is no central record. The wrapper version implies the package version set, but operators must track it externally.

What the target needs ​

  1. Gitea-backed npm registry. Designed in ARCHITECTURE-PLATFORM-TOPOLOGY.md §8. Not implemented.
  2. Registry-pull op. host.control packages.pull '{"package":"foo","version":"1.2.3"}'. Not implemented.
  3. Per-package adoption query. Roll up across system.devices. Not implemented.
  4. UI in matrix-web.

Package authoring today ​

For now, package authors:

  1. Edit source under projects/matrix-3/packages/<name>/.
  2. Bump package.json version.
  3. Build (per-package node build.mjs or workspace pnpm build:affected).
  4. Cut a wrapper release.
  5. Distribute the wrapper.

There is no published-to-registry step. The wrapper is the distribution mechanism.

Compatibility matrix ​

There is no compatibility matrix. Each wrapper release implicitly bundles a known-good set. Cross-wrapper-version compatibility is not tested or guaranteed.

A target compatibility matrix would record:

  • Package A version X works with Package B versions Y..Z.
  • Migration path between major versions.

Verification ​

Today: no signing. The wrapper itself is OS-package-manager-signed (apt).

Target: signed package manifests, signature verification at install time.

See also ​

Source: WORKSTREAMS/docker-npm-parity/ and ARCHITECTURE-PLATFORM-TOPOLOGY.md §8.