Changeset 6d7ea52 in Klonkt for src/services/ap-inbox.js

Timestamp:

09/04/2026 12:40:22 PM (4 days ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

21cebed

Parents:

1d1fdc9

Message:

De noodknop is niet meer door een vreemde uit te zetten (shaer-gt70)

De markering op een hulpvraag werd van IEDEREEN aangenomen: de enige
voorwaarde was dat de actor niet lokaal is. Ondertekening zegt WIE, niet
of het MAG, en die tweede laag stond er niet. Afgehandeld kent geen
terugdraai en de vraag verdwijnt daarna uit de teller van elke guardian,
dus elke ondertekende actor die de URI kende kon de noodknop van een kind
uitzetten.

DE WARD IS DE BRON VAN WAARHEID over wie zijn guardians zijn -- onze
eigen tabel kent alleen onze relatie. existingGuardiansOf stelt die vraag
op de goede plek: lokaal als wij de ward hosten, anders shaer:guardians
van zijn actor. En WELKE ward erbij hoort komt uit onze eigen
administratie (de hulpvraag zoals wij hem opsloegen), nooit uit wat de
afzender beweert. Kennen we die hulpvraag niet, dan is er niets te
markeren.

Met een cache van vijf minuten, want het remote geval is een
netwerkaanroep in het inbox-pad -- zonder cache is dat een manier om onze
inbox te laten wachten. Een MISLUKTE ophaal wordt niet als lege lijst
onthouden: dan zou een tijdelijk onbereikbare server vijf minuten lang
elke markering weigeren.

TWEEDE VONDST, gemeten tijdens het bouwen: dezelfde regels riepen
wakeGuardian(slug) aan met een slug die in die scope niet bestaat. De
markering werd dus vastgelegd en daarna gooide de handler een
ReferenceError -- het paneel hoorde het nooit en de rest van de
verwerking van die activiteit viel weg. Nu wakeGuardian(vraag.slug): het
paneel dat de hulpvraag houdt. slugParam zou ook fout zijn, want die is
null op de gedeelde inbox.

Vijf toetsen, tegenbewijs tegen de code van hiervoor: daar vallen ze alle
vijf. Volle suite 1260 groen.

File:

• src/services/ap-inbox.js (modified) (2 diffs)

src/services/ap-inbox.js

@@ -138 +138 @@
   try { return !!db.prepare('SELECT 1 FROM ap_following WHERE actor_uri = ? LIMIT 1').get(uri); } catch { return false; }
 };
+
+/**
+ * De hulpvraag zoals WIJ hem opsloegen (shaer-gt70).
+ *
+ * Een markering wijst naar een note-URI, en die komt van de afzender. Welke
+ * ward erbij hoort mag daarom niet uit die markering komen maar uit onze eigen
+ * rij: de hulpvraag kwam hier binnen als directe vermelding met help_request=1,
+ * en `actor_uri` daarvan IS de ward.
+ *
+ * Geen rij, geen markering. Dat sluit meteen de aardigste variant af: iemand
+ * die markeringen stuurt voor hulpvragen die hij ergens anders zag.
+ */
+function helpRequestRow(noteUri) {
+  if (!noteUri || typeof noteUri !== 'string') return null;
+  try {
+    return db.prepare('SELECT slug, actor_uri FROM ap_mentions WHERE object_uri = ? AND help_request = 1 LIMIT 1').get(noteUri) || null;
+  } catch { return null; }
+}
+
+/**
+ * Is deze actor guardian van deze ward?
+ *
+ * De WARD is de bron van waarheid over zijn eigen guardians -- onze tabel kent
+ * alleen onze eigen relatie. existingGuardiansOf stelt de vraag op de goede
+ * plek: hosten wij de ward, dan is het een databaselezing; woont hij elders,
+ * dan komt het uit shaer:guardians op zijn actor.
+ *
+ * MET EEN CACHE, want dat tweede geval is een netwerkaanroep in het inbox-pad.
+ * Zonder zou een vreemde onze inbox kunnen laten wachten door markeringen te
+ * blijven sturen. De lokale tak raakt de cache ook, en dat kost daar niets.
+ *
+ * Vijf minuten is kort genoeg dat een verse guardian niet lang buiten staat, en
+ * lang genoeg om herhaald bevragen te dempen. Een geweigerde markering is niet
+ * verloren: de andere kant levert opnieuw af, en dan is de cache ververst.
+ */
+const _guardiansOfWard = new Map();   // ward-uri -> { at, set }
+const GUARDIAN_CACHE_MS = 5 * 60 * 1000;
+async function isGuardianOfWard(actorUri, wardUri) {
+  if (!actorUri || !wardUri) return false;
+  const nu = Date.now();
+  const gecached = _guardiansOfWard.get(wardUri);
+  if (gecached && nu - gecached.at < GUARDIAN_CACHE_MS) return gecached.set.has(actorUri);
+  let lijst = [];
+  try { lijst = await Guardianship.existingGuardiansOf(wardUri); } catch { lijst = []; }
+  // Een MISLUKTE ophaal niet als lege lijst wegschrijven: dan zou een tijdelijk
+  // onbereikbare server vijf minuten lang elke markering weigeren. Bij twijfel
+  // niets onthouden en de volgende keer opnieuw kijken.
+  if (Array.isArray(lijst) && lijst.length) {
+    if (_guardiansOfWard.size > 500) _guardiansOfWard.clear();   // simpele begrenzing
+    _guardiansOfWard.set(wardUri, { at: nu, set: new Set(lijst) });
+  }
+  return Array.isArray(lijst) && lijst.includes(actorUri);
+}
 
 // Mislukte dereferences kort onthouden. Mastodon herhaalt een bezorging
@@ -687 +740 @@
       const mark = Guardianship.help.parseMarker(o);
       if (mark) {
-        const ai = actorInfo(await resolveActor(actorUri).catch(() => null), actorUri);
-        Guardianship.help.record(mark.noteUri, actorUri, mark.kind, ai && ai.handle);
-        wakeGuardian(slug);   // een mede-guardian pakte iets op: het paneel hoort het meteen
-        console.log('[AP] help', mark.kind, actorUri, '→', mark.noteUri);
+        // WIE MAG DIT (shaer-gt70). Hier stond alleen "de actor is niet lokaal",
+        // en dat is geen poort: elke ondertekende actor die de URI van een
+        // hulpvraag kende kon hem op 'handled' zetten. Afgehandeld kent geen
+        // terugdraai en de vraag verdwijnt daarna uit de teller van ELKE
+        // guardian -- een vreemde kon dus de noodknop van een kind uitzetten.
+        //
+        // Ondertekening zegt WIE, niet OF HET MAG. Die tweede laag stond er niet.
+        //
+        // DE WARD IS DE BRON VAN WAARHEID over wie zijn guardians zijn; onze
+        // eigen tabel kent alleen ONZE relatie. existingGuardiansOf stelt die
+        // vraag op de goede plek: lokaal opzoeken als wij de ward hosten,
+        // anders shaer:guardians van zijn actor.
+        //
+        // En WELKE ward dat is komt uit onze EIGEN administratie -- de
+        // hulpvraag zoals wij hem opsloegen -- nooit uit wat de afzender
+        // beweert. Kennen we die hulpvraag niet, dan is er niets te markeren.
+        const vraag = helpRequestRow(mark.noteUri);
+        if (!vraag) {
+          console.warn('[AP] help-markering voor een onbekende hulpvraag, genegeerd:', actorUri, '→', mark.noteUri);
+        } else if (!(await isGuardianOfWard(actorUri, vraag.actor_uri))) {
+          console.warn('[AP] help-markering van iemand die geen guardian van deze ward is, geweigerd:', actorUri, '→', mark.noteUri);
+        } else {
+          const ai = actorInfo(await resolveActor(actorUri).catch(() => null), actorUri);
+          Guardianship.help.record(mark.noteUri, actorUri, mark.kind, ai && ai.handle);
+          // Het paneel dat de hulpvraag HOUDT wordt gewekt, en dat is
+          // `vraag.slug`. Hier stond `slug`, en die bestaat in deze scope niet:
+          // de markering werd vastgelegd en daarna gooide de handler een
+          // ReferenceError, dus het paneel hoorde het nooit en de rest van de
+          // verwerking van deze activiteit viel weg. Gemeten, niet geredeneerd.
+          // slugParam zou hier ook fout zijn: op de gedeelde inbox is die null.
+          wakeGuardian(vraag.slug);   // een mede-guardian pakte iets op: het paneel hoort het meteen
+          console.log('[AP] help', mark.kind, actorUri, '→', mark.noteUri);
+        }
       }
     }