mirror of
https://github.com/PR0M3TH3AN/bitgate.git
synced 2026-10-27 16:41:03 +00:00
thePR0M3TH3AN
adeba151b8
Renames the project and makes it as easy to adopt as BitLogin, which was the stated bar and which it did not previously meet. Rename (ADR 0005): @nostr-governance/* -> @bitgate/*, governance-* elements -> bitgate-*, createGovernanceRuntime -> createBitGate. "Governance" reads as DAO voting to this audience and named a category rather than a product; BitGate names the benefit and joins the bit- family that BitVid and BitRoad compose with. Domain types keep their names — the product is BitGate, the subject matter is still governance. The migration plan is left as written; this ADR records the change rather than rewriting history. Drop-in distribution (ADR 0006): adopting BitGate meant supplying a transport, authoring a policy, and wiring every element in JavaScript. Now: - createRelayTransport(urls) — WebSocket transport with reconnection, backoff, subscription replay, and cross-relay dedupe - policy presets (social, commerce, admin-only) addressable by name; the engine still carries no thresholds of its own - <bitgate-provider> — configuration in markup, with descendants finding the runtime through a bubbling context event rather than DOM walking, which breaks across shadow boundaries - npm run build:widget — a self-contained dist/bitgate.js That last one came from running it in a browser rather than from a test. Bare specifiers resolve in Node and vitest but not in a browser, so the widget source worked everywhere except a plain static page — the one place it exists to serve. The bundle is not committed: consumers build from reviewed source. Also found by running it: the provider's ready event fires during element upgrade, before a page that defines elements after parsing can attach a listener, so it now exposes `ready` as a promise too. Four bugs fixed along the way, three found by new tests and one by the browser: admin state stayed silent when a roster change altered capabilities but no denials; the relay transport sent every subscription twice on connect; the commerce preset computed a meaningless visibility verdict at checkout and could hide a listing from its own seller; <bitgate-status> threw on an unusable decision. 759 tests; lint, typecheck, and both builds clean.
69 lines
2.9 KiB
Markdown
69 lines
2.9 KiB
Markdown
# 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 `@bitgate/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`](test/proof-of-fit.test.js):
|
|
|
|
1. **Seller allowlist mode** — unlisted sellers are hidden from discovery, but
|
|
the allowlist is not enforced at checkout
|
|
2. **Administrative seller denial** — takes the seller's whole catalogue down
|
|
while leaving them their own dashboard view
|
|
3. **Product-address denial** — survives the seller republishing under a new
|
|
event id, and does not touch their other listings
|
|
4. **Exact-event denial** — affects only the named revision
|
|
5. **Trusted scam-report downranking** — one report reorders, three block
|
|
checkout; nothing is hidden on a single signal
|
|
6. **Malware checkout denial** — one trusted malware report blocks the sale,
|
|
while three "misleading" reports do not
|
|
7. **Moderator capability checks** — a listing moderator cannot deny a seller;
|
|
a seller moderator cannot deny a listing address
|
|
8. **Community curator ingestion** — curated denials are honored, curator
|
|
contributions beyond their capability are dropped, and the root cannot be
|
|
denied through a curated list
|
|
9. **Seller-dashboard explanation** — the seller sees who reported and why;
|
|
public surfaces see only counts
|
|
10. **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
|
|
|
|
```bash
|
|
npm test -- examples/commerce
|
|
```
|