Build & ship · Developer tools
Package manager
Discovery, install, approval gates and dependency resolution for your packages, distributed peer-to-peer instead of through a central app store.
What it is
The package manager is the infrastructure behind installing code written by other people. Search comes from the local graph and connected peers rather than one central index. Every install goes through an explicit approval gate, dependencies resolve automatically with a lock file recorded as events in the shared history, and the underlying transfer runs over a peer-to-peer connection rather than a download server.
What a person notices
The packages view shows what is available, searchable by name, scope, tags and description, and filterable by category or trust tier. Results come from repositories the person's own Hives have published to.
The package detail view lays out what a package does, its dependencies, version history and security posture before anyone installs anything.
Installing is deliberate: an approval dialog shows exactly which capabilities the package is asking for, and the person can reject anything asking for more than it needs.
Installed packages sit in their own management view, where the person can suspend, resume, or revoke any of them at any time.
What you get as a developer
Publishing and shipping updates both move through the same manager, using the manifest your package already declares.
Discovery
People find your package by searching the graph and connected peers. What they see comes from the Hive repositories your package has actually been published to.
Install request and approval
An install request creates a pending record. The person approves or denies it explicitly; nothing installs silently. A separate gate checks that the Hive owner countersigned the artifact, and a hive-context install also runs a steward-quorum check.
Dependency resolution
Dependencies resolve automatically, and the resolved set is recorded as lock-file events in the shared history, so an install can be reproduced exactly later.
Updates
Update mode is per package: auto, notify, or manual, with auto the default. A stored preference applies whenever an update request does not say which mode to use.
Publishing a release
Publishing tags a version for distribution. Every publish runs through a pre-publish check that blocks on critical findings before the release goes out.
Requesting an install, in the wire format your package's tooling actually sends
These are the real WebSocket message shapes documented for NAOMS's package manager. The field names and message types are exact.
// Search for a package.
{ "type": "pkg.search", "query": "calendar" }
// Ask to install a specific version. This creates a pending record;
// nothing runs until it is approved.
{ "type": "pkg.install_request", "packageId": "chain-uuid", "version": "1.2.0" }
// The owner approves the pending install.
{ "type": "pkg.approval_granted", "packageId": "chain-uuid", "version": "1.2.0" }
How it relates to other steps
Package
The manifest your package declares when you build it is what the install approval dialog reads from, to show a person exactly what your package is asking for.
Distribute
Publishing and release both live in the package manager; distribution to a Hive or a hub is the next step after a release is tagged.
Marketplace & hubs
A hub is a place people search for packages that have gone through this same discovery, approval and release path, with its own extra validation on top.