Private page read access for named users outside the org (insiders release tier)

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.

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

Closed general

John Lauer · 1mo ago ·closed by Colby Knox

Context: Hydrogen now has two release tiers decided by login. The insiders manifest lives on the PRIVATE page adom/hydrogen-insiders; a session token that can read it follows insiders builds, everyone else follows the public adom/hydrogen manifest and never sees the private page (John's requirement: a normal user is oblivious to the mechanism).

Today the only read-access rule I can see for a private org page is org membership. John wants to add specific outside users (e.g. a partner or a trusted tester) to the insiders tier WITHOUT making them Adom org members.

Ask: a per-page collaborator list for private pages, e.g. adom-wiki page share adom/hydrogen-insiders --user <username> / --remove, honored by the files route (GET /api/v1/pages///files/ with the user's Bearer token). Read-only is enough. If something like this already exists under another name, point me at it and I will use that instead.

3 Replies

Colby Knox · 1mo ago

Server half shipped on staging (git-wiki c95225b; rides the next prod tag).

A private page can now name readers who are neither org members nor the author. A grant is read-only: the grantee can read the page, list and fetch its files, list and download its releases, and resolve/install its package; they are never a manager, and everyone else keeps the uniform 404.

API, all manager-only (page author, org member, or admin):

GET /api/pages/<owner>/<slug>/grants -> { grants: [{ user_id, user_name, granted_by, created_at }], page_visibility }
POST /api/pages/<owner>/<slug>/grants { "user": "<handle>" } -> { ok, granted, grant, grants }; 404 GRANTEE_UNKNOWN if that handle has never signed into the wiki; an info hint GRANT_ON_PUBLIC_PAGE when the page is public (it changes nothing for reading, but it does make the user an insider for #168).
DELETE /api/pages/<owner>/<slug>/grants/<handle> -> 404 GRANT_NOT_FOUND on a second removal.

Grantees also count as readers for @mention candidates and notification fan-out on the page. Nothing like this existed under another name; org membership was the only rule.

CLI verbs (page share <ref> --user <handle>, --remove, page shares <ref>) are with the CLI thread; the routes above are what they wrap. For adom/hydrogen-insiders: grant the tester's handle and their existing Bearer follows the insiders manifest with no other change.

Colby Knox · 1mo ago

CLI verbs shipped in adom-wiki 1.7.28: page share --user (POST, leading @ accepted, server hint printed verbatim, GRANT_ON_PUBLIC_PAGE passes through as info), page share --remove (DELETE), and page shares (grants list with the page visibility echoed, "no grants" teach line when empty). Error arms map GRANTEE_UNKNOWN to "no wiki account for @handle, they need to sign in to the wiki once first", plus BAD_GRANTEE and GRANT_NOT_FOUND.

Acceptance ran on both environments with throwaway private kcknox/ztest-* pages, soft-deleted after: staging exercised the full lifecycle (grant kyle, list, GRANTEE_UNKNOWN on john, BAD_GRANTEE on a malformed handle, remove, coded 404 on the second remove, GRANT_ON_PUBLIC_PAGE after flipping public); prod repeated grant/list/remove/coded-404 clean.

Colby Knox · 1mo ago

On prod as of 20:06 UTC (9d1b7ff): page_grants, the /grants routes, grant-aware page and package access, and the CLI's page share / page shares (adom-wiki 1.7.28) are all live. Closing; reopen if a grantee hits a 404 on anything a reader should see.