Registering this installation

An installation asks before it registers. A fresh MeshWeaver installation configured for a plugin registry without a key (the Homebrew default: memex-local registry https://portal.example.com) does not register on first start. It starts, and waits for a platform admin of this installation to accept two texts on its behalf. Only then does it register, obtain its token and read the catalogue.

The tile

Every global admin who signs in gets a This instance tile on their home (the Hosting plugin's InstanceAppTileLogonAction, run on every logon so an admin promoted later gets it too). It opens the Registration tab of the Admin app — /Admin/Settings/Registration (the tile's /{you}/Instance address redirects there, so tiles seeded earlier keep working). Registering the installation is platform administration, so it lives with every other admin surface in the Admin app (Doc/Architecture/AdminApp on the platform). Non-admins who open the URL are refused and see nothing else.

The page shows where the installation would register and as what:

line source
Registry PluginCatalog:RegistryUrl (or the first of PluginCatalog:Registries)
Instance ID PluginCatalog:InstanceId — the id the registration claims; a stable global identity, never derived from a machine name
Awaiting consent no Admin/InstanceConsent record exists yet

Below it, the two texts as published on this installation — the privacy statement (Admin/Privacy, the page served at /privacy; edited under Settings ▸ Privacy) and the platform terms (Admin/Terms, created with generic default terms on first use and editable like any Markdown node) — with one checkbox each and Register this installation. Both boxes must be ticked; with one, the page refuses and writes nothing.

What registering does

  1. The consent is written to Admin/InstanceConsent under your own identity — the record carries the instance id, the registry, a hash of each text exactly as shown, and who accepted when. Writing the Admin partition is what only a global admin may do; that is the gate.
  2. The platform's auto-registration, which was waiting on that record through a live query, wakes: it presents the instance id to the registry without a key (open registration), the registry enrols it into its default plan — free on the public instance — and returns the instance's durable key exactly once. The key is stored encrypted under this installation's master key, together with the plan the registry echoed.
  3. From then on every registry call exchanges that key for a short-lived signed token and presents the token; the key itself leaves the process once per token lifetime.
  4. The default install runs: the packages the installation is granted, at its plan.

The page follows all of it live. It is laid out as a summary card over a package grid:

on the card what it shows
Registry the registry URL, as a link
Instance ID the id the registry issued (or, before registration, the configured one)
Plan the plan the registry echoed, as a badge; set at the registry for an operator-provisioned installation, whose plan the page cannot see
Status Connected once the catalogue read succeeds, Not connected when it fails, Checking… while it runs, Not registered / Registering… before a credential exists
Registered / Consent given by when present
Packages the count, split by tier — one badge per tier (free · 72, pro · 20, …), largest first

Under the card, Packages available to this installation is a DataGrid — package, tier (a badge), category, description, released version — sorted by name, sortable by any text column, 25 per page. It is the list the registry serves, read through the same token exchange, so it is exactly what the Store shows. A package with no tier, category or version shows —, never an empty cell. A pro or enterprise package is not on it unless the plan covers it; the registry serves what the plan covers, and a registry administrator raises the plan on the instance record there.

Withdrawing

Withdraw consent deletes the record. The installation stops registering. It does not delete the stored credential — an already-registered installation keeps authenticating until a platform admin deletes Admin/PluginRegistryCredential/{registry-host}; that is the louder step, kept separate on purpose.

Installations provisioned with a key

An installation whose operator provisioned it with a registration key (PluginCatalog:BootstrapKey, minted on the registry for a plan) is not gated: its operator accepted the terms on the fleet's side, and an unattended pod asked the same question would stay unregistered forever. The page says so and shows the status only.

Where the pieces live