Ignore:
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:
1 edited

Legend:

Unmodified
Added
Removed
  • src/services/guardianship/queues.js

    rc26cc18 r780a7c6  
    33 *
    44 * Three OrderedCollections on the actor (shaer:queues), same contract as the
    5  * Shaer test daemon so the iOS/Android guardian dashboards read them as-is:
    6  *  - offers:  pending guardianship offers where I am a party (§3)
    7  *  - follows: pending follows for my wards (§5.3) — Klonkt has no gated
    8  *             follows yet, so this collection is empty for now
    9  *  - wards:   my wards, for the dashboard's wards list
     5 * Shaer test daemon so the iOS/Android dashboards read them as-is:
     6 *  - offers:  pending handshake offers where I am a party (§3), with the full
     7 *             accept tally so the client shows the right action
     8 *  - follows: pending gated follows for my wards (§5.3) — Fase 2, empty for now
     9 *  - wards:   my committed wards
    1010 */
    11 import { GUARDIAN_RELATIONSHIP_COMPACT } from './context.js';
     11import * as offers from './offers.js';
    1212import * as relations from './relations.js';
    1313
     
    1616});
    1717
    18 /** Pending offers, reconstructed as Offer activities (either side). Each item
    19  *  also carries the daemon-contract helper fields (shaer:ward, candidate,
    20  *  needsMyAccept, iAmCandidate, …): the Shaer clients render their accept
    21  *  button from those, so the shapes must match the test daemon exactly. */
     18/** Pending offers where the local site is a party, each with its accept tally. */
    2219export function offersCollection(id, slug, me) {
    23   const items = relations.listOffers(slug).map((r) => {
    24     const ward = r.role === 'guardian' ? r.other_uri : me;
    25     const candidate = r.role === 'guardian' ? me : r.other_uri;
    26     return {
    27       id: r.offer_id || `${me}/offers/pending-${r.id}`,
    28       type: 'Offer',
    29       actor: candidate,
    30       object: {
    31         type: 'Relationship',
    32         subject: ward,
    33         relationship: GUARDIAN_RELATIONSHIP_COMPACT,
    34         object: candidate,
    35       },
    36       'shaer:ward': ward,
    37       'shaer:candidate': candidate,
    38       'shaer:existingGuardians': relations.listGuardians(slug).map((g) => g.other_uri),
    39       'shaer:acceptedBy': [],
    40       // Klonkt's flow is single-phase: the ward's Accept commits at once, so
    41       // only the ward-side owner has an action here.
    42       'shaer:needsMyAccept': r.role === 'ward',
    43       'shaer:readyToCommit': false,
    44       'shaer:iAmCandidate': r.role === 'guardian',
    45       'shaer:handle': r.other_handle || undefined,
    46       published: r.created_at,
    47     };
    48   });
     20  const items = offers.listForParty(slug, me).map((o) => offers.queueItem(o, me));
    4921  return collection(id, items);
    5022}
    5123
    52 /** Gated follows awaiting guardian approval — not built in Klonkt yet. */
     24/** Gated follows awaiting guardian approval — not built in Klonkt yet (Fase 2). */
    5325export function followsCollection(id) {
    5426  return collection(id, []);
    5527}
    5628
    57 /** The guardian's wards (accepted), with cached handle for display. */
     29/** The guardian's committed wards, with cached handle for display. */
    5830export function wardsCollection(id, slug) {
    5931  const items = relations.listWards(slug)
    60     .filter((r) => r.status === 'accepted')
    6132    .map((r) => ({ id: r.other_uri, 'shaer:handle': r.other_handle || undefined, since: r.created_at }));
    6233  return collection(id, items);
Note: See TracChangeset for help on using the changeset viewer.