Skip to main content
The hosted registry is not built yet. There is no live registry host, no ados plugin search, no Browse tab, and no registry REST API today. The two shipping distribution channels are local file install (a signed .adosplug from disk) and URL install (a signed .adosplug fetched over HTTPS). Everything below describes the planned design so plugin authors can build against a stable contract; the commands and endpoints on this page do not work yet.
The planned hosted registry would add discovery on top of local file install and URL install. It is a catalog plus a CDN plus a revocation feed. The trust chain (signed .adosplug, Ed25519, trusted key list) does not change.

What the registry provides

The default registry endpoint would be a host like registry.example.com. Closed deployments can point at their own host; see the self-host section below.

Planned CLI

These commands are part of the registry design and are not implemented today. Installing by id, searching, and update-against-registry land with the registry itself.
Results show plugin id, latest version, author, risk band.

Install by id

Installing without a version pin picks the highest semver matching the agent’s compatibility range.

Show details

Update

update re-runs the permission prompt only if the new version declares additional permissions. Otherwise it applies in place and restarts the plugin.

List installed against the registry

Prints every installed plugin that has a newer version available.

Planned Mission Control Browse tab

In the registry design, Mission Control gets a Browse tab under Settings, Plugins. Cards show icon, name, author with verification badge, install count, short description. Filters mirror the CLI: category, board compatibility (auto-suggested from the connected drone), license, signed-only (on by default), verified-only. The detail page shows the README, screenshots, version history, the permission set, the static-analyzer report, and the Install button. Clicking Install runs the same permission dialog as local file install.

Planned REST surface

Filters on the list endpoint:
The download endpoint redirects to the CDN URL. Clients that prefer to fetch directly can use the redirected URL with their own HTTP client; the archive is always the same signed bytes. revoked.json shape:
The agent polls this endpoint every 24 hours when networking is available and caches the result under /var/cache/ados/revocations/.

Pointing at a self-hosted registry

Edit /etc/ados/config.yaml:
Then restart the supervisor:
You can configure two registries (the default plus your own) for federation. The Browse tab shows results from both, badged with the source.

Offline operation

The agent never blocks on the registry. If the network is down:
  • Local file install keeps working.
  • Already-installed plugins keep running.
  • The cached revocation list is consulted (older entries still enforce until they age out at 30 days).
  • The Browse tab shows the last-cached catalog with a stale banner.
Operators on disconnected networks can run an internal mirror that periodically syncs the catalog and archives over an isolated transfer channel. The mirror serves the same REST surface and signed archives, so clients point at it the same way they would the default registry.

What the registry does not do

  • Run the plugin code.
  • Grant permissions on the operator’s behalf.
  • Override the trust list. A signer the agent does not trust still fails install even if the registry served the archive.
  • Push installs. Every install is operator-initiated.

See also