Changeset 780a7c6 in Klonkt for src/config/database.js

Timestamp:

07/24/2026 07:44:15 PM (7 weeks ago)

Author:

Robin Genis <roboburr@…>

Branches:

main

Children:

b5924eb

Parents:

c26cc18

Message:

Guardianship Fase 0+1: de echte multi-party handshake (FEP-633c §3)

De eerste versie committeerde na één accept. Nu de spec: geen enkele partij
maakt een voogdij alleen, en een nieuwe guardian erbij kan niet zonder
toestemming van de bestaande. Daemon als blauwdruk, zodat Klonkt en de
test-daemon exact hetzelfde gedragen en de Shaer-clients één contract lezen.

Fase 0 (datamodel): ap_guardian_offers (per lokale partij een kopie van de
handshake, PK slug+offer_id) + ap_guardian_offer_accepts (de accept-tally).
ap_guardianships houdt alleen nog de GECOMMITTE relaties.

Fase 1 (state-machine): offers.js is een getrouwe port van de daemon-Handshake
(accepts over ward+candidate+existing; ready = ward && candidate && (geen
existing OF >=1 existing); een Reject voidt). handshake.js orchestreert het
gedistribueerd: de kandidaat adresseert de Offer aan ward + alle bestaande
guardians (§3.1.1); elke Accept wordt aan alle andere partijen gebroadcast, dus
elke instance-kopie convergeert; zodra een kopie compleet is committeert die
lokaal (ward schrijft shaer:guardians, guardian schrijft z'n ward), met de
kandidaat-inbox als handle (§6). Volgorde-onafhankelijk.

Ook: §1 wederzijdse uitsluiting (een ward is nooit ook guardian in het
actor-doc), de queues vullen nu de echte accept-tally (needsMyAccept/
readyToCommit/acceptedBy/existingGuardians), en de PWA + Berichten beantwoorden
via de C2S Accept/Reject-pijplijn per offer-id. De co-guardian ziet een
mede-voogdij-aanvraag met accepteer/weiger in de PWA.

Changed files:
src/config/database.js

• tabellen ap_guardian_offers + ap_guardian_offer_accepts

src/services/guardianship/offers.js (NEW)

• de handshake-state-machine (daemon-port), per-instance in SQLite

src/services/guardianship/relations.js

• alleen commit-writers + actor-props (§1 uitsluiting)

src/services/guardianship/handshake.js

• gedistribueerde multi-party C2S/S2S orchestratie

src/services/guardianship/queues.js

• offers-queue uit de state-machine

src/services/guardianship/index.js

• exports bijgewerkt

src/services/ActivityPubService.js

• wire localSlug + fetchActor; inbound-routing naar alle lokale partijen

src/routes/guardian.js

• dashboard toont offers met tally; POST /guardian/offer (accept/reject)

src/routes/posts.js

• Berichten toont ward-offers uit de state-machine; accept via offer-id

src/views/pages/messages.ejs, src/assets/js/guardian.js, src/assets/css/guardian.css

• offer-kaarten per state (mijn aanvraag / mede-voogdij / wachten)

src/services/i18n.js

• accept/reject/complete/coguard + co-guardian push (nl/en/de)

test/guardianship.test.js

• multi-party: eerste guardian, co-approval bestaande guardian, reject voidt, ward-mag-niet-guarden, vaste initiator

remarks: Fase 2 (follow-gating), 3 (hasGuardians + Not-a-Teapot), 4 (Undo/
emancipatie) volgen. 164 tests groen.

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

File:

• src/config/database.js (modified) (3 diffs)

src/config/database.js

@@ -405 +405 @@
     );
     CREATE INDEX IF NOT EXISTS idx_ap_blocks_target ON ap_blocks(target);
+    -- Committed guardian ↔ ward relations, one row per local side. role
+    -- 'ward' = the local slug is a ward of other_uri; 'guardian' = the local
+    -- slug guards other_uri. status is always 'accepted' here now: PENDING
+    -- offers live in ap_guardian_offers below (FEP-633c multi-party handshake).
     CREATE TABLE IF NOT EXISTS ap_guardianships (
       id INTEGER PRIMARY KEY AUTOINCREMENT,
@@ -411 +415 @@
       other_uri TEXT NOT NULL,     -- the counterpart actor URI (local or remote)
       other_handle TEXT,           -- cached @user@host for display
-      status TEXT NOT NULL,        -- 'offered' (handshake pending) | 'accepted'
+      status TEXT NOT NULL,        -- 'offered' (legacy) | 'accepted'
       offer_id TEXT,               -- the Offer activity id (FEP-633c section 3)
       created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
@@ -417 +421 @@
     );
     CREATE INDEX IF NOT EXISTS idx_ap_guardianships_slug ON ap_guardianships(slug, role, status);
+    -- The multi-party handshake (FEP-633c section 3), one row per offer this
+    -- instance is a party to. Mirrors the Shaer test daemon's Handshake:
+    -- accepts accumulate in ap_guardian_offer_accepts, and the offer commits
+    -- only when the candidate returns the handle after ward + candidate + at
+    -- least one existing guardian have accepted.
+    CREATE TABLE IF NOT EXISTS ap_guardian_offers (
+      offer_id TEXT NOT NULL,      -- the Offer activity id (minted by the candidate)
+      slug TEXT NOT NULL,          -- the local site tracking this handshake (each party keeps its own copy)
+      ward_uri TEXT NOT NULL,      -- the ward-to-be
+      candidate_uri TEXT NOT NULL, -- the guardian-candidate (fixed initiator)
+      existing_guardians TEXT NOT NULL DEFAULT '[]',  -- JSON array of the ward's current guardian URIs
+      status TEXT NOT NULL DEFAULT 'pending',         -- 'pending' | 'committed' | 'void'
+      handle TEXT,                 -- the escalation handle returned at commit (section 6)
+      ward_handle TEXT,            -- cached @ward@host for display
+      candidate_handle TEXT,       -- cached @candidate@host for display
+      created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
+      PRIMARY KEY (slug, offer_id)
+    );
+    CREATE INDEX IF NOT EXISTS idx_ap_guardian_offers_slug ON ap_guardian_offers(slug, status);
+    CREATE TABLE IF NOT EXISTS ap_guardian_offer_accepts (
+      offer_id TEXT NOT NULL,      -- FK to ap_guardian_offers
+      slug TEXT NOT NULL,          -- the local site's copy of the tally
+      party_uri TEXT NOT NULL,     -- the party who accepted (ward | candidate | an existing guardian)
+      created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
+      PRIMARY KEY (slug, offer_id, party_uri)
+    );
     CREATE TABLE IF NOT EXISTS ap_delivery (
       id INTEGER PRIMARY KEY AUTOINCREMENT,