Changeset 4c1e327 in Klonkt

Timestamp:

08/07/2026 12:00:55 PM (5 weeks ago)

Author:

roboburr <roboburr@…>

Branches:

main

Children:

20ae7b0

Parents:

1e172f3

git-author:

Robin <roboburr@…> (08/07/2026 12:00:53 PM)

git-committer:

roboburr <roboburr@…> (08/07/2026 12:00:55 PM)

Message:

Guardianship Fase 2: gate-verzoeken bereiken een C2S-client (shaer-jdb)

Barts melding: in GuardianshipView staan de volgverzoeken niet, inkomend noch
uitgaand. De SECTIES in de app zijn er wel; er kwam alleen nooit iets binnen.

WELKE FASE 2 DIT IS. De faseplanning komt uit 780a7c6 "Guardianship Fase 0+1: de
echte multi-party handshake" -- Fase 0 het datamodel, Fase 1 de state-machine.
queues.js noemt Fase 2 twee keer, allebei over dit: "follows: pending gated
follows for my wards (5.3)". De gating ZELF is al gebouwd (shaer-hxg, gesloten
25 juli, getest en live); wat nooit gebeurde is het doorgeven aan een client.
Dat was een koersbesluit: shaer-sqo is in juli gesloten als vervallen met
"doorbouwen op de PWA-guardian, niet een aparte iOS-UI". Die koers is met de
Guardian-chip uit shaer-f8g omgedraaid, dus de stub kan nu dicht.

DRIE LAGEN, van onder naar boven.

1. shaer:direction werd gezet en nooit gelezen. Bij een uitgaande gate stuurt de ward een Offer met 'shaer:direction': 'outgoing'; die vlag kwam in de hele codebase precies een keer voor, bij het versturen. De guardian sloeg hem op in dezelfde tak als een inkomende, waar follower de actor van de Follow is en wardUri die van de Offer -- bij een uitgaande allebei de ward. Het doel, waar het antwoord over gaat, viel weg. ap_follow_reviews heeft nu direction, target_uri en target_handle, en de inbox leest de vlag. Terugval voor oudere afzenders: is de volger de ward zelf, dan is het uitgaand -- dat volgt uit de vorm en hoeft niet geloofd te worden.

2. followsCollection gaf een lege lijst terug. Vult nu uit twee bronnen: de doorgestuurde kopie van een remote ward, en een ward op deze instance. Die tweede hoort op termijn ook over de lijn (shaer-h6u).

3. outgoingFollowsCollection serveerde alleen listForWard(slug): wat DEZE account als ward wil volgen. Voor een guardian is dat per definitie leeg. Nu bedient dezelfde wachtrij beide lezers, en dat kan omdat 5.1 een ward en een guardian wederzijds uitsluit: je bent het een of het ander.

Bij een remote ward wordt shaer:guardianCount WEGGELATEN in plaats van op nul
gezet: die set wordt op diens eigen server bijgehouden, en nul leest als "dit
kind heeft geen guardians" -- het tegenovergestelde van onbekend.

Bestaande rijen missen de richting en zijn niet te repareren; die vallen terug op
inkomend, want dat waren ze toen ook.

5 tests. Gecontroleerd dat ze bijten: leeg de follows-wachtrij en er vallen er
vier om. Suite 556/556.

File:

• test/guardian-follow-queues.test.js (added)