Configure and switch between multiple Galaxy instances in Orbit (e.g. usegalaxy.org and .eu)

[nekrut]

Motivation

Users work across multiple Galaxy servers — usegalaxy.org, usegalaxy.eu, usegalaxy.org.au, institutional instances — each with its own account/API key, histories, and tool availability. Orbit should let you configure several Galaxy instances and switch the active one, instead of being tied to a single server.

Current state

The data model already supports multiple named profiles — the gap is the UI:

• Config: ~/.loom/config.json → galaxy: { active: string, profiles: Record<name, { url, apiKey | apiKeyEncrypted }> }.
• extensions/loom/profiles.ts manages named profiles (loadProfiles, saveProfile, switchProfile); /connect <name> and /profiles switch/list them from chat.

But the Orbit UI is single-server:

• Welcome screen writes one hardcoded profile: profiles: { default: { url, apiKey } } (app/src/renderer/app.ts ~L899).
• Preferences exposes a single URL + key (prefs-galaxy-url / prefs-galaxy-key, app.ts ~L3032) editing that one default profile, plus a Disconnect button.
• There is no UI to add a second server, see the list, or pick which is active. Power users can hand-edit config.json or use /connect in chat, but that isn't discoverable.

So today, galaxy.profiles almost always has exactly one entry named default.

Proposed

Surface the existing multi-profile model in the Orbit UI:

1. Preferences → Galaxy: a list of servers. Add / edit / remove named Galaxy instances, each with a label, URL, and its own API key (encrypted at rest via safeStorage, like the current single key). Mark one active.
2. A server switcher. Let the user change the active Galaxy instance — ideally from the footer (next to the Galaxy indicator) and/or Preferences. Switching re-points GALAXY_URL / GALAXY_API_KEY, re-registers the Galaxy MCP server, and restarts the brain (the same path /connect already uses via ctx.reload).
3. Presets for common servers (usegalaxy.org, usegalaxy.eu, usegalaxy.org.au) so adding one is one click + paste key.
4. Welcome flow unchanged for first-run (add one to start); additional servers are added later in Preferences.

Considerations

• Per-server binding/history. A notebook's loom-galaxy-page binding and history belong to a specific server — pushing/pulling or opening a history must target the server it was created on, not just the currently-active one. Guard against cross-server mismatch (e.g. a notebook bound to .org while .eu is active). The history-link feature (feat(orbit): Galaxy history link in the Activity tab #240) already builds the URL from the active profile's origin — that needs to become binding-aware here.
• Switching mid-session should behave like /connect (brain restart + MCP re-register), and warn if there's in-flight work bound to the current server.
• Liveness per server — the footer indicator (Galaxy footer indicator reflects only config, not liveness — show amber/red on unreachable/failed calls #362) should reflect the active server's reachability/auth, and ideally show which server is active.
• Keep each profile's key encrypted; only the active profile's URL/key sync to the brain env.

Acceptance criteria

• The Orbit UI can add, edit, and remove multiple Galaxy servers, each with its own URL + API key.
• The user can switch the active Galaxy instance from the UI; the brain + MCP follow the switch.
• The footer/UI shows which Galaxy server is active.
• Notebook Galaxy bindings/histories remain tied to the server they were created on (no cross-server push/open).
• Existing single-default-profile configs migrate/keep working.

Related

• extensions/loom/profiles.ts, /connect + /profiles (existing multi-profile plumbing).
• Galaxy footer indicator reflects only config, not liveness — show amber/red on unreachable/failed calls #362 — footer indicator should reflect the active server's liveness.
• feat(orbit): Galaxy history link in the Activity tab #240 — Galaxy history link (build URL from the bound server, not just the active one).