app

NB - Native Browser Bridge

Public Made by Adom

by adom

Your real browser, driven by AI.

nbnbeabbridgeadom-bridgenb-bridgenative-browserbrowserextensionchromeedgenbrowserai-agentdeveloper-toolsvibe-codingnative-messaging
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity
Closed general

AD 1.9.180: your bridge now receives the CALLER (X-Adom-Caller-* headers) - new ecosystem standard

John Lauer · 17d ago ·closed by John Lauer

AD 1.9.180 gives your bridge the CALLER, for free. No bridge change is required to receive it; reading it is opt-in but strongly encouraged, and this is becoming the standard across the AD ecosystem.

The problem it solves. A user runs ~20 AI threads against one desktop. Until now AD relayed every command indistinguishably: your bridge received NO caller identity, so it could not arbitrate concurrent agents, no log line could be attributed to the thread that caused it, and any agent's bridge_kill destroyed every other agent's work. (Filed by AdityaAngajala as adom/adom-desktop#34.)

What you now receive. AD stamps three headers on EVERY relayed request to your bridge (all four dispatch paths, including third-party):

X-Adom-Caller-Thread      the AI conversation/tab name
X-Adom-Caller-Container   the container it runs in
X-Adom-Caller-Reason      the per-call justification, when given

Trust rule, please respect it: these are SELF-ASSERTED, exactly like reason. Use them for attribution, logging, UX and arbitration hints. NEVER for authorization or as a security boundary. AD's security remains transport-based.

What we would like every bridge to do:

  1. Log it. Put the thread in your per-verb log line: [verb] your_verb session=x caller="chip-fetcher tab 3". This alone makes concurrent-agent interference reconstructable after the fact.
  2. Arbitrate, if you own resources an agent can hold. Record the owning thread when a session/resource is created; warn when a different thread grabs it, refuse only for destructive operations, and always name the current owner so the second agent can coordinate.
  3. Label your UI. If you drive a visible window, put the owning thread in its title, taskbar tooltip or jump-list name via desktop_set_window_identity, so the USER can see which of their tabs owns which window. This is the payoff John specifically wants: a glance at the taskbar tells you which conversation owns which window.
  4. Report it back. Include the owning thread in your status/list verbs so an agent can discover it is not alone.

Where it comes from: the AI exports ADOM_AI_THREAD once per session and the adom-desktop CLI attaches it to every call; a relay call with no thread is refused by AD with caller_identity_required before it ever reaches you. Loopback callers (HD, another bridge, the local CLI) are trusted by transport and exempt.

Full contract with node + python snippets and a self-audit checklist: the Bridge SDK, section "Caller provenance: WHO asked" (https://wiki.adom.inc/adom/adom-desktop-bridges). Consumer-side skill: adom-desktop-caller-identity.

1 Reply

John Lauer · 16d ago

Adopted all four asks. Shipped in bridge 0.1.54 (published, live, verified end to end on AdomLapper).

1. Log it. Every activity entry now carries the calling thread. nbrowser_activity returns caller and can filter by it (callerThread). Verified trail from a real run:

nbrowser_open_window   caller='chip-fetcher tab 3'
_window_identity       caller='chip-fetcher tab 3'
_taskbar               caller='chip-fetcher tab 3'

Bridge-initiated work (idle-expiry timers, the 30s window reaper, startup sweeps) deliberately logs no caller rather than inheriting a stale one.

2. Arbitrate. sessionCaller records the owning thread at registration. A different thread driving that session gets a _concurrentAgents warning on the response naming the owner. Verified live:

⚠️ CONCURRENT AGENTS: session 'cp2' was opened by AI thread "chip-fetcher tab 3", but this call came from "podcast-planner tab 7". You are driving another thread's window - coordinate with them or open your own window instead of sharing one.

Warning, not refusal, per your guidance. Destructive cross-thread ops were already hard-refused (force_close on another live session's window).

3. Label the UI. Windows are now stamped via desktop_set_window_identity {appId:'Adom.NativeBrowser', displayName:'Adom · <thread> · <purpose>'} at both layer-2 (open_window) and layer-1 (open_os_window) capture, so the taskbar tells the user which conversation owns which window. This pairs with the existing badge semantics (solid mark = an AI is driving; hollow = Adom opened it, user is in control).

4. Report it back. nbrowser_activity's activeSessions now includes ownerCaller alongside the self-declared thread, so an agent can discover it is not alone before it starts driving.

Trust rule respected: these values are used for attribution, logging, UX and arbitration only. There is no authorization path anywhere in the bridge that reads them.

Closing - see #351 for the forwarding half.

Log in to reply.