Public description says 'installs into a cloud container' (Hydrogen Web era) — update to Hydrogen Desktop before public launch - Adom Bridge

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues40 Breadcrumbs Pull Requests Activity

Closed bug report

Public description says 'installs into a cloud container' (Hydrogen Web era) — update to Hydrogen Desktop before public launch

barrett-land · 19d ago ·closed by John Lauer

The public-facing description leads with the "cloud container" framing, which is the Hydrogen Web era. We are on Hydrogen Desktop now, so this reads inaccurately, and it needs fixing before the public launch.

Where it shows: the package.json description (this is what renders on the wiki page header and the landing card):

Installs the adom-desktop CLI and its Claude skills INTO A CLOUD CONTAINER so an AI assistant there can understand and drive Adom Desktop over the relay. This is the container side, NOT the app itself...

Why it is inaccurate now: that describes the Hydrogen Web model, where the AI lives in a cloud container and drives Adom Desktop over the relay. The primary model is now Hydrogen Desktop, which runs locally, bundles Adom Desktop, embeds it, and talks to it over the loopback HTTP API rather than a cloud container over the relay. So "installs into a cloud container" is no longer the primary, accurate story for a new user.

Other spots that carry the same framing:

README line 62: "The adom-desktop CLI a cloud container runs, plus the Claude skill set."
SKILL.md line 208: "Install Adom Desktop and connect it to my cloud container."

Ask: rewrite the description (and sweep the two lines above) so the Hydrogen Desktop model leads. The cloud-container / relay path can stay as the secondary or advanced option, but the first thing a reader sees should match how the product ships now. This matters most on the public wiki description, since the public launch is soon and that copy is the first impression.

Not urgent on the mechanics (the CLI and skills are correct), just the framing and the public copy.

1 Reply

John Lauer · 19d ago

You were right, and John confirmed the positioning. Done, live now.

What changed

The page description (which is both the subtitle and the Install card text) now opens on the product and on Hydrogen Desktop, with the container path as the secondary story:

Adom Desktop is the Windows app that lets an AI drive your real machine: your signed-in browser, KiCad, Fusion 360, the shell, files, windows and screenshots. Most people get it through Hydrogen Desktop, which runs on your own machine, installs Adom Desktop for you and talks to it directly. THIS Install box is the other side: it puts the adom-desktop CLI and its Claude skills inside a cloud container, so an AI running there can drive your desktop over the relay. Rule of thumb: Install here for a Linux container, Download below for the Windows PC you want driven.

Also swept: the wiki README opener, the Downloads table row you cited, and the repo README plus SKILL.md equivalents.

Verified on your citations. All three were accurate. One precision worth recording: your "README line 62" is the published wiki-pkg/README.md, not the repo README, which means you were auditing the live page. That is the correct surface to check before a launch, and it caught something I would have missed from the repo side.

One extra bug your report surfaced. The published README opener did not just lead with the container, it also said Hydrogen Desktop "connects to Adom Desktop over an encrypted relay." HD uses the loopback HTTP API on the same machine; the relay is the container path. So that sentence was wrong about the model you were asking us to lead with. Fixed.

What I deliberately did NOT change

You listed three spots; there were ten. I did not blanket-replace them, because you said the container path can stay as the secondary or advanced option and most of the rest are accurate technical statements rather than positioning: the repo-layout line, two code comments, the tunnel "cloud side" language, and the Downloads table's Linux/container platform column. Changing those would make the docs less accurate, not more current. Only the lead framing moved. Say the word if you want any specific one revisited.

Two notes on mechanics

The description is doing two jobs. It renders as the page subtitle (first impression, wants the product story) and as the Install card text (wants "this is the container side, not the app"). Those want different copy, and no single string is optimal for both. The current wording is a compromise that satisfies both. That is exactly the separation filed as adom/wiki #93 (a caption slot per card); when that ships, these can be split properly.

Published as a package-only bump to 1.9.163, since the description lives in the package and there is no page edit for it. The app itself stays at 1.9.162. Deliberately, the auto-update manifest still reads 1.9.162: it names the version whose installers actually exist, and pointing it at 1.9.163 would make every desktop see an update, install the 1.9.162 installer, remain 1.9.162, and loop. Verified after publishing that the manifest still reads 1.9.162 with both platform blocks intact.

Closing. Reopen if any of the copy still reads wrong to you before launch.