Changeset fcd6964 in Klonkt for src/routes

Timestamp:

07/24/2026 08:59:51 PM (7 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

c6185fa

Parents:

3ffbedd

Message:

Guardianship: ward ziet z'n guardians, PWA-assets no-cache, handle-fix

De handshake commit werkte al aan beide kanten (geverifieerd live: sound-fabrics
ziet beta als ward, beta weet dat sound-fabrics guardian is), maar het TONEN
ontbrak op drie plekken. Dit lost de Klonkt-kant op.

1. Ward-kant: in Berichten ziet een ward nu wie z'n guardians zijn (committed relaties, FEP-633c §2). Die view bestond nog niet.
2. other_handle bewaarde per ongeluk de FEP-escalatiehandle (candidate/inbox) i.p.v. de @handle, dus overal waar we het toonden kwam een inbox-URL uit. Nu de echte @handle uit de offer; display self-healt oude rijen door @user@host uit de actor-URI af te leiden als de opgeslagen handle geen @ is.
3. Guardian PWA-assets via /guardian/app.js|css met Cache-Control: no-cache, dus een update wordt nooit meer gemaskeerd door de 1-jaar /assets-cache of een vastgelopen install (dat was de "niks werkt na deploy"-bug). Client zit nu in try/catch met een zichtbare foutbanner i.p.v. stil te hangen.

Changed files:
src/services/guardianship/handshake.js

• applyCommitLocally schrijft de @handle (offer.ward/candidate_handle) naar other_handle

src/routes/posts.js

• messages-route levert myGuardians (committed guardians met afgeleide @handle)

src/views/pages/messages.ejs

• "Jouw guardians"-sectie voor de ward

src/services/i18n.js

• msg.guardians_label (nl/en/de)

src/routes/guardian.js

• /guardian/app.js|css no-cache; ASSET_V-mtime-machinerie weg

src/assets/js/guardian.js

• hele client in try/catch met zichtbare foutbanner; handleOf vertrouwt alleen echte @handles

src/views/pages/guardian.ejs

• assets via no-cache routes i.p.v. /assets?v=

test/guardianship.test.js

• assert dat other_handle de @handle is na commit

remarks: getest met npm test (6/6). sound-fabrics (stable-lane, handmatig) bewust
niet aangeraakt; wacht op akkoord.

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

Location:

src/routes

Files:

• guardian.js (modified) (4 diffs)
• posts.js (modified) (1 diff)

src/routes/guardian.js

@@ -10 +10 @@
  */
 import express from 'express';
-import fs from 'fs';
 import path from 'path';
 import { fileURLToPath } from 'url';
@@ -20 +19 @@
 
 const router = express.Router();
-
-// Cache-bust the PWA assets: /assets is served with a 1-year cache, so without
-// a per-build version the browser keeps running an old guardian.js/css after a
-// deploy (that was exactly the "no feedback / not arriving" bug). The version
-// is the file's mtime at process start; a redeploy restarts us and bumps it.
 const __dir = path.dirname(fileURLToPath(import.meta.url));
-function assetVersion(rel) {
-  try { return Math.floor(fs.statSync(path.join(__dir, '..', 'assets', rel)).mtimeMs).toString(36); }
-  catch { return '0'; }
-}
-const ASSET_V = { js: assetVersion('js/guardian.js'), css: assetVersion('css/guardian.css') };
 
 /** The acting site: ?site=slug when owned, else the user's first site. */
@@ -78 +67 @@
     sites,
     lang: L,
-    assetV: ASSET_V,
     t: (k, v) => i18nT(L, k, v),
     cspNonce: res.locals.cspNonce,
@@ -125 +113 @@
   res.json({ ok: true, committed: !!r.committed, readyToCommit: !!r.readyToCommit });
 });
+
+// ── PWA assets served no-cache, so an update is never masked by the 1-year
+//    /assets cache or a stuck install (that was the whole "nothing works after
+//    a deploy" bug). Small files; the browser revalidates and gets a 304 when
+//    unchanged, the fresh file when changed.
+function pwaAsset(rel, type) {
+  return (req, res) => {
+    res.set('Cache-Control', 'no-cache');
+    res.type(type);
+    res.sendFile(path.join(__dir, '..', 'assets', rel));
+  };
+}
+router.get('/app.js', pwaAsset('js/guardian.js', 'application/javascript'));
+router.get('/app.css', pwaAsset('css/guardian.css', 'text/css'));
 
 // ── Manage: release a committed ward (local Undo; federation is Fase 4). ──

src/routes/posts.js

@@ -939 +939 @@
     ? Guardianship.offersCollection(`${gMe}/queues/offers`, site.slug, gMe).orderedItems
     : []).filter((o) => o['shaer:ward'] === gMe && o['shaer:needsMyAccept']);
+  // FEP-633c §2: who guards this account (committed). Shown so a ward can always
+  // see its guardians, not just pending offers. Derive a display @handle when the
+  // stored one is missing or is the escalation (inbox) handle rather than a @handle.
+  const guardianHandle = (uri, cached) => {
+    if (cached && cached.charAt(0) === '@') return cached;
+    try { const u = new URL(uri); return `@${u.pathname.split('/').filter(Boolean).pop()}@${u.host}`; }
+    catch { return uri; }
+  };
+  const myGuardians = (site ? Guardianship.listGuardians(site.slug) : [])
+    .map((g) => ({ uri: g.other_uri, handle: guardianHandle(g.other_uri, g.other_handle) }));
   renderPage(req, res, 'pages/messages', {
     pageTitleKey: 'msg.title', bodyClass: 'on-special', items, seenAt,
-    hasMore, nextOffset: offset + FEED_PAGE, moreBase, guardianOffers,
+    hasMore, nextOffset: offset + FEED_PAGE, moreBase, guardianOffers, myGuardians,
     success: req.query.success || null, error: req.query.error || null,
   });