Changeset 4f322bc in Klonkt for src/services/ActivityPubService.js

Timestamp:

08/07/2026 08:49:58 AM (5 weeks ago)

Author:

roboburr <roboburr@…>

Branches:

main

Children:

a6d703a

Parents:

5861849

git-author:

Robin <roboburr@…> (08/07/2026 08:49:56 AM)

git-committer:

roboburr <roboburr@…> (08/07/2026 08:49:58 AM)

Message:

Wachten op nieuws, als uitbreiding van de inbox (shaer-n05)

Geen tweede endpoint. Geef since (de shaer:cursor uit je vorige antwoord) en
wait mee aan de bestaande inbox-lezing, en het antwoord blijft hangen tot er
iets is of de tijd om is. Zonder die twee gedraagt de route zich exact zoals
altijd.

Bewust hetzelfde antwoord in plaats van een 'er is nieuws'-seintje: dan hoeft de
client niets nieuws te parsen, is er geen tweede beschrijving van de kaartvorm
die uit de pas kan lopen met de eerste, en scheelt het een tweede ronde.

De merksteen telt ALLE VIER de poten die de inbox samenvoegt: tijdlijn,
berichten, antwoorden op je eigen posts, en wat je zelf verstuurde. Ontbreekt er
een, dan blijft een wachtende client slapen terwijl er wel degelijk nieuws is --
erger dan niet wachten, want het lijkt te werken. rowid en geen tijdstempel: die
loopt strikt op, terwijl twee dingen in dezelfde seconde kunnen aankomen en een
published van een andere server niet te vertrouwen is.

Wachten gebeurt met een interne tik en niet met een gebeurtenis-emitter. Een
emitter moet op ELKE plek worden aangeroepen waar er iets bijkomt, en de plek die
je vergeet is precies de melding die nooit aankomt. Vier MAX(rowid)-queries per
seconde is niets, en dit kan niets missen. Prijs: hooguit een tik vertraging.

Grenzen: hooguit 50 seconden wachten (ruim onder wat een proxy toestaat), vier
gelijktijdige wachters per account, en ophangen breekt het wachten af. Een client
met een kapotte herverbind-lus krijgt gewoon de huidige stand in plaats van een
fout.

9 tests, waaronder de vier poten apart en de vraag of hij wakker wordt in plaats
van de tijd vol te maken. Suite 537/537.

File:

• src/services/ActivityPubService.js (modified) (2 diffs)

src/services/ActivityPubService.js

@@ -3485 +3485 @@
 }
 
+/**
+ * Een merk voor "is er iets veranderd aan wat de inbox-lezing zou opleveren?"
+ * (shaer-n05).
+ *
+ * Alle VIER de poten die de inbox samenvoegt tellen mee -- tijdlijn, berichten,
+ * antwoorden op je eigen posts, en wat je zelf verstuurde. Zou er een ontbreken,
+ * dan blijft een wachtende client slapen terwijl er wel degelijk iets is
+ * bijgekomen, en dat is erger dan niet wachten: het lijkt te werken.
+ *
+ * rowid en niet een tijdstempel: rowid loopt strikt op per invoeging, terwijl
+ * twee dingen in dezelfde seconde kunnen aankomen en een `published` van een
+ * andere server niet te vertrouwen is.
+ *
+ * Ondoorzichtig voor de client. Hij krijgt hem terug en geeft hem ongewijzigd
+ * mee; de vorm mag veranderen zonder dat dat iets breekt.
+ */
+export function feedCursor(slug) {
+  const max = (sql, ...args) => { try { const r = db.prepare(sql).get(...args); return (r && r.n) || 0; } catch { return 0; } };
+  const t = max('SELECT MAX(rowid) AS n FROM ap_timeline WHERE slug = ?', slug);
+  const m = max('SELECT MAX(rowid) AS n FROM ap_mentions WHERE slug = ?', slug);
+  const o = max('SELECT MAX(rowid) AS n FROM ap_outbox WHERE site_slug = ?', slug);
+  const r = max(`SELECT MAX(i.rowid) AS n FROM ap_interactions i
+                   JOIN posts p ON p.id = i.post_id
+                   JOIN sites s ON s.id = p.site_id
+                  WHERE s.slug = ? AND i.kind = 'reply'`, slug);
+  return `${t}.${m}.${o}.${r}`;
+}
+
+// Zoveel clients mogen er tegelijk op EEN account staan wachten. Een client met
+// een kapotte herverbind-lus mag de instance niet vastzetten; de overtolligen
+// krijgen gewoon meteen antwoord in plaats van een fout.
+const FEED_WAIT_MAX = 4;
+const _wachters = new Map();
+
+/**
+ * Wacht tot de inbox-lezing iets anders zou opleveren dan bij `since`.
+ *
+ * Bewust met een interne tik en niet met een gebeurtenis-emitter. Een emitter
+ * moet op ELKE plek worden aangeroepen waar er iets bijkomt, en de plek die je
+ * vergeet is precies de melding die nooit aankomt. Twee tot vier MAX(rowid)-
+ * queries per seconde is niets, en dit kan niets missen. Prijs: hooguit een tik
+ * vertraging.
+ */
+export async function waitForFeedChange(slug, opts = {}) {
+  const tickMs = Math.max(50, opts.tickMs || 1000);
+  const waitMs = Math.max(0, opts.waitMs || 0);
+  const since = String(opts.since || '');
+  let cursor = feedCursor(slug);
+  // Geen sinds, al iets veranderd, of niet willen wachten: meteen antwoorden.
+  if (!since || since !== cursor || !waitMs) return { cursor, changed: !!since && since !== cursor, waited: false };
+
+  const bezet = _wachters.get(slug) || 0;
+  if (bezet >= FEED_WAIT_MAX) return { cursor, changed: false, waited: false, busy: true };
+  _wachters.set(slug, bezet + 1);
+  try {
+    const einde = Date.now() + waitMs;
+    while (Date.now() < einde) {
+      if (opts.signal && opts.signal.aborted) break;   // client hing op
+      const rest = Math.min(tickMs, einde - Date.now());
+      await new Promise((r) => setTimeout(r, rest));
+      cursor = feedCursor(slug);
+      if (cursor !== since) return { cursor, changed: true, waited: true };
+    }
+    return { cursor, changed: false, waited: true };
+  } finally {
+    const n = (_wachters.get(slug) || 1) - 1;
+    if (n > 0) _wachters.set(slug, n); else _wachters.delete(slug);
+  }
+}
+
 export function getDirectMessages(slug, limit) {
   try {
@@ -5254 +5324 @@
   buildActor, buildNote, buildCreate, buildOutbox, buildFollowers, buildFollowing, buildFeatured,
   followerCount, deliver, fetchActor, verifyRequest, handleInbox, deliverCreate, deliverDelete, deliverUpdate, deliverActorUpdate, resyncFeaturedPins,
+  feedCursor, waitForFeedChange,
   getInteractions, getInteractionById, setInteractionBoosted, setInteractionLiked, buildReplyNote, getOutboxNote, getSentNotes, deliverReply, resolveRemoteNote, noteAudience, mayReadNote,
   listOutbox, deliverOutboxDelete, deliverOutboxUpdate, deliverDirectNote,