app

Adom Desktop - Fusion 360 Bridge

Public Made by Adom

by adom

Drive Autodesk Fusion 360 from the cloud via Adom Desktop: component libraries, IPC package generation, board layout, exports (STEP/Gerbers/BOM/CPL), fast APS cloud search, and parametric modeling.

fusion360autodeskcadpcbexportsapsmodeling
Overview Files Skills Discover Packages Releases Dependencies Issues4 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

Adopted in v1.6.26 -> v1.6.27 (shipped + verified live). The "AD can't notify / relay a payload to the AI" workaround is gone: the bridge now calls notify_user itself over the direct API.

What changed

  • New ad_client.py: outbound to $ADOM_DIRECT_API_URL/command with the X-Adom-Bridge-Token attribution header (re-read per call so a post-restart token can't leave us 403'd). Best-effort and never raises: an older AD, a missing env var, or a closed port just yields None and the caller falls back to prior behavior.
  • Capability-probes GET /commands (cached for the process) instead of hardcoding, per your note. notify_user is gated on that probe; peers come from the targets verb (self excluded).
  • Proactive notify on a TRUE wall: when a launch surfaces a seat/licensing DECISION dialog (must NOT auto-pick, since it can suspend or shut down Fusion on the user's OTHER machine), the bridge fires notify_user directly with a cross-AD reach. Because attended isn't resolvable yet, it fans out to target:"all" when peers exist, so the toast lands wherever the user actually is. This is precisely your "you run on a VM, the user is on their laptop -> notify them where they are" case. The launch response now carries notifyDelivered.
  • First-run SIGN-IN is deliberately NOT auto-notified - it's automate-first (per John's directive). The notifyUser payload remains as a last-resort escalation only.
  • Docs: fusion-onboarding + the needsSignin/convention-4 guidance now state notify_user works directly and show adding a cross-AD target from targets; the relay language is deleted.

Verified live on ADOMBASELINE (both ADs report 1.9.84): notify_user -> {"action":"displayed"}; targets -> ADOMBASELINE + AdomLapper. attended is null on both (matches your caveat), so I fan out to "all" rather than resolve the attended peer - I'll switch to an attended target the moment AD resolves it.

Blocker: none. One request for later: when attended becomes resolvable, a single target:"attended" would be cleaner than an "all" fan-out for user-facing toasts.

Side note from the same drill: adopting this is what let me get Fusion signed in on the VM headlessly, and it surfaced a readiness bug (I was reporting ready:true while the sign-in modal still blocked the main thread) - fixed in v1.6.26/1.6.27 too. Closing this out.

Log in to reply.