Changeset 65abc85 in Klonkt for src/config/database.js

Timestamp:

07/28/2026 10:40:50 AM (6 weeks ago)

Author:

Robin Genis <roboburr@…>

Branches:

main

Children:

2708282

Parents:

2a76184

Message:

Gated settings federeren: guardians beslissen samen, ook van een andere server

Ik had de knop alleen voor het co-located geval gebouwd, en dat is precies het
uitzonderingsgeval. In de echte opstelling staat de ward op de ene server en zijn
drie guardians op twee andere: er was dus nergens een knop. Dat botst met onze
eigen regel dat co-locatie een optimalisatie is en nooit de aanname.

Nu volgens FEP-633c 5.6 (deze week aan de spec toegevoegd): een guardian stelt
een wijziging voor met een Offer van een shaer:GatedSetting aan de server van de
WARD; de andere guardians antwoorden met Accept/Reject; de server van de ward
telt en handhaaft, want die serveert de feed. Co-locatie neemt dezelfde weg: ook
daar wordt voorgesteld en geteld, anders zou een guardian naast de deur meer te
zeggen hebben dan een op afstand.

De tally is een 3.5-beslissing en staat als pure functie apart: gesnapshotte set,
strikte meerderheid, venster van een dag. Omkeerbaar, dus race naar de drempel in
BEIDE richtingen (settelt ook zodra een meerderheid onhaalbaar is) en faalt dicht
op de deadline. Een Reject is een stem voor de andere waarde, geen schouderophalen.

New file:
src/services/guardianship/gated.js

• tallyGatedSetting (puur), thresholdFor, featureColumn (onbekende features geweigerd i.p.v. geraden), recordGatedVote, en de Offer-vorm

test/gated-settings.test.js

• 9 tests: drempel, vroeg settelen in beide richtingen, dicht op de deadline, vreemden tellen niet mee, geen guardians = niets toegekend, van gedachten veranderen vervangt je stem, en een onbekende feature raakt geen kolom

Changed files:
src/config/database.js

• ap_gated_offers + ap_gated_votes

src/services/guardianship/handshake.js

• inbox: Offer(shaer:GatedSetting) en Accept/Reject erop, met de stem van de voorsteller meegeteld (one-step-clausule)

src/services/guardianship/index.js

• gated geexporteerd

src/routes/guardian.js

• de knop stuurt een voorstel, lokaal en remote langs dezelfde weg

src/assets/js/guardian.js

• knop bij ELKE ward, ook remote; toont 'wacht op de andere guardians'

src/services/i18n.js

• embeds_propose / embeds_waiting in nl, en, de

remarks: 228 tests groen (was 219).

-robo
Co-Authored-By: Claude Opus 4.8 <noreply@…>

File:

• src/config/database.js (modified) (1 diff)

src/config/database.js

@@ -502 +502 @@
       PRIMARY KEY (slug, offer_id, party_uri)
     );
+    -- FEP-633c §5.6: a gated setting a ward's guardians decide together, which
+    -- has to work when they live on other servers (the ordinary case). One row
+    -- per guardian answer; the ward's server tallies (§3.5) and enforces.
+    -- The proposals themselves, so an Accept that only references the offer
+    -- id can still be resolved to "which feature, which value".
+    CREATE TABLE IF NOT EXISTS ap_gated_offers (
+      offer_id TEXT PRIMARY KEY,
+      slug TEXT NOT NULL,          -- the ward, on this server
+      feature TEXT NOT NULL,
+      value INTEGER NOT NULL,
+      created_at DATETIME DEFAULT CURRENT_TIMESTAMP
+    );
+    CREATE TABLE IF NOT EXISTS ap_gated_votes (
+      slug TEXT NOT NULL,          -- the WARD, on this server
+      feature TEXT NOT NULL,       -- e.g. 'shaer:externalEmbeds'
+      guardian_uri TEXT NOT NULL,  -- who answered (must be a committed guardian)
+      value INTEGER NOT NULL,      -- the value they voted for (0/1)
+      opened_at DATETIME NOT NULL, -- when this decision opened (the window start)
+      created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
+      PRIMARY KEY (slug, feature, guardian_uri)
+    );
     CREATE TABLE IF NOT EXISTS ap_delivery (
       id INTEGER PRIMARY KEY AUTOINCREMENT,