- Timestamp:
- 07/28/2026 08:15:31 PM (6 weeks ago)
- Author:
- Robin Genis <roboburr@…>
- Branches:
- main
- Children:
- 6eab7e9
- Parents:
- 742ba7e
- Message:
-
De Undo bij het loslaten van een ward reist nu echt mee
Loslaten was een lokale delete. De guardian vergat het kind, terwijl de server
van het kind hem gewoon in shaer:guardians bleef noemen. De vorige commit zette
dat als waarschuwing in beeld; Robin noemt het terecht een bug, want FEP-633c
3.2 zegt gewoon dat een Undo van de Relationship de guardian eruit haalt.
Nu gaat er een Undo naar het kind en naar de andere guardians, met dezelfde
adressering als de Offer waarmee het begon (3.1.1), zodat geen kopie achterblijft
die denkt dat de band er nog is. De ontvangende kant haalt de guardian eruit,
maar alleen als de guardian zelf tekent: de variant waarbij het kind opzegt met
een mede-ondertekenende guardian heeft een tweede handtekening nodig en is niet
gebouwd, dus die wordt geweigerd in plaats van half uitgevoerd.
De laatste guardian kan niet meer alleen weglopen. 3.3 geldt zolang er meer dan
een over is; de set leegmaken is emancipatie (3.4) en daar gaat geen enkele
partij alleen over. Dat wordt geweigerd aan beide kanten, en de knop biedt in
dat geval alleen nog een nee aan in plaats van een ja die toch een fout geeft.
Een kind op DEZELFDE instance kreeg de Undo niet: een inbox op deze machine is
van deze machine niet over HTTP bereikbaar, en dat hoort ook niet. De commit-kant
lost dat al zo op dat elke instance schrijft wat hij host; het loslaten doet dat
nu ook. In de browser gevonden nadat de guardian-kant leeg was en de kant van het
kind nog niet.
Een guardian-app kan hetzelfde over C2S: een Undo naar de eigen outbox loopt
langs precies dezelfde functie als de knop in de PWA, zodat die twee niet uit
elkaar kunnen groeien.
Changed files:
src/services/guardianship/handshake.js
- endGuardianship: bouwt en verstuurt de Undo, weigert emancipatie, en schrijft de kant van een lokaal gehost kind zelf
- applyInboundUndo + dropGuardianFromWard: de ontvangende kant
- handleOutbox accepteert Undo; handleInbox routeert hem
src/services/guardianship/index.js
- endGuardianship en parseUndoRelationship geexporteerd
src/services/ActivityPubService.js
- de guardianship-dispatch ziet Undo nu voordat de generieke Undo-tak hem opslokt met een 202
- push voor een vertrokken guardian en een vertrokken mede-guardian
src/routes/guardian.js
- /wards/remove loopt langs endGuardianship in plaats van een lokale delete
- release-check meldt niet langer dat de Undo blijft liggen
src/assets/js/guardian.js
- geen ja-knop meer als jij de laatste bent; een 409 wordt getoond in plaats van stil hertekend
src/services/i18n.js
- de waarschuwing klopt weer, plus push-teksten in nl, en, de
test/guardianship.test.js
- zes tests: de Undo werkt aan beide kanten, de laatste guardian wordt geweigerd, hij is idempotent, C2S loopt hetzelfde pad, een vreemde Undo verandert niets, en een kind op dezelfde instance wordt ook bijgewerkt terwijl er niets bezorgd is
remarks: end-to-end nagekeken in de browser: na het loslaten staat guard niet
meer in shaer:guardians van het actor-document van het kind, en een POST die de
knop omzeilt krijgt 409 would_emancipate.
-robo
Co-Authored-By: Claude Opus 4.8 <noreply@…>
- (No files)
-
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)