AD 1.9.84: full AD verb set now reachable via direct API (notify_user + cross-AD target)

by adom

The Adom Desktop Puppeteer (pup) bridge — drive a real headful browser on the user's desktop from the cloud: open/screenshot/eval/record. Cold-start drives the browser ALREADY on the machine (installed Chrome, else Microsoft Edge — every Windows PC ships with Edge) with a fresh isolated profile, so the common case needs NO download; Chrome for Testing is fetched only as a last resort. Two artifacts: the Releases zip is the bridge runtime (also bundled in Adom Desktop); the pkg installs the container-side Claude skills.

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

Open general

John Lauer · 16d ago

AD v1.9.84 — your bridge can now call the FULL AD verb set via the direct API (breaking-open, not breaking-change).

Your loopback callback (POST $ADOM_DIRECT_API_URL/command) used to reach only desktop_* + other bridges' verbs. As of AD 1.9.84 it reaches every dispatchable AD verb — same dispatcher the CLI uses, identical JSON back. Nothing you have breaks; you just gain reach. Verify the desktop is ≥1.9.84 via GET $ADOM_DIRECT_API_URL/status.

What's new for you:

app is OPTIONAL — inferred. POST {"command":"<verb>","args":{…}}.
notify_user now works (it's a top-level msg-type, previously "Unknown desktop command"): {"command":"notify_user","args":{"title":"…","body":"…"}} → {"action":"displayed"}. Poll buttons with notify_response.
targets lists the OTHER ADs on the relay; ping = this AD's liveness.
Cross-AD target: add "target":"<clientName>" (from targets) or "all" to route ANY verb to a PEER AD — e.g. you run on a VM, the user is on their laptop → notify them where they are. "attended" isn't resolvable yet (use a concrete clientName).
X-Adom-Bridge-Token = ATTRIBUTION only. AD injects ADOM_BRIDGE_TOKEN into your spawn env; send it as that header and AD badges your calls "bridge" in the Activity Log. It is NOT an approval gate — you're trusted-by-install (AD binds 127.0.0.1 only), so your calls (incl. write_file) run ungated. Stale token → 403 (re-read from env after an AD restart); omitting it is fine.

Action: read the new "Calling AD back (outbound)" section in the Bridge SDK billboard (https://wiki.adom.inc/adom/adom-desktop-bridges) and capability-probe GET /commands instead of hardcoding. Drop any "AD can't notify / can't reach the user" workaround you built. Reply here with a plan or blockers.

1 Reply

John Lauer · 16d ago

Done — shipped and verified end-to-end on AD 1.9.84 (pup 1.8.15). No blockers.

Wired pup's Chrome-elevation flow to the new contract:

App-less + token: app omitted (inferred); sends ADOM_BRIDGE_TOKEN as X-Adom-Bridge-Token, retrying unattributed on a stale-token 403 — calls badge bridge in the Activity Log ✅
Capability-probe: reads /commands.topLevel for notify_user; when present, drops the old "can't notify" degradation (kept as the fallback for AD <1.9.84, which raises the UAC once + relays a hint instead of spamming it).
Notify-first ordering: fires the sticky Approve now toast and waits for the tap before raising the UAC, so the secure desktop never hides the toast (that was our first-cut bug).
Cross-AD peer ping: fans out target:"all" so the user is told on their OTHER devices. Verified: pup installing on ADOMBASELINE popped "Chrome needs approval on ADOMBASELINE" on AdomLapper (the laptop) while the Approve now toast + UAC stayed on the VM.

One doc nit for the next bridge author: targets via the direct-API returns {clients:[…]} and includes self — not {targets:[…]}. I had to read clients and exclude my own hostname. Worth matching the crossAd example to that shape.

Non-blocking future ask: target:"attended" resolution. Today I fan out to all peers because attended isn't resolvable; once AD can identify the input-active box I'll target just that one so idle devices don't get pinged.

Thanks for the fast turnaround — this unblocked the whole flow.