source: Klonkt/src/services/ActivityPubService.js@ 47db4b5

Een Move is een Move: de guardianship verhuist mee

Robins redenering, en die is korter dan de mijne: de guardian is nog steeds
dezelfde guardian, dus dat mag gewoon gebeuren. Dat klopt met de spec. FEP-633c §5
zegt dat toezicht een gewone Follow is, en die verhuisde hier al mee, inclusief de
uitgelicht-stand.

Alleen de RELATIE bleef aan de oude URI hangen. Daar stond een console.warn met
"left untouched (shaer-tge)" en verder niets. Dat gaf de vervelendste toestand van
allemaal: de guardian ziet de posts van het kind gewoon 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, en
dan merk je het pas op het moment dat het nodig is.

Nu een UPDATE naast de re-follow, met dezelfde bescherming eromheen: alleen na een
geverifieerde Move, alleen voor een geaccepteerde relatie, en niet naar een
geblokkeerde bestemming.

De twee harde randen van shaer-tge blijven staan en gaan over iets anders dan ik
eerst dacht: weigeren te verhuizen naar een instance die shaer:guardians niet kan
dragen is een controle aan de UITGAANDE kant, en terugkeren-zonder-set is een
alsoKnownAs-kwestie. Die bead blijft dus open, maar smaller.

Changed files:
src/services/ActivityPubService.js

• handleMoveInbox werkt ap_guardianships.other_uri bij in plaats van te waarschuwen

New file:
test/move-guardianship.test.js

• de relatie wijst na de Move naar het nieuwe adres, en verdubbelt niet
• de Follow verhuist mee met de uitgelicht-stand
• een NIET-geverifieerde Move raakt hem niet aan (anders haalt een vreemde een kind bij zijn guardians weg met een verzonnen Move)
• een nog niet geaccepteerde relatie blijft staan
• een geblokkeerde bestemming verandert niets

remarks: tegenproef gedaan. Zonder de fix valt alleen test 1 om en blijven de vier
bewakingstests groen, dus ze meten de reparatie en niet zichzelf. Suite 932 groen in
UTC en Europe/Amsterdam. Onderweg had ik de kolomnaam van ap_blocks verkeerd
(target, niet actor_uri); dat was mijn test, niet de code.

FEP-633c zegt NIETS over verhuizen. Dat is een gat in de spec, niet alleen in
Klonkt, en het is een paragraaf waard.

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