Hub: wire the `inactive` (deployed-but-greyed) app state end-to-end #132

New issue

Open

opened 2026-06-20 07:28:33 +00:00 by padreug · 0 comments

padreug commented

2026-06-20 07:28:33 +00:00

Owner

Follow-up to #130. The hub resolver already supports an inactive availability state (provisioned but switched off → rendered greyed and inert), but there's no way for an operator to specify it on deploy — today an app is binary: enabled (shown) or not (hidden). This issue wires the greyed-out state end-to-end.

Background

PR #130 introduced the availability model in src/pages/Hub.vue:

state	meaning	render
`available`	provisioned + reachable	link
`auth-locked`	provisioned, needs login, logged out	greyed, prompts login
`inactive`	provisioned but switched off (`active:false`)	greyed, inert
`unavailable`	not provisioned	hidden

inactive is driven by an optional active field on the in-code catalog (Module.active), but nothing sets it — it's a frontend seam with no input.

Current deploy mechanism

Availability is set in NixOS via services.webapp-standalones.<app>.enable (server-deploy/modules/services/standalones.nix). For each enabled app the module derives hub<App>Url → baked into the build as VITE_HUB_<APP>_URL. The hub shows a tile iff that env var is set. So enable does double duty: build+serve the standalone and light up the hub tile. There is no "deployed but greyed on the hub" option.

Proposed wiring

Frontend (this repo):

Read a per-app active flag from env, e.g. VITE_HUB_<APP>_ACTIVE (default true / absent ⇒ active).
In availabilityOf(), return inactive when the app is provisioned (URL present) but its active flag is false, ahead of the auth check.
Source the catalog's active from that env rather than a hardcoded field (the field stays as the in-code default/override).
Decide the inactive UX: greyed + cursor-not-allowed (current), plus optionally a small "Coming soon" / "Unavailable" sub-label or tooltip in place of the maturity badge.

Deploy (aiolabs/server-deploy):

Add services.webapp-standalones.<app>.active (bool, default true).
Emit the corresponding VITE_HUB_<APP>_ACTIVE into the webapp build env alongside hub<App>Url.
Keep enable as build+serve; active=false means "served + shown on hub, but greyed/inert" — i.e. the app is reachable directly but presented as not-yet-available on the hub. (Confirm this is the intended semantics vs. "shown but link-dead".)

Open questions

Naming: active vs enabled/visible/coming_soon. active matches the frontend field already in place.
Should inactive tiles be completely inert, or still navigable for logged-in admins? (Probably inert for everyone; admins use the direct URL.)
Longer term this whole catalog (URLs + active flags) is a candidate to move from build-time env to a runtime feed (LNbits /hub/apps or a NIP-78 event) for live toggling without a rebuild — see the registry-as-data note in #130. This issue is the env-var stopgap; the runtime source is a separate, larger piece.

Scope

Small, additive. No behavior change until an app sets active=false. Cross-repo: webapp resolver + server-deploy option.

Related: #129, #130.

Follow-up to #130. The hub resolver already supports an `inactive` availability state (provisioned but switched off → rendered greyed and inert), but there's **no way for an operator to specify it on deploy** — today an app is binary: enabled (shown) or not (hidden). This issue wires the greyed-out state end-to-end. ## Background PR #130 introduced the availability model in `src/pages/Hub.vue`: | state | meaning | render | |---|---|---| | `available` | provisioned + reachable | link | | `auth-locked` | provisioned, needs login, logged out | greyed, prompts login | | `inactive` | provisioned but switched off (`active:false`) | greyed, inert | | `unavailable` | not provisioned | hidden | `inactive` is driven by an optional `active` field on the in-code catalog (`Module.active`), but nothing sets it — it's a frontend seam with no input. ## Current deploy mechanism Availability is set in NixOS via `services.webapp-standalones.<app>.enable` (`server-deploy/modules/services/standalones.nix`). For each enabled app the module derives `hub<App>Url` → baked into the build as `VITE_HUB_<APP>_URL`. The hub shows a tile iff that env var is set. So `enable` does double duty: build+serve the standalone *and* light up the hub tile. There is no "deployed but greyed on the hub" option. ## Proposed wiring **Frontend (this repo):** 1. Read a per-app active flag from env, e.g. `VITE_HUB_<APP>_ACTIVE` (default true / absent ⇒ active). 2. In `availabilityOf()`, return `inactive` when the app is provisioned (URL present) but its active flag is `false`, ahead of the auth check. 3. Source the catalog's `active` from that env rather than a hardcoded field (the field stays as the in-code default/override). 4. Decide the `inactive` UX: greyed + `cursor-not-allowed` (current), plus optionally a small "Coming soon" / "Unavailable" sub-label or tooltip in place of the maturity badge. **Deploy (`aiolabs/server-deploy`):** 1. Add `services.webapp-standalones.<app>.active` (bool, default true). 2. Emit the corresponding `VITE_HUB_<APP>_ACTIVE` into the webapp build env alongside `hub<App>Url`. 3. Keep `enable` as build+serve; `active=false` means "served + shown on hub, but greyed/inert" — i.e. the app is reachable directly but presented as not-yet-available on the hub. (Confirm this is the intended semantics vs. "shown but link-dead".) ## Open questions - Naming: `active` vs `enabled`/`visible`/`coming_soon`. `active` matches the frontend field already in place. - Should `inactive` tiles be completely inert, or still navigable for logged-in admins? (Probably inert for everyone; admins use the direct URL.) - Longer term this whole catalog (URLs + active flags) is a candidate to move from build-time env to a **runtime feed** (LNbits `/hub/apps` or a NIP-78 event) for live toggling without a rebuild — see the registry-as-data note in #130. This issue is the env-var stopgap; the runtime source is a separate, larger piece. ## Scope Small, additive. No behavior change until an app sets `active=false`. Cross-repo: webapp resolver + server-deploy option. Related: #129, #130.

padreug added the

app:webapp

enhancement

labels

2026-06-20 07:28:39 +00:00