Onboarding and the Store

Onboarding installs the Store and opens it

A fresh Iro has no apps — not even the Store. The planned onboarding (Iro UI, not an app) suggests our catalog, which you can replace or skip. It installs the Store through the ordinary download, checks and consent sheet, and opens it. Fewer Iro screens; the Store owns the first-run app list.

The Store’s first run

Starter apps up front, everything else behind search. Each install is an iro.install.request with { url, sha256, catalog? }: Iro downloads and checks it like a link, shows its sheet naming the store that asked, and the store hears only installed or cancelled. One request per app at a time; jobs can’t ask.

Apps that need another app

A catalog entry names the providers of the contracts the app uses. The install sheet names a contract no installed app provides yet (Daily Briefing: tasks@1 from GitHub). The app installs anyway and gets NotBound until the provider is there. After installed, the Store offers each provider as its own request with its own sheet.

Revoking a published package

A signed catalog may list revoked: [{ id, versions, reason }]. Iro reads the install’s source catalog with its update checks. A revoked version is disabled — service stopped, views closed, jobs off — its data kept, the app’s page saying why and offering an update if there is one. A catalog can turn off only versions installed from that catalog; every catalog has the same scope. Revoking only turns off, never installs or changes anything.