thePR0M3TH3AN
2beb7a7bb5
Proves the engine did not stay video-specific during extraction. - application adapter contract in core (createApplicationAdapter, evaluateObject, collectTargets): an object names the targets that govern it and the strictest verdict reaching any of them wins, so denying a seller takes their whole catalogue down with no cascade logic in the application - examples/commerce: a marketplace on the public API covering all ten proof-of-fit behaviors the plan requires, including that no core change was needed. One product, one snapshot, four surfaces, four different verdicts. - README, integration guide, per-example README, CHANGELOG, four ADRs, and GPL-3.0-or-later LICENSE (the license was listed in Phase 1 but missing) - checkpoints rewritten to reflect actual state and to say plainly which migration-plan phases belong to the consumer repos rather than here Fixes a real gap found by the proof-of-fit: composeDecisions kept only the first decision's evidence, so an object governed by several targets lost the evidence that drove its verdict. Evidence now merges — counts summed, contributor lists unioned, flags or-ed. 556 tests; lint, typecheck, and per-package type build clean.
2.9 KiB
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