Adom Hydrogen (macOS)
Public Made by Adomby adom
The full Adom Hydrogen workspace as a native macOS app (Apple Silicon) — AI-driven electronics design, running locally.
Send the fleet install_id, signin and setup_complete pings so Mac installs count as running on time
Kyle, this is the smallest change that lets the sign-up reports count Mac installs correctly and on time. The full per-step setup telemetry is still #5; this issue is only the pings that prove "this person got Hydrogen running".
What happens today
The Mac app pings the fleet only after an update check, every few hours. Of the 67 Macs reporting, 55 are signed in, but none carry an install_id or a code_server version, and none have ever sent an event. So:
- Success posts land hours late. The User Signups posts say things like "signed in 3h 57m after creating their account" when that figure is only when the first update-check ping arrived. We cannot tell whether they were up in five minutes or five hours.
- A Mac that hasn't reached its first update check is invisible. It counts as "unknown", the same as someone who never downloaded at all. About half of each day's new accounts end up in that bucket, and most are probably Macs.
- Signed in is the only proof we have. On Windows, success means setup actually finished (
setup_complete) or a running workspace reported its editor version (code_server). On Mac we accept any signed-in ping because nothing better exists.
What to send
Use the same endpoint and contract as Hydrogen for Windows, which has run this since 1.0.512. The Windows code is hydrogen-control-core/src/telemetry.rs, and the field list is the adom/service-fleet README, "The ping body".
1. Where. POST <fleet_url>ping with a JSON body. Read fleet_url from the public manifest, the same version.json the updater reads, and cache it. Never compile the address into the app. If the lookup fails, drop the ping: silence is correct, and a second source of truth is not.
2. How. Fire and forget: a 5 s timeout and no retries, so a dead fleet can never slow an install down. Send through one serial queue so events arrive in the order they happened.
3. Every ping carries:
| field | value |
|---|---|
product |
"hydrogen" |
version |
the app version |
tier |
"insiders" or "public" |
machine |
the computer name |
os |
"macos" |
install_id |
a random UUID made on this install's first launch, stored on disk, and sent on EVERY ping, update checks included. This is what joins a person's pings before they sign in. |
user_id, username |
only while someone is signed in, from the login cache |
Nothing else personal: never an email, a token, a path or a command line. Every value is a string of 120 characters or fewer.
4. Events. Add event to these pings. A ping with no event is an update check, exactly as today.
| event | when | extra fields |
|---|---|---|
first_launch |
once, the first time this install starts, before setup | none |
signin |
the moment a user signs in, not at the next update check | none |
setup_complete |
once, when first-run setup finishes and the workspace is up | ms (setup wall time in ms) |
5. Update-check pings also carry code_server, the editor version, whenever the workspace is running. Only a running workspace can report it, which makes it the same proof of success Windows uses.
6. Testing. Add "test": true to a ping and the fleet validates and answers it but never stores it. Use that while developing.
What changes on our side
Once a Mac build sends setup_complete and install_id, I'll switch the fleet's Mac rule to match Windows: setup_complete from any install, or an update check with code_server set. Kel will then post a Mac success within minutes of it happening, with the setup time, instead of hours later. Please comment here with the first version that sends these, and I'll make the fleet change and confirm the first real Mac post.
1 Reply
Log in to reply.