thePR0M3TH3AN
6957594c36
Follows bitlogin's layering: the engine stays headless and the widget is a consumer of the published API, never a dependency of it. Building it was also a test of that API — an element needing something unexposed would have been a finding, the way the commerce example was. Viewer elements: governance-veil (blur on restrict, disclosure on hide, warning on warn), governance-report, governance-status. Moderator elements: governance-capabilities, governance-action, governance-admin-panel. Deliberate behaviors: - hidden content leaves the accessibility tree rather than being visually covered, so a screen reader does not read out what the viewer must not see - a hidden decision renders a disclosure, not nothing: content that silently vanishes is indistinguishable from a bug and leaves no route to appeal - refused moderator actions stay visible and name the missing capability. A hidden button teaches nothing about the authority model, and the command layer enforces the same check independently — the UI is an explanation, never the gate - no element computes policy; wording maps from stable reason identifiers and is overridable per application Found while building it: GovernanceAdminStore emitted only when reduced denial state changed, so revoking a role that denied nobody announced nothing, leaving capability-gated UI and the decision cache stale. The root tsconfig deliberately omits the DOM lib — that absence is what keeps core, nostr, and runtime from reaching for browser globals — so the widget carries its own DOM-aware config rather than relaxing the guarantee globally. 687 tests; lint, typecheck, and the declaration build pass from a cold checkout.
Commerce proof-of-fit
A marketplace built on nostr-governance, using only the published API.
The point is not to ship marketplace moderation. It is to prove the engine did
not accidentally stay video-specific during extraction: if a commerce consumer
needs a change to @nostr-governance/core, the abstraction is wrong.
What it demonstrates
The migration plan lists ten behaviors a commerce consumer should show before
1.0.0. Each is a numbered block in
test/proof-of-fit.test.js:
- Seller allowlist mode — unlisted sellers are hidden from discovery, but the allowlist is not enforced at checkout
- Administrative seller denial — takes the seller's whole catalogue down while leaving them their own dashboard view
- Product-address denial — survives the seller republishing under a new event id, and does not touch their other listings
- Exact-event denial — affects only the named revision
- Trusted scam-report downranking — one report reorders, three block checkout; nothing is hidden on a single signal
- Malware checkout denial — one trusted malware report blocks the sale, while three "misleading" reports do not
- Moderator capability checks — a listing moderator cannot deny a seller; a seller moderator cannot deny a listing address
- Community curator ingestion — curated denials are honored, curator contributions beyond their capability are dropped, and the root cannot be denied through a curated list
- Seller-dashboard explanation — the seller sees who reported and why; public surfaces see only counts
- No core changes required — four different verdicts for one product from one snapshot, using only exported functions
Files
| File | Contents |
|---|---|
src/policy.js |
Marketplace thresholds and roles. None of these numbers exist in the core. |
src/adapters.js |
Products, storefronts, reviews, and sellers as governance targets. |
src/marketplace.js |
Feed pipeline, grid ordering, checkout, seller explanation. |
The shape worth copying
A product answers to three targets — its seller, its exact event, and its address coordinate — and the composed decision is the strictest verdict reaching it. That is what makes "deny the seller" remove every listing without a line of cascade logic in the application.
One product, one snapshot, four surfaces:
| Surface | Visibility | Transaction |
|---|---|---|
public-marketplace |
restrict |
deny |
product-detail |
restrict, overridable |
deny |
checkout |
allow |
deny |
seller-dashboard |
restrict, with evidence |
deny |
Reviews deliberately answer to their reviewer and their own event — never to the product they review. Otherwise denying a bad product would silence the reviews warning people about it.
Run it
npm test -- examples/commerce