silicon-apps-client
The primary Rust interface for Silicon Apps. The HTTP client holds only an explicit URL and optional bearer token; it does not load environment variables, persist sessions or initialize local state. The CLI calls this package for every service operation, authentication, installation and update.
use Client;
# async
create, edit, action, upload, upload_signed, withdraw_release, resolve, report, register_platform and the typed package/release models cover author and store operations. capabilities, events, stream_events and the subscription methods follow events; author_keys, add_author_key, revoke_author_key and signing_keys manage keys. Service errors are ApiError values with status, code, message, hint and details. request exposes the documented user-facing HTTP contract for additional filters and optional fields. Mutations accept caller-supplied idempotency keys; otherwise a new UUID identifies the operation. Reuse your key when retrying after an unknown network outcome.
Authentication uses the official silicon-accounts-client. Device or Silicon sign-in obtains a first-party token, requests a single-use Apps token, and exchanges it through the Apps backend. Only the backend holds the app secret. auth::authenticated_client takes a LocalState explicitly and serializes rotating refresh-token use across processes. Saved sessions bind access and refresh tokens to the complete Apps and Accounts service URLs, including any tenant path; changing either URL requires a fresh login before tokens can be sent. Session files have owner-only Unix permissions and are written atomically. APPS_TOKEN is interpreted by the CLI, not by the HTTP client.
use ;
# async
Install checks the selected app/channel/target and SHA-256 digest, then the service's Ed25519 signature over the release manifest (and the author's signature when the package has one) with signing::verify_package, before it extracts a bounded archive. Keys are trusted per service in the LocalState: the official service's key is pinned in signing::PINNED_KEYS, newer keys are trusted when a trusted key endorses them, and other services are trusted on first use. A failed check is a signing::VerificationError with a stable code such as signature_mismatch. It then checks command ownership, and uses staging plus backup directories to restore a prior installation on errors. Bundled scripts run automatically during installs and updates and have a timeout. Filesystem rollback cannot undo a script's unrelated external side effects. Successful installation counts use a durable idempotent outbox when the service is temporarily unavailable.
Every installed record also binds the app to its registry URL. Updating against another registry is refused; explicitly reinstalling with confirmation is required to change the source. Sessions saved by 0.1.0 require a new login, and installed records without a saved source require an explicit reinstall with --yes before automatic updates resume.
updater::run takes explicit state and checks installed channels each minute, including apps. updater::service_definition produces launchd, systemd or Windows Task Scheduler configuration; install_service activates it when requested. Windows startup resolves the stable installed command and runs a separate executable copy so installed app executables can be replaced. A successful Apps update hands off to the latest executable, and the next startup also picks up that version. Unix updaters reload with the same process ID so their launchd/systemd supervisor continues managing the current code. Interactive Windows self-installs return a scheduled receipt and continue through a helper, with the final result in self-update.log.
Telemetry is configurable and default-on. The optional APPS_TELEMETRY_TABLE_KEY (legacy alias APPS_TELEMETRY_KEY) routes source/step/progress/context events to Space Station; no events are emitted when disabled or when the deployment key is absent. Signed-in platform registration supplies aggregate target population independently of diagnostic telemetry.
The package intentionally has no endpoints for isolated-runner verdict submission, account migration or other service-internal administration.
The instructive guides and informative rationale are available without filesystem or network access through docs::guide(topic), and the CLI renders the same text with silicon-apps docs TOPIC. The CLI also offers silicon-apps docs tree for every subcommand and flag.