Edge vs Platform Admin

Edge (@open-matrix/matrix-edge) and Platform Admin (@open-matrix/matrix-web) are two clients of the same set of bus actors. They run in different places, authenticate users differently, and may see different subsets of the namespace, but they render the same five registries (Devices / Runtimes / Mounts / Packages / App Routes), use the same shared shell primitives, and provide the same operations. Per P1.44, the asymmetry between them is the auth/identity boundary, full stop — not the feature set.

Where each runs

• Platform shell (@open-matrix/matrix-web) — runs on the HiveCast cloud Host. URL: https://hivecast.ai/apps/web/ (or any platform-role install). Authenticates via Google OIDC. Sees: every linked Device under the principal's authority root.
• Edge shell (@open-matrix/matrix-edge) — runs on every paired Matrix Device (laptop, workstation, server, container, VM). URL: http://127.0.0.1:3100/apps/edge/ (loopback) and https://hivecast.ai/<spacePath>/edge/ (paired public route). Authenticates via local-owner mode or paired-browser session. Sees: every Device in the user's namespace (the full namespace, not just this one), plus local-only diagnostics on this Device.

In production they are separate physical Hosts. In dev, both can run on one machine via the two-runtime topology described below.

The asymmetry rule (the only allowed differences)

The closed list of things matrix-web has that Edge does NOT have:

1. Cloud OAuth login flow. Edge uses local-owner mode (loopback) or a paired-browser session; identity comes from the linked-device credentials.
2. Device-pairing creation flow. Cloud generates the pairing token; Edge hands off via deep link.
3. Account-level admin. Multi-namespace switching, billing, account subscription, account deletion.
4. Cloud-only legal/compliance surfaces. Terms acceptance, GDPR data-export.

The closed list of things Edge has that matrix-web does NOT have (local-additive surfaces; augment, do not replace):

1. Raw Host logs viewer (the cloud cannot reach this Device's filesystem).
2. Local process info (ps of Host runtime processes, memory).
3. Local state-dir browser (<host-home>/runtimes/, <host-home>/instances/).
4. NATS server status / JetStream usage for this Device's local NATS.

Everything else is the same — same Devices view, same Runtimes view, same Mounts view (with the same filter pills), same Packages view, same App Routes view, same diagnostics, same actions where the user has grants.

Comparison table

Concern	Edge	Platform Admin
Scope	Full user namespace (all Devices), with this Device highlighted	Full account view (all Devices for the principal)
Hosted on	Every paired Matrix Device (default install)	The HiveCast cloud Host
Auth	Local-owner (loopback) or paired-browser session	Google OIDC
Read source	system.devices, system.runtimes, system.registry, system.catalog, system.packages directly over the bus (per P1.43)	Same bus actors
Five registries (Devices / Runtimes / Mounts / Packages / App Routes)	Yes — full parity per P1.44	Yes
Local-only diagnostics	Yes (logs, processes, state-dir, NATS status)	No (cannot reach the Device's filesystem)
Pair-creation flow	No (hands off to cloud)	Yes
Account / billing / subscription	No	Yes
Visual identity	Shared shell primitives (per P1.22c)	Same primitives

Why two shells at all

Three reasons:

1. Different authorities at the auth boundary. Edge can serve a local owner without any account login (loopback trust). The cloud cannot — it needs OAuth.
2. Different reach. Edge runs on the Device, so it can read local files, processes, NATS server logs. The cloud cannot. These are augmentations, not replacements.
3. Resilience. A user can keep using Edge — and the local apps it launches — when hivecast.ai is down. The substrate's local-first nature requires that the local control surface be complete, not degraded.

Why some apps appear in both shells

A package's matrix.json webapp.shells field decides which shell catalogs the app:

• ["platform"] — appears in matrix-web's catalog.
• ["edge"] — appears in Edge's catalog.
• Both — appears in both.

Director, Chat, Inference Settings declare both. The app itself runs on the user's Device in either case; only the catalog entry differs.

Two-runtime dev topology

To run both shells on one machine for development:

hivecast install --home /tmp/matrix-home --no-start
hivecast start --home /tmp/matrix-home --no-default-runtimes

matrix up @open-matrix/matrix-web --serve --port 5001 \
  --runtime-id WEB --env hivecast --startup auto --restart always

matrix up @open-matrix/matrix-edge --serve --port 5002 \
  --runtime-id EDGE --env hivecast --startup auto --restart always

Then:

• http://127.0.0.1:5001/apps/web/ — platform-role shell.
• http://127.0.0.1:5002/apps/edge/ — Device-role shell.

Both heartbeat to the same local system.devices. Cross-runtime ops route via local NATS. This is the same code path production HiveCast runs in its own Docker setup.

When to use which

• Operate this Device's local Host: Edge.
• Inspect logs, processes, state directories on this Device: Edge.
• Switch Spaces, manage billing, accept ToS, delete account: matrix-web.
• Pair a new Device: matrix-web (Edge shows the link).
• Either of "show me everything in my namespace" or "drill into a runtime / mount / package / app route": either shell — both render the same data the same way (per P1.44).

Common confusions

• "Why doesn't Edge show my other Devices?" — It should. Edge shows all Devices in the user's namespace per P1.44. If it doesn't, that is a regression; check the file an issue against matrix-edge.
• "Why is Edge styled differently from matrix-web?" — It shouldn't be. Per P1.22c, both shells share primitives; divergence is a regression.
• "Why does Edge ask me to pair when I just signed in to matrix-web?" — Sign-in is per-shell. Edge runs on loopback as local-owner without any login. The "Connect to HiveCast" affordance is for pairing this Device, not signing in to Edge.

See also

• What is Edge? — full role description.
• Local host view — the data model.
• HiveCast Platform / Overview / Admin surfaces — present/target state of the platform shell.
• P1.44 — the normative full-parity spec.

Source: projects/matrix-3/packages/matrix-edge/matrix.json and projects/matrix-3/packages/matrix-web/matrix.json for the shell declarations. WORKSTREAMS/loose-ends/items/P1.44-edge-full-local-control-surface.md is the normative SSOT for the full-parity rule.