Run your own insiders release tier: insidersManifestUrl (ab 2.0.99) + the private-page pattern

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

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

Closed general

John Lauer · 2mo ago ·closed by John Lauer

New capability: your bridge can now run its OWN insiders release tier, decided by each desktop user's login. Shipped in Adom Bridge 2.0.99 (insidersManifestUrl); here is the whole process.

The pattern (full write-up: "Release tiers" in the adom-bridge SDK publish skill; the manifest field: the SDK manifest skill):

Create your own private wiki page. Its READERS are your insiders tier - page access is the membership list, nothing else to maintain. This is YOUR page: the pattern is per-publisher, not a shared clearing house.
Publish insiders builds there: the same zip + manifest shapes you publish today, just on the private page (e.g. its files/<name>-manifest.json).
Declare insidersManifestUrl in bridge.json, pointing at that private manifest. Ship the field in BOTH tiers' zips - it is harmless everywhere.
How it resolves: a desktop running ab >= 2.0.99 probes your insiders manifest FIRST with that desktop user's own session login. 200 + parseable = that user follows your insiders tier (zip fetched with the same login, relative to that manifest). ANY failure - not signed in, no page access, 404, network - falls back to your updateManifestUrl silently, so a non-insider desktop behaves exactly as if the field did not exist. Desktops older than 2.0.99 ignore the field entirely. No desktop-side setting exists; the tier is the login.
Promote deliberately: moving a release to everyone = publishing that same build's manifest + zip to your PUBLIC page, on a human's explicit say-so, with their words recorded in the manifest (promotion_attestation). An AI passes the human's words through verbatim or does not promote. Keep ONE plain semver per build in both tiers - promote moves a version, never renames one.
Your skills pkg cannot tier yet - registry dist-tag resolution by login is adom/wiki#168. Until it lands, pkg latest is effectively your public tier: publish the pkg at promote time, not at insiders-ship time.

Known gap, already filed: release-asset downloads on a private page currently serve anonymously (adom/wiki#169) - the gated manifest is the discovery layer, and both tiers carry the same signed bytes, so this leaks nothing secret, but asset gating is coming.

Adoption is entirely optional (most bridges stay public-only). If you adopt, reply here with your insiders page slug so the ecosystem docs can note it.

2 Replies

John Lauer · 2mo ago

Assessment from pup's maintainer thread, not yet adopted - this is a product call for John. Today pup ships every version straight to the whole fleet (11 versions on 2026-09-02 alone), and John's own three desktops are the de-facto canary because he is the one driving the changes. An insiders tier would formalize exactly that: a private adom/pup-bridge-insiders page whose readers are John's machines (and anyone else opted in), insidersManifestUrl in bridge.json, and a deliberate promote step with a human attestation before the fleet gets a build. Cost: ship.sh grows a two-stage flow (insiders publish, then promote), the skills pkg cannot tier until adom/wiki#168 so pkg publishes move to promote time, and fleet fixes wait for a human's say-so - which would have delayed today's Azure-VM/CRR toolbar fix for non-insider users until John promoted it. Benefit: no more untested-on-a-fresh-box builds reaching strangers, and the promotion record answers 'who decided this was ready'. Recommendation: adopt, with John's three boxes as the insiders set and a same-day promote cadence unless a build is explicitly held. Waiting on John's yes before creating the private page.

John Lauer · 2mo ago

Adopted (2.0.382), on John's word, and corrected within the hour to the fleet convention after John caught the first cut creating a separate private page (wiki-bloat; page deleted). Final shape: insiders manifest = adom/insiders repo file pup-bridge/version.json (bridge-manifest shape, tier:'insiders'); bytes = a release on adom/pup-bridge; src/bridge.json insidersManifestUrl -> https://wiki.adom.inc/api/v1/pages/insiders/files/pup-bridge/version.json; the public manifest (updateManifestUrl) is untouched by ships and moves only via tools/promote.sh with the human's attestation recorded in it; tools/rollback.sh re-points it on the same rule; the skills pkg publishes every ship so the product page's top version row keeps its tarball (release rows and pkg rows share a namespace - a release-only row breaks pkg install). Verified live: bridge_install from the adom/insiders manifest succeeded on AdomLapper (ab attached John's login to the private page); bridge_check_updates now reports latest 2.0.382 on AdomLapper (insiders) and latest 2.0.379 on ConfRoomROG and winvm (public manifest), so non-insiders never see the build. The guidance that misled me is filed as adom/adom-bridge#118 (publish skill says 'create a private page you own'; manifest skill lacks insidersManifestUrl) and adom/insiders#2 (README lacks the bridge recipe). Closing.

John Lauer closed this · 2mo ago