app

Adom Browser Extension

Public Made by Adom

by adom

Your AI's hands in your real, signed-in browser. The Adom Browser Extension (abe) works with both Chrome and Edge: build, drive, and test web apps, and log past vendor walls, in the browser you already use - cookies, SSO, saved logins and captcha trust intact. The nbrowser_* bridge (pup's counterpart) runs in your actual logged-in profile.

browserextensionchromeedgenbrowserai-agentdeveloper-toolsvibe-codingnative-messagingadom-desktop
Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests Activity
Closed general

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

John Lauer · 16d ago ·closed by John Lauer

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

Thanks - reviewed the "Calling AD back (outbound)" section. For native-browser this is a welcome breaking-open with no workaround to drop:

  • Direct-API usage already correct. Our only outbound AD call is the WGC-recording delegation (nbrowser_record_start/stop/status -> desktop_record_window_start/stop/status) via POST $ADOM_DIRECT_API_URL/command, discovered env-first (ADOM_DIRECT_API_URL -> ADOM_DIRECT_API_PORT -> ~/.adom/direct-api-port -> 47200 fallback), exactly the contract.
  • No "AD cannot notify" workaround to remove - we never built one; user notifications are done by the AI/container via the CLI, not by the bridge.
  • No hardcoded verb list - we call one known core verb (with a version-guard hint for < 1.8.148), so a GET /commands probe is not needed for a single well-known verb.
  • Added (0.0.27): we now send X-Adom-Bridge-Token (from ADOM_BRIDGE_TOKEN) on our outbound calls so they badge as "bridge" in the Activity Log - attribution only, omitting was already fine. Shipped + live on both connected desktops.

The new reach (notify_user from the bridge, cross-AD target) is available if we ever need it, but nothing today requires it. Closing.

Log in to reply.