Fleet ping reports the Native Browser bridge as product 'adom' when it follows the public manifest (slug taken from an owner-qualified manifest URL)

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

Seen on the fleet dashboard since the 2.1.6 ping shipped: five desktops report a product named adom at version 0.5.1, public tier, next to their real bridge rows. 0.5.1 is the Native Browser bridge's public version, and its public manifest URL is the one bridge manifest that carries an owner segment (/api/pages/adom/nb-bridge/files/native-browser-bridge-manifest.json, no /v1/), so the slug derivation takes adom as the page slug instead of nb-bridge. Desktops that follow nb's early-tier manifest (.../pages/insiders/files/nb-bridge/version.json) report nb-bridge correctly, which is why the same bridge shows up under two names depending on tier.

Ask: derive the product slug from the page, not from the URL's first path segment after pages/: skip an owner segment when the path has pages/<owner>/<slug>/files/, or better, take it from the bridge's own name to slug mapping (native-browser is nb-bridge) so a manifest URL shape change never renames a product. Until it ships the dashboard folds adom into nb-bridge with an alias, so nothing is lost; the fix removes the alias.

2 Replies

John Lauer · 2mo ago

Fixed, shipping in ab 2.1.9 (insiders, going out shortly). Root cause exactly as you diagnosed: the slug derivation took the first path segment after pages/, and nb's public manifest is the one owner-qualified bridge manifest (/api/pages/adom/nb-bridge/files/...), so the owner (adom) was reported as the product. The derivation now anchors on the files segment: the segment BEFORE it is the page slug, and on the shared insiders page the product is the folder AFTER files — so both of nb's manifest forms report nb-bridge. Unit-tested with your exact URL. The dashboard alias can come off once the insiders fleet is on 2.1.9 (next 4h polls after it publishes).

On "take it from the bridge's own name-to-slug mapping": ab deliberately has no such table (ab stays generic; a name→slug map would be per-bridge knowledge baked into ab core). The page in the manifest URL ab actually resolved against IS the bridge's product identity, and anchoring on files makes the derivation robust to both URL shapes.

John Lauer · 2mo ago

Fix confirmed shipped (2.1.9) and the relay-connected fleet is on 2.1.13+, so every ping now derives the product from the page slug anchored on the files segment - nb reports nb-bridge on both manifest forms (unit-tested with your exact URL). The dashboard alias can come off. Closing.

John Lauer closed this · 2mo ago