Changeset 44dfbd2 in Klonkt

Timestamp:

08/13/2026 08:32:21 PM (4 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

4766720

Parents:

54b027a

Message:

Eerst de guardianship verhuizen, dan pas de follow

Robins regel na zijn eigen verhuizing, en het log van beta bewijst hem:

[AP] outgoing Follow beta → ​https://soundfabrics.nl/ap/users/robo

(gated, awaiting guardians)

Beta is zelf een ward. Zijn UITGAANDE follow naar de verhuisde guardian werd
gepoort door §5.3, want op dat moment stond het nieuwe adres nog niet in zijn
guardian-lijst: handleMoveInbox werkte de relatie pas NA de follows bij. De
inkomende kant heeft precies hetzelfde: de ward gate't een Follow van een
onbekende, en de verhuisde guardian is op dat moment een onbekende.

Dus beide richtingen bleven hangen op een goedkeuring die niemand hoefde te geven,
omdat het om een guardian ging die er al was. Met de relatie eerst is de verhuisde
actor al erkend als de follows langskomen en gaat de auto-acceptatie door.

De volgorde is hier dus geen netheid maar de werking.

Changed files:
src/services/ActivityPubService.js

• het guardianship-blok staat nu VOOR de follow-lus, met het waarom erbij

test/move-guardianship.test.js

• test 5 meet de VOLGORDE, niet de uitkomst: hij leest de relatie uit binnen de injecteerbare followFn en eist dat die daar al op het nieuwe adres staat

remarks: de tegenproef is hier het punt. De vijf bestaande tests slagen ook met de
oude volgorde, want die kijken naar de eindtoestand. Met de guardianship-update er
wel in maar NA de follows valt alleen test 5 om. Suite 938 groen in UTC en
Europe/Amsterdam.

Dit is handmatig al rechtgezet voor beta en robo (relatie overgezet, follow opnieuw
gestuurd, beta's log gaat van "gated, awaiting guardians" naar "sig ok"). Deze commit
zorgt dat de volgende verhuizing die handmatige stap niet meer nodig heeft.

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

Files:

• src/services/ActivityPubService.js (modified) (2 diffs)
• test/move-guardianship.test.js (modified) (1 diff)

src/services/ActivityPubService.js

@@ -5783 +5783 @@
     return 202; // decline to act; no 4xx, the sender may be a well-meaning retrying server
   }
+  // EERST de guardianship, DAARNA pas de follows. Die volgorde is geen netheid
+  // maar de hele werking, en hij is met bloed geschreven: bij Robins verhuizing
+  // op 13-8 stond het andersom en het log liet precies zien wat er dan gebeurt.
+  //
+  //   [AP] outgoing Follow beta → .../robo (gated, awaiting guardians)
+  //
+  // Beta is zelf een ward. Zijn UITGAANDE follow naar de verhuisde guardian werd
+  // gepoort (§5.3), want op dat moment stond het nieuwe adres nog niet in zijn
+  // guardian-lijst: de code hieronder had de relatie nog niet bijgewerkt. En de
+  // INKOMENDE kant heeft hetzelfde probleem, want de ward gate't een Follow van
+  // een onbekende. Dus beide richtingen bleven hangen op goedkeuring die niemand
+  // hoefde te geven, omdat het om een guardian ging die er al was.
+  //
+  // Met de relatie eerst is de verhuisde actor al een erkende guardian als de
+  // follows langskomen, en gaat de auto-acceptatie gewoon door.
+  //
+  // Een Move is een Move: de guardian is dezelfde guardian, het kind is hetzelfde
+  // kind, alleen het adres is nieuw. Zelfde bescherming als de re-follow: alleen
+  // na een geverifieerde Move, en niet naar een geblokkeerde bestemming (daar
+  // zijn we hierboven al uitgestapt). De twee harde randen van shaer-tge staan
+  // hier LOS van: weigeren te verhuizen naar een instance die shaer:guardians
+  // niet kan dragen is een controle aan de UITGAANDE kant, en het
+  // terugkeren-zonder-set is een alsoKnownAs-kwestie.
+  try {
+    const g = db.prepare('SELECT slug, role FROM ap_guardianships WHERE other_uri = ? AND status = ?').all(oldUri, 'accepted');
+    if (g.length) {
+      const r = db.prepare('UPDATE ap_guardianships SET other_uri = ? WHERE other_uri = ? AND status = ?').run(newUri, oldUri, 'accepted');
+      console.log('[AP] guardianship moved:', oldUri, '→', newUri, `(${r.changes}x)`, g.map((x) => `${x.role}:${x.slug}`).join(', '));
+    }
+  } catch (e) { console.warn('[AP] guardianship move failed:', e && e.message); }
+
   for (const row of rows) {
     const site = db.prepare('SELECT * FROM sites WHERE slug = ?').get(row.slug);
@@ -5795 +5826 @@
     }
   }
-  // Een Move is een Move: de guardian is dezelfde guardian, het kind is hetzelfde
-  // kind, alleen het adres is nieuw. Toezicht IS een gewone Follow (FEP-633c §5),
-  // en die is hierboven al meeverhuisd -- maar de relatie zelf hing nog aan de
-  // oude URI. Dat leverde de vervelendste toestand op: de guardian ziet de posts
-  // nog binnenkomen, terwijl alles dat op other_uri matcht omvalt (de gate op een
-  // nieuwe volger, het escalatiepad, listGuardians bij het kind). Half een
-  // vangnet ziet eruit als een heel vangnet.
-  //
-  // Zelfde bescherming als de re-follow hierboven: alleen na een geverifieerde
-  // Move, en niet als de bestemming geblokkeerd is (daar zijn we al uitgestapt).
-  // De twee harde randen van shaer-tge staan hier LOS van: weigeren te verhuizen
-  // naar een instance die shaer:guardians niet kan dragen is een controle aan de
-  // UITGAANDE kant, en het terugkeren-zonder-set is een alsoKnownAs-kwestie.
-  try {
-    const g = db.prepare('SELECT slug, role FROM ap_guardianships WHERE other_uri = ? AND status = ?').all(oldUri, 'accepted');
-    if (g.length) {
-      const r = db.prepare('UPDATE ap_guardianships SET other_uri = ? WHERE other_uri = ? AND status = ?').run(newUri, oldUri, 'accepted');
-      console.log('[AP] guardianship moved:', oldUri, '→', newUri, `(${r.changes}x)`, g.map((x) => `${x.role}:${x.slug}`).join(', '));
-    }
-  } catch (e) { console.warn('[AP] guardianship move failed:', e && e.message); }
   return 202;
 }

test/move-guardianship.test.js

@@ -92 +92 @@
 });
 
+// De VOLGORDE, niet de uitkomst. De tests hierboven slagen ook als de relatie pas
+// na de follows wordt bijgewerkt, en juist dat ging mis bij Robins verhuizing:
+//
+//   [AP] outgoing Follow beta → .../robo (gated, awaiting guardians)
+//
+// Beta is zelf een ward, dus zijn uitgaande follow naar de verhuisde guardian werd
+// gepoort omdat het nieuwe adres nog niet in zijn guardian-lijst stond. Beide
+// richtingen bleven hangen op een goedkeuring die niemand hoefde te geven.
+test('de guardianship is al bijgewerkt VOORDAT de follow uitgaat', async () => {
+  let standTijdensFollow = null;
+  const stil = console.log; console.log = () => {};
+  try {
+    await AP.handleMoveInbox(move, {
+      ...stubs,
+      followFn: async () => {
+        // Op dit moment moet de gate aan de andere kant ons al kennen.
+        standTijdensFollow = db.prepare('SELECT other_uri FROM ap_guardianships').get().other_uri;
+        return true;
+      },
+    });
+  } finally { console.log = stil; }
+
+  assert.equal(standTijdensFollow, NIEUW,
+    'staat de relatie hier nog op het oude adres, dan gate\'t de ward de follow van zijn eigen guardian');
+});
+
 test('een Move naar een geblokkeerde bestemming verandert niets', async () => {
   db.prepare('INSERT INTO ap_blocks (slug, target, kind) VALUES (?,?,?)').run('voogd', NIEUW, 'actor');