.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.Search
Install by id
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
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
revoked.json shape:
/var/cache/ados/revocations/.
Pointing at a self-hosted registry
Edit/etc/ados/config.yaml:
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.
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.