Changeset 2365630 in Klonkt for src/services/ActivityPubService.js

Timestamp:

08/14/2026 12:32:25 AM (4 weeks ago)

Author:

roboburr <roboburr@…>

Branches:

main

Children:

5a49eba

Parents:

919b82d

git-author:

Robin <roboburr@…> (08/14/2026 12:31:37 AM)

git-committer:

roboburr <roboburr@…> (08/14/2026 12:32:25 AM)

Message:

Een stempel in een vorm, anders sorteert een gesprek op schrijfwijze

Bart, 14-8: in Berichten stond een bericht van 00:30 boven een antwoord van
20:22 de avond ervoor -- op iOS en op Android allebei, en dat wees al naar hier
in plaats van naar de clients.

De unie achter een gesprek haalde haar stempel uit twee bronnen met een andere
VORM. SQLite's CURRENT_TIMESTAMP schrijft '2026-08-13 22:30:12', een binnenkomend
object draagt '2026-08-13T20:22:00Z', en soms met milliseconden erbij. Alle drie
tekst, dus vergeleken als tekst -- en op plek 10 staat een spatie tegen een T.
Een spatie is kleiner, dus sorteerde binnen dezelfde dag ALLES wat jij stuurde
vóór alles wat binnenkwam, hoe laat het ook was.

Barts eigen geval precies: 00:30 lokaal is 22:30 UTC op de 13e, en dat kwam
daarmee vóór een antwoord van 20:22Z.

strftime leest alle drie en geeft er een vorm voor terug, in UTC. Lukt dat niet,
dan blijft de rauwe waarde staan: dan is die ene rij verkeerd gesorteerd in
plaats van de hele lijst.

Dit ging ook de clients aan zonder dat iemand het zag. new Date('2026-08-13
22:30:12') leest in JavaScript als LOKALE tijd en de T-Z-vorm als UTC -- dezelfde
rij gaf dus een leeftijd die uren verschilde per vorm, en daar hangt in de hemel
de afstand tot het midden aan.

De toetsen hierboven gebruikten overal dezelfde ISO-vorm en konden hier dus niet
op falen. De drie nieuwe zetten de vormen door elkaar zoals de echte database
dat doet, op een eigen site zodat ze de tellingen van de andere niet verstoren.
Nagegaan dat ze ook echt kunnen falen: met de normalisering eruit vallen ze
alle drie om.

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

File:

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

src/services/ActivityPubService.js

@@ -4421 +4421 @@
 // visibility 'direct'. Een publiek antwoord is geen gesprek en hoort niet als
 // gezicht in de hemel.
+/**
+ * EEN STEMPEL IN EEN VORM, en dat is hier geen netheid maar de volgorde zelf.
+ *
+ * Drie vormen kwamen samen in deze unie: `2026-08-13 19:26:17` van SQLite's
+ * CURRENT_TIMESTAMP, `2026-08-13T18:21:57Z` uit een object, en dezelfde met
+ * milliseconden. Als TEKST vergeleken staat op plek 10 een spatie tegen een
+ * T -- en een spatie is kleiner. Dus sorteerde binnen dezelfde dag alles wat
+ * JIJ stuurde vóór alles wat binnenkwam, ongeacht de klok (Barts melding 14-8:
+ * een bericht van 00:30 stond boven een antwoord van 20:22 de avond ervoor).
+ *
+ * strftime leest alle drie en geeft er een vorm voor terug, in UTC. Lukt het
+ * niet, dan blijft de rauwe waarde staan -- dan is die ene rij verkeerd
+ * gesorteerd in plaats van de hele lijst.
+ *
+ * Dit gaat ook de client aan: `new Date('2026-08-13 19:26:17')` leest in
+ * JavaScript als LOKALE tijd en `...T19:26:17Z` als UTC. Dezelfde rij gaf dus
+ * een leeftijd die twee uur verschilde per vorm.
+ */
+const STEMPEL = (rauw) => `COALESCE(strftime('%Y-%m-%dT%H:%M:%SZ', ${rauw}), ${rauw})`;
+
 const CONVERSATION_UNION = `
-  SELECT m.actor_uri AS other, COALESCE(m.published, m.created_at) AS stamp,
+  SELECT m.actor_uri AS other, ${STEMPEL('COALESCE(m.published, m.created_at)')} AS stamp,
          'in' AS direction, m.object_uri AS ref
     FROM ap_mentions m
    WHERE m.slug = @slug AND m.actor_uri IS NOT NULL AND m.actor_uri <> ''
   UNION ALL
-  SELECT j.value AS other, o.created_at AS stamp,
+  SELECT j.value AS other, ${STEMPEL('o.created_at')} AS stamp,
          'out' AS direction, o.id AS ref
     FROM ap_outbox o