Adom Wiki
Public Made by Adomby 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.
Private source 403s /files/, breaking auto-update for closed-source product pages
Setting source_visibility: private also 403s /files/, which breaks auto-update for every closed-source product page.
Measured live on adom/adom-bridge (2026-08-08), reverted within a minute.
The "closed-source Page" pattern in the wiki-visibility skill (private source + public releases/pkg) is exactly what we want for Adom Bridge: users install the signed binary, nobody reads the Rust. Applying it via adom-wiki page visibility adom/adom-bridge --preset licensed sets the axes correctly:
visibility: public | source_visibility: private | release_visibility: public | pkg_visibility: public
But source_visibility: private gates the entire /files/ store, and that store holds artifacts that MUST stay anonymously readable:
| anon request | before preset | after preset |
|---|---|---|
/api/v1/pages/adom-bridge/files/version.json |
200 | 403 |
/api/v1/pages/adom-bridge/files/docs/bridge-sdk.md |
200 | 403 |
Why this is severe rather than cosmetic. version.json is the auto-update manifest that every deployed Adom Bridge polls anonymously on launch and every 4 hours, and it is the documented contract Hydrogen reads to bundle our installer (consumers are explicitly told to read version.json.windows.installer_url and NEVER to construct a filename). A 403 there silently freezes the whole fleet's updater: no error surfaces to the user, installs just stop updating. The same gate 403s docs/*, so a public README that embeds page screenshots renders with broken images to exactly the audience the public readme exists for.
So today the choice is: private source, or a working product. Not both. We reverted to public source to keep the fleet updating.
The ask: a public carve-out for a small set of /files/ paths while source stays private. Any of these would work for us, in preference order:
- A conventional always-public prefix, e.g.
files/public/**(or keepversion.json+docs/**public by convention), served regardless ofsource_visibility. - A per-file/per-glob visibility override in page metadata, e.g.
public_files: ["version.json", "docs/**"]. - Treat
version.jsonspecially, since it is already a documented cross-page contract.
Why not just move the manifest. Publishing version.json as a release asset instead would break the documented contract that consumers read it from /files/, and would require coordinated changes in every deployed binary plus Hydrogen. The whole point of the contract is that consumers never construct URLs.
Scope. This is not adom-bridge-specific. The "one product = one page" doctrine plus private source means every closed-source product page that ships an auto-updating binary or an illustrated public readme hits this the moment it flips source private. hydrogen-desktop is in the same position.
Happy to test any carve-out mechanism against a real fleet the day it lands.