Changeset 6d5ce0c in Klonkt for src/services/guardianship/delivery.js

Timestamp:

07/29/2026 10:50:32 AM (6 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

08ab8ad

Parents:

c8e03c6

Message:

Op deze machine gedraagt elke Klonkt zich alsof hij ergens anders staat

Robins regel, en de reden staat in de logs van deze week. Twee bugs kwamen uit
hetzelfde patroon: een tweede, lokale route die een kapotte externe route
verborg. De Undo bereikte een kind op dezelfde machine nooit, en het gated
voorstel was een maand stuk over de lijn terwijl de sluiproute de stem hier
direct opschreef en het dashboard er prima uitzag.

Samenlokatie is nu een kwestie van TRANSPORT, geen beslispad. deliverToActor
geeft een activiteit voor een lokale ontvanger door aan dezelfde inbox-handler
die de lijn zou bereiken, inclusief de controle of de ondertekenaar de afzender
is. Alles daarboven weet het verschil niet meer, en dus draait elke deployment
dezelfde code.

Directe berichten deden dat nog niet. Die zochten een inbox op en POSTten
erheen, dus een bericht aan een kind op deze machine ging naar onze eigen
hostnaam en terug, of nergens heen. Nu nemen ze dezelfde loopback.

En de kern van het probleem zat in de inbox zelf: "van onze eigen actor" werd
gelezen als "van wie dan ook op deze machine". Daardoor werd elk bericht tussen
twee sites op een instantie met een 202 aangenomen en daarna weggegooid: geen
vermelding, geen afwezigheid, geen hulpvraag. Buren zijn niet wij.

Daarmee konden twee met de hand geschreven sluiproutes weg: het lokaal
wegschrijven van een afwezigheid in de C2S-outbox en in de Guardian PWA. Die
bestonden alleen omdat de echte weg niet aankwam.

Changed files:
src/services/ActivityPubService.js

• isLocalActor is nu "de eigenaar van deze inbox", niet "iemand op deze host"
• localActor(): het actordocument van een site die wij hosten, uit onze eigen database in plaats van via een verzoek aan onszelf
• de lokale sluiproute voor afwezigheid in de C2S-outbox is weg

src/services/guardianship/delivery.js

• een lokale ontvanger krijgt het bericht via de loopback, de rest per inbox
• een lokale ontvanger wordt lokaal opgezocht, dus hij valt niet stilletjes uit de ontvangerslijst als het verzoek aan onszelf mislukt

src/routes/guardian.js

• /api/away schrijft niets meer zelf weg: het bericht doet het werk

src/services/guardianship/handshake.js

• commentaar bijgewerkt bij de plekken die wel lokaal mogen schrijven

New file:
test/co-location.test.js

• hetzelfde scenario twee keer, alles-lokaal en alles-extern, met de eis dat de eindtoestand gelijk is
• een afwezigheid via de loopback en dezelfde brief van de lijn gelezen
• de loopback weigert nog steeds een afzender die niet klopt
• een bewaking die faalt zodra er een nieuwe lokale sluiproute in een beslispad verschijnt, met de legitieme uitzonderingen bij naam

remarks: 329 tests groen, en de server start. Twee dingen om te weten voor de
uitrol: sites op een instantie die elkaar volgen zien elkaars berichten nu wel
(dat is wat volgen betekent, maar het is zichtbaar anders), en gated follows
lopen voor een lokale guardian nog steeds via de gedeelde database. Die laatste
staat met naam en toenaam in de bewakingstest, zodat hij niet vergeten wordt.

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

File:

• src/services/guardianship/delivery.js (modified) (3 diffs)

src/services/guardianship/delivery.js

@@ -41 +41 @@
 // call-for-help path).
 export async function deliverDirectNote(site, { recipients, text, language, inReplyTo, attachments, helpRequest, wave, awayUntil }) {
-  const { actorId, fetchActor, deriveHandle, escHtml, linkUrls, linkHashtags,
+  const { actorId, fetchActor, localActor, deliverTo, deriveHandle, escHtml, linkUrls, linkHashtags,
           getOutboxRow, buildReplyNote, AP_CONTEXT, getOrCreateKeys, deliver, enqueueDelivery } = deps;
   const base = (process.env.PUBLIC_BASE_URL || '').replace(/\/+$/, '');
@@ -50 +50 @@
   const resolved = [];
   for (const uri of list) {
-    const a = await fetchActor(uri).catch(() => null);
+    // An actor we host is read from our own database, not fetched from our own
+    // hostname: that request has to leave the machine and come back, and when
+    // it does not, the recipient is silently dropped from the note. Everything
+    // that decides anything still runs below, for local and remote alike.
+    const a = (localActor && localActor(uri)) || await fetchActor(uri).catch(() => null);
     if (!a || !(a.inbox || (a.endpoints && a.endpoints.sharedInbox))) continue;
-    resolved.push({ uri, inbox: (a.endpoints && a.endpoints.sharedInbox) || a.inbox, handle: deriveHandle(uri), url: a.url || uri });
+    resolved.push({ uri, inbox: (a.endpoints && a.endpoints.sharedInbox) || a.inbox, local: !!a.local, handle: deriveHandle(uri), url: a.url || uri });
   }
   if (!resolved.length) return null;
@@ -83 +87 @@
   const keyId = `${me}#main-key`;
   let delivered = 0;
-  for (const inbox of [...new Set(resolved.map((r) => r.inbox))]) {
+  // A recipient on this machine takes the loopback (deliverToActor), which
+  // hands the Create to the same inbox handler an HTTP POST would reach: the
+  // note is stored, the mention is stored, and a shaer:away on it is applied,
+  // all by the code that does it for everyone else. A hairpin POST to our own
+  // hostname is not that code path, it is a second one that only appears to be.
+  for (const r of resolved.filter((x) => x.local)) {
+    const res = await deliverTo(site, r.uri, create).catch(() => null);
+    if (res && res.delivered) delivered++;
+  }
+  // Remote: one POST per inbox, so two guardians on the same server share it.
+  for (const inbox of [...new Set(resolved.filter((x) => !x.local).map((r) => r.inbox))]) {
     let ok = false;
     try { const st = await deliver(inbox, create, keyId, keys.private_pem); ok = st >= 200 && st < 300; } catch { ok = false; }