mirror of
https://github.com/PR0M3TH3AN/bitgate.git
synced 2026-10-27 08:31:00 +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.
35 lines
1.4 KiB
Markdown
35 lines
1.4 KiB
Markdown
# ADR 0003 — The engine carries no thresholds
|
|
|
|
**Status:** accepted
|
|
|
|
## Context
|
|
|
|
The extraction started from one application's numbers: blur at 3 trusted
|
|
reports, hide at 20 trusted mutes, a 60-day mute window. Those were nearly
|
|
promoted into the core as defaults, which would have made every future consumer
|
|
inherit a video application's editorial judgement.
|
|
|
|
## Decision
|
|
|
|
The core defines the *vocabulary* — target types, capabilities, effect ladders,
|
|
reason identifiers, aggregation and precedence rules — and no thresholds.
|
|
Applications supply a `PolicyDefinition` of named profiles with category
|
|
thresholds. The characterized reference values live in
|
|
`@bitgate/bitvid-compat` as one application's profile.
|
|
|
|
`NEUTRAL_POLICY` is the fallback: it enforces administrative denial and applies
|
|
no trust thresholds, so the generic engine never hides content merely because
|
|
one trusted account acted against it.
|
|
|
|
## Consequences
|
|
|
|
A new consumer writes a policy instead of arguing with a default. The commerce
|
|
example needed no core change, which is the test this decision has to pass.
|
|
|
|
An application that supplies no policy gets very little enforcement. That is
|
|
deliberate: silently applying someone else's moderation thresholds is worse than
|
|
applying none, because the operator would not know it was happening.
|
|
|
|
Threshold `0` means "gate disabled" rather than "fires on everything", so
|
|
zeroing a value is a safe way to switch a gate off.
|