Changeset 86e6a45 in Klonkt for src/services/ActivityPubService.js

Timestamp:

08/08/2026 07:24:44 AM (5 weeks ago)

Author:

roboburr <roboburr@…>

Branches:

main

Children:

a9ede28

Parents:

0b0cd54

git-author:

Robin <roboburr@…> (08/08/2026 07:24:42 AM)

git-committer:

roboburr <roboburr@…> (08/08/2026 07:24:44 AM)

Message:

De apps krijgen de hulpstaat, en kunnen afhandelen (shaer-lgo)

Barts melding: afgehandelde hulpverzoeken blijven zichtbaar in de Shaer
GuardianshipView, en kan het afhandelen daar ook?

DIE TWEE ZIJN HETZELFDE PROBLEEM. De apps lazen hulpvragen uit de FEED -- losse
notes met een helpRequest-vlag -- en kregen de staat helemaal niet. Ze konden dus
niet weten of er al iemand op af was, en dan is een afgehandeld verzoek laten
staan nog het eerlijkste dat een app kan doen. Klonkt bewaarde de staat wel; hij
reisde alleen nergens heen.

Nu een queue help op de actor, met de staat PLAT erin: open, wie hem oppakte,
wie hem afsloot en wanneer. Een app hoeft hem niet af te leiden en kan hem dus
ook niet anders afleiden dan het paneel -- helpItemsFor is een plek, net als
wardGates. Twee berekeningen zouden twee guardians een ander beeld geven van
hetzelfde kind, en bij een reddingsboei is dat het gevaarlijkste dat er mis kan
gaan.

AFHANDELEN HOEFDE GEEN NIEUWE VORM. De markering IS al een gewone directe note
met shaer:helpPickup of shaer:helpHandled, precies zoals de zwaai. De outbox
herkent hem nu, dus de app stuurt letterlijk wat de PWA stuurt en het reist over
dezelfde bezorging naar de mede-guardians. Geen tweede weg.

Wel LOKAAL boeken, en daar staat een toets op: zonder dat zag de guardian die de
knop indrukt zijn eigen markering pas als hij bij zichzelf terugkwam, en die weg
bestaat niet.

Oppikken blijft OPEN. De faalstand hier is "iedereen denkt dat het geregeld is",
en die is gevaarlijker dan geen markering.

De AS2-toets ving dat help nog niet gedeclareerd stond op de actor -- precies
waarvoor die toets er is. Suite 718/718; zonder de lokale boeking valt er een om.

File:

• src/services/ActivityPubService.js (modified) (1 diff)

src/services/ActivityPubService.js

@@ -3344 +3344 @@
           }
           const gateReq = Guardianship.gatereq.parseRequest(object);
-          const r = await deliverDirectNote(site, { recipients, text: plain, language: object.language || null, inReplyTo: typeof object.inReplyTo === 'string' ? object.inReplyTo : null, attachments: atts, helpRequest: help, awayUntil, gateRequest: gateReq && gateReq.feature });
+          // Een hulpvraag oppikken of afsluiten vanuit de app (5.2.1, shaer-lgo).
+          // De markering IS al een gewone directe note met een shaer:-eigenschap,
+          // dus hier hoeft niets nieuws bij: de app stuurt precies wat de PWA
+          // stuurt, en het gaat over dezelfde bezorging naar de mede-guardians.
+          //
+          // We boeken hem ook LOKAAL. Zonder dat zou de guardian die de knop
+          // indrukt zijn eigen markering pas zien als hij bij zichzelf
+          // terugkomt -- en die weg bestaat niet.
+          const mark = Guardianship.help.parseMarker(object);
+          if (mark) {
+            const base2 = (process.env.PUBLIC_BASE_URL || '').replace(/\/+$/, '');
+            Guardianship.help.record(mark.noteUri, actorId(base2, site.slug), mark.kind, `@${site.slug}`);
+          }
+          const r = await deliverDirectNote(site, { recipients, text: plain, language: object.language || null, inReplyTo: typeof object.inReplyTo === 'string' ? object.inReplyTo : null, attachments: atts, helpRequest: help, awayUntil, gateRequest: gateReq && gateReq.feature, helpMark: mark });
           if (!r || !r.id) return { status: 502, error: 'direct_failed' };
           return { status: 201, id: r.id, url: `${base}/ap/notes/${r.id}` };