A typed pub/sub/RPC substrate where any feed, service, or component is the same primitive — published, discovered, instantiated, and metered the same way across local Hosts, hosted Hosts, and existing language ecosystems.
This portal exists because the substrate is a lot of moving parts — protocol, runtime, registry, security, and on top of that the apps and the cloud platform — and a single starting point matters more than any individual page. Read this first to figure out which docs package answers your question, then jump straight there. The portal does not try to teach the whole system on one page; it routes you to the package whose docs are written for what you are actually trying to do, whether that is installing HiveCast, publishing a package, hardening a deployment, or wiring up an agent. The known-gaps register linked below captures real implementation gaps and target-state items, so you can tell what is shipped today from what is planned.
Matrix is docker-for-actors / npm-for-actors. Same shape as Docker and npm, mapped onto an actor system instead of OS containers:
| Concept | Docker / npm world | Matrix substrate |
|---|---|---|
| The thing you publish | Image / npm package | Package (@open-matrix/<x>) |
| The registry | Docker Hub / npm / Gitea | Gitea or HiveCast-hosted package registry |
| The thing that runs | Container | DeploymentInstance (a copy of a package) |
| The runtime that runs them | Docker engine / Node | Matrix runtime (a Node process; multi-package) |
| The host that runs runtimes | Linux box / VM | A Matrix Host (the user's machine) |
| The orchestration | Compose / Kubernetes | Host Service + future composer |
| Inter-container comms | TCP/IP, sockets | NATS subjects, typed bus messages |
| Isolation declaration | seccomp, namespaces | matrix.json runtime.isolation field |
Container name (--name) | docker run --name foo | matrix deploy --instance-name foo |
Underneath the analogy, the substrate is a typed pub/sub/RPC fabric with a registry, a capability catalog, identity, federation, and metering, runnable across multiple execution tiers. Three primitive types of actor — Feed, Service, Component — cover everything you can publish: a stream, a request/reply endpoint, or a UI-bearing actor. All three are typed (declared accepts / emits / streams), all three live at a Space-rooted bus address, all three are discoverable, instantiable on demand, metered, and revocable.
HiveCast is the first big provider on top of this substrate. Personal AI runtime, inference market, compositional UIs, and (post-launch) third-party Matrix-enabled web pages are verticals built on top. The substrate is the business; the verticals are the proof.
Read first: The product thesis — the consolidated docker-for-actors framing, the three execution tiers, the three discovery surfaces, the five distribution wedges, and the v0 -> v3 roadmap.
hivecast install puts on a laptop or VPS.system.com, system.win32 (already on master at commit 937ad7d5), and future system.npm, system.pypi, system.openapi, system.dotnet. Each connector unlocks a whole ecosystem in one package.| Question | Surface | Example |
|---|---|---|
| "What can do X?" | Catalog | system.catalog ranks candidates by capability, stats, trust, cost, locality |
| "What is in registry X?" | Browse | Browse the Gitea registry directly |
| "What is currently live?" | Live | system.runtimes, system.devices, system.registry |
The three surfaces overlap but answer different questions. The substrate is honest about which is which.
The HiveCast and Matrix documentation portal is organized by product. Each product/domain has its own independent docs package — @open-matrix/docs-<product> — that builds, deploys, and versions on its own. The portal you are reading right now is the cross-package landing page.
Substrate-side docs (the typed-actor fabric and supporting infrastructure):
Vertical-side docs (products built on top of the substrate):
Every page in this portal follows three rules:
<file>:<line> references in frontmatter under sourceCode.> **Status: target state — ships in v0.5/v1/etc.** callout and a pointer to the workstream that owns delivering it.When a documentation page diverges from code, the page is wrong, not the code. Cross-references back to source make that easy to verify.
Every page is pure CommonMark + GFM — no :::tip admonitions, no MDX components, no Vue or React inline components, no framework-specific markdown extensions. Source markdown imports cleanly into VitePress, Astro Starlight, Docusaurus, or any other CommonMark-aware static site generator.
Full rules at WORKSTREAMS/product-consolidation-and-documentation/PORTABILITY-RULES.md.
Sub-agents authoring this portal read the actual source for each package and surfaced a register of real gaps (missing implementation), intentional designs that are easy to misread, and documentation hygiene drift. Read Known gaps and quirks before assuming any framework behavior — it covers the silent $prompt seal, asset-relay caps, the Caddy /nats-ws bypass, and others.
The original VitePress docs at /apps/docs/ (architecture, operations, security, workstreams) are still served while content migration into the new domain-organized portal is in progress.