skill

Adom Wiki

Public Made by Adom

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

wikiclipackagesregistrypublishingguide
Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity
Closed general

Page rename 301s the HTML but 404s /api/pages/.../files/, silently stranding every installed bridge's auto-update

John Lauer · 2mo ago ·closed by Colby Knox

Surfaced by the adom-browser-extension -> adom-native-browser rename (2026-08). The rename itself was clean; this is a gap in what the redirect covers, and it will hit every future bridge rename identically.

The gap

The human-facing page redirects. The API file path does not:

GET /adom/adom-browser-extension                                                     -> 301  (good)
GET /download/adom/adom-browser-extension/0.1.54/...zip                              -> 200  (good)
GET /api/pages/adom/adom-browser-extension/files/native-browser-bridge-manifest.json -> 404  (no redirect)
GET /blob/app/adom-browser-extension/screenshots/foo.png                             -> 404  (no redirect)

Why that path matters more than the others

Every Bridge bridge stores an updateManifestUrl in its own bridge.json and polls it (on launch, then every 4h) to self-update. That URL is exactly the /api/pages/<owner>/<slug>/files/<manifest>.json shape. After a rename it 404s, so:

  • The failure is SILENT and reads as success. bridge_check_updates returns latest: null, updateAvailable: false, wikiReachable: true , indistinguishable from "you are already current." refresh_bridges reports action: current_offline and quietly keeps the stale cache. Nothing errors, so nobody investigates.
  • It is self-stranding. The corrected URL ships INSIDE the new version, which cannot be fetched because the old URL is dead. An installed bridge cannot recover on its own no matter how many versions I publish.
  • It is fleet-wide. Every machine with this bridge installed stopped receiving updates the moment the page was renamed. I only caught it by checking the URL by hand during the rename sweep. My own laptop sat on 0.1.54 while 0.1.55 was published and serving.

Verified recovery (what every affected user would have to do)

adom-desktop bridge_install '{"manifestUrl":"https://wiki.adom.inc/api/pages/adom/adom-native-browser/files/<manifest>.json"}'

Re-points AD at the live URL, confirmed on my box: current: 0.1.55, latest: 0.1.55, wikiReachable: true. It works, but it requires knowing the rename happened AND knowing this remedy. Nothing prompts either.

Ask

Make /api/pages/<owner>/<old-slug>/files/... 301 to the new slug, exactly as the HTML path already does. One change makes renames non-breaking for every bridge on the platform, and retroactively heals the currently-stranded installs on their next 4h poll.

Two smaller ones, in priority order:

  1. Extend the redirect to /api/v1/pages/... and /blob/app/<slug>/.... The blob path silently breaks README images and embedded demo videos on any renamed page; I had to rewrite mine by hand.
  2. If a redirect is unwanted on the API surface, return 410 Gone with the new slug in the body instead of a bare 404, so callers can self-diagnose. A 404 is indistinguishable from "never existed."

Happy to test a fix, since I have a reproducible stranded config.

1 Reply

Colby Knox · 2mo ago

Fixed and live on prod, and verified against your exact case. The rename alias now covers the file paths, not just the HTML page:

  • /api/pages/<owner>/<slug>/files/<path> (owner-qualified and bare-slug) and /blob/<type>/<slug>/<path> now 301 to the renamed slug, preserving the file path, the query, and the /api/v1 prefix. So a bridge's pinned updateManifestUrl keeps resolving after a rename instead of silently 404ing into latest: null.
  • Your page was renamed TWICE (adom-browser-extension -> adom-native-browser -> nb-bridge), so I also collapsed alias CHAINS: the original URL now 301s straight to the FINAL slug in ONE hop, so a client that caps redirects at 1 still resolves. Cycle-guarded and depth-capped.

Verified on prod:

GET /api/v1/pages/adom/adom-browser-extension/files/version.json
  -> 301 Location: /api/v1/pages/adom/nb-bridge/files/version.json   (one hop)

Bare-slug and /blob paths carry no owner, so they only redirect when the slug is unambiguous across owners (more than one owner having renamed the same slug won't guess) but the owner-qualified path bridges actually use always resolves. Covered by the rename test suite (single + double rename, /files/ + /blob/). Closing as done.

Log in to reply.