Dashboard: Devices

Status: partial. Per-principal Device list is fully implemented in the user shell. Cross-principal admin fleet view is target state.

What exists for the user

The signed-in user shell (/apps/web/#dashboard) renders the principal's own Devices today, with:

Online / offline / revoked status.
hostName, deviceSlug, lastSeenAt, routeKey / Space path.
Runtime host count, runtime count, web app count.
App route cards (Chat, Director, Edge, etc.) per Device.
Live route-plan diagnostics with provenance.

This is the closest existing surface to the target admin Device view. The data flows from system.devices.devices.list filtered to the calling principal.

Target admin view

For a platform admin, the table needs to span all principals:

Filter / search by principalId, spaceId, routeKey, hostName, status, createdAt range.
Bulk select for bulk-revoke (target op).
Per-row drill-in to a deep Device page: full Host Link record, runtime list, recent heartbeats, recent revoke events, scopes, NATS user public keys.
Grouping by Runtime Host (per P1.22a topology — a Device can have multiple Runtime Hosts).

Cross-principal listing today

system.devices.devices.list accepts a principalId filter:

bash

matrix invoke system.devices devices.list \
  '{"principalId":"p_xxx","includeOffline":true,"includeRevoked":true}'

Without principalId, the op scopes to the calling identity. To list all Devices on the platform Host:

bash

# From a loopback connection on the platform Host (local-client identity)
matrix invoke system.devices devices.list '{"includeOffline":true}' \
  --home /var/lib/hivecast/host-home

The local-client identity bypasses the per-principal filter. This is the operator path today.

For a non-loopback admin (a remote browser session held by a platform admin principal), the access path is target state — there is no admin: true flag on principals yet (per Authorization).

Schema recap

interface IHostLinkRecord {
  id: string;
  hostId: string;
  hostName?: string;
  deviceSlug: string;
  natsUserPublicKeys?: readonly string[];
  heartbeatTokenHash?: string;
  heartbeatTokenIssuedAt?: string;
  principalId: string;
  spaceId: string;
  routeKey?: string;
  publicNamespace?: string;
  authorityRoot: string;
  scopes: readonly string[];
  status: 'active' | 'revoked';
  createdAt: string;
  updatedAt: string;
  lastRefreshedAt?: string;
  revokedAt?: string;
}

Plus the Device row's runtime / app rollup from system.devices.

What `P1.22` already proved

Per the live progress in P1.22:

The per-principal Device card with route-plan diagnostics is shipped.
system.devices.devices.list exists and returns rows.
Live proof on https://hivecast.ai/apps/web/#dashboard showed the linked Device as Online with 8 runtime hosts and routed app links.
Bus auth and per-actor health probes are separated and surfaced.

The P1.22 closure prerequisites that block a full admin Device view:

Multi-Runtime-Host fixture acceptance.
Selected-target failure-mode UAT.
HiveCast Local Mode structure.
Runtime-control mount checks.

These are scoped to the user dashboard. The admin extension (cross-principal) is downstream.

Per-Device deep view

The target deep-view page would show:

Identity panel: installId, hostId, deviceSlug, hostName, owner principal.
Bond panel: Space, authority root, scopes, status, created/updated timestamps, revoke timestamp if any.
Runtime panel: every runtime registered under the Device, grouped by Runtime Host.
App-route panel: per-app route plans with provenance.
Credentials panel: heartbeat token issued at, NATS user public keys recorded.
Audit panel: recent events touching this Device (target).

Today, you assemble this view from:

auth.hostLink.get for the bond panel.
system.devices.devices.get for identity + status.
system.devices.devices.runtimes.list for runtimes.
The runtime log files for audit.

Bulk operations

Target:

auth.hostLink.bulkRevoke — pass an array of hostLinkIds, atomically revoke and update NATS account JWT once.
auth.hostLink.list-all — admin-only list, paginated.

Today these don't exist. Bulk revoke is a loop of single-revoke calls (each triggers a NATS hub reload — slow under fleet pressure).

Dashboard: Devices ​

What exists for the user ​

Target admin view ​

Cross-principal listing today ​

Schema recap ​

What P1.22 already proved ​

Per-Device deep view ​

Bulk operations ​

See also ​