source: Klonkt/src/services/guardianship/queues.js@ 709dc6f

main
Last change on this file since 709dc6f was 709dc6f, checked in by Bart <bart@…>, 4 weeks ago

Twee richtingen, twee poorten: shaer:following naast shaer:follows

In de catalogus stond één rij voor twee mechanismen. Het paneel telde
listReviewsByDirection(slug, 'incoming') en zette dat getal onder
shaer:follows, dus een guardian las "3 wachtend" en wist niet of er drie
vreemden bij zijn kind wilden of dat zijn kind drie keer had gevraagd of het
iemand mocht volgen. Dat zijn niet dezelfde zorg, en sinds shaer-p729 bestaan
ze allebei echt.

Nu twee poorten, en het verschil ertussen is opzet. §5.3 EIST dat een Follow
naar een ward langs de guardians gaat: shaer:follows blijft dus fixed. Over de
andere richting zegt de FEP niets — wat je verder gated is expliciet aan de
implementatie gelaten — dus shaer:following is onze keuze, en dan hoort hij ook
echt losgelaten te kunnen worden. Verstelbaar, met gate_following als kolom en
dezelfde automatiek als de rest: onbeslist is dicht voor een ward en open voor
ieder ander. Een kind dat erin groeit hoeft niet eeuwig te blijven vragen.

Geen eigen ownFollowsAllowed(): wardGateAllowed() is er al en zegt er zelf bij
dat het één implementatie hoort te zijn. Een derde kopie zou precies de tweede
plek zijn die er anders over kan gaan denken.

De labels zijn nog aan de clients: de server geeft de feature-naam door, de
Guardian PWA en Shaer moeten er nog woorden bij kiezen.

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

  • Property mode set to 100644
File size: 13.3 KB
Line 
1/**
2 * Guardianship (FEP-633c) — the owner-only dashboard queues.
3 *
4 * Three OrderedCollections on the actor (shaer:queues), same contract as the
5 * Shaer test daemon so the iOS/Android dashboards read them as-is:
6 * - offers: pending handshake offers where I am a party (§3), with the full
7 * accept tally so the client shows the right action
8 * - follows: pending gated follows ON my wards (§5.3), Fase 2 (shaer-jdb)
9 * - wards: my committed wards
10 */
11import * as offers from './offers.js';
12import * as relations from './relations.js';
13import * as availability from './availability.js';
14import * as outgoing from './outgoing.js';
15import * as follows from './follows.js';
16import * as gated from './gated.js';
17import * as gatereq from './gatereq.js';
18import * as help from './help.js';
19import db from '../../config/database.js';
20import * as handshake from './handshake.js';
21
22const collection = (id, items) => ({
23 id, type: 'OrderedCollection', totalItems: items.length, orderedItems: items,
24});
25
26/** Pending offers where the local site is a party, each with its accept
27 * tally. The same collection carries the running lapses (§3.6.3) this
28 * account is a party to, exactly as the daemon serves them, so the Shaer
29 * clients render both without a second fetch. */
30export function offersCollection(id, slug, me) {
31 // §4.2: a handshake whose candidate could not be dereferenced is deferred,
32 // not decided, and the last Accept may already have landed — so nothing else
33 // would ever retry it. This poll is the schedule. Not awaited: the read
34 // answers with what is true now, and a retry that succeeds surfaces in the
35 // next one. `listForParty` settles closed windows on the way past.
36 handshake.retryDeferred(slug).catch(() => { /* the next read tries again */ });
37 const items = offers.listForParty(slug, me).map((o) => offers.queueItem(o, me));
38 items.push(...availability.lapseQueueItems(slug, me, Date.now()));
39 return collection(id, items);
40}
41
42/**
43 * Gate-verzoeken OP mijn wards die op mijn antwoord wachten (Guardianship Fase 2,
44 * shaer-jdb). Dit was een lege stub: de gating zelf werkt sinds shaer-hxg, maar
45 * werd nooit aan een C2S-client doorgegeven omdat de koers toen op de PWA lag.
46 *
47 * Twee bronnen, want een guardian kan wards op andere servers hebben en (nog)
48 * op deze:
49 * - ap_follow_reviews: de doorgestuurde kopie van een REMOTE ward
50 * - ap_pending_follows: een ward op deze instance
51 * Zie shaer-h6u: die tweede hoort op termijn ook over de lijn te gaan.
52 */
53export function followsCollection(id, slug, me) {
54 const items = follows.listReviewsByDirection(slug, 'incoming')
55 .map((r) => follows.reviewQueueItem(r, me));
56 for (const w of relations.listWards(slug)) {
57 const wardSlug = slugOf(w.other_uri);
58 if (!wardSlug) continue;
59 for (const p of follows.listForWard(wardSlug)) {
60 items.push({
61 id: p.id, type: 'Follow', actor: p.follower_uri, object: w.other_uri,
62 'shaer:direction': 'incoming', 'shaer:ward': w.other_uri,
63 'shaer:follower': p.follower_uri, 'shaer:followerHandle': p.follower_handle || undefined,
64 'shaer:quorum': p.quorum || 'any', published: p.created_at,
65 });
66 }
67 }
68 return collection(id, items);
69}
70
71/** De slug van een actor-uri op DEZE instance, of null als hij elders woont. */
72function slugOf(uri) {
73 const base = (process.env.PUBLIC_BASE_URL || '').replace(/\/+$/, '');
74 if (!base || !String(uri || '').startsWith(`${base}/ap/users/`)) return null;
75 return decodeURIComponent(String(uri).slice(`${base}/ap/users/`.length).split(/[/?#]/)[0]) || null;
76}
77
78/**
79 * §5.3 uitgaand. Twee lezers, een wachtrij, en dat kan omdat §1 een ward en een
80 * guardian wederzijds uitsluit: je bent het een of het ander.
81 *
82 * ALS WARD wat IK wil volgen en waar mijn guardians nog over moeten
83 * ALS GUARDIAN wat mijn WARDS willen volgen en waar IK over moet (shaer-jdb)
84 *
85 * Dat tweede ontbrak. De wachtrij serveerde alleen listForWard(slug), en voor
86 * een guardian is dat per definitie leeg -- dus het scherm "Your wards want to
87 * follow" kon nooit iets tonen.
88 */
89export function outgoingFollowsCollection(id, slug, me) {
90 const items = outgoing.listForWard(slug).map((o) => outgoing.queueItem(o, me));
91 for (const r of follows.listReviewsByDirection(slug, 'outgoing')) {
92 items.push(follows.reviewQueueItem(r, me));
93 }
94 return collection(id, items);
95}
96
97/** The guardian's committed wards, with cached handle for display. */
98export function wardsCollection(id, slug) {
99 const items = relations.listWards(slug)
100 .map((r) => ({
101 id: r.other_uri,
102 'shaer:handle': r.other_handle || undefined,
103 since: r.created_at,
104 // Alles wat voor dit kind gated is, met soort, drempel en lopend voorstel
105 // (shaer-ahy.1). Zonder dit kon een app wel een ward TONEN maar niets over
106 // hem zeggen -- en dat is precies de helft van het antwoord op "wat mag
107 // dit kind". Dezelfde rijen als het PWA-paneel, uit dezelfde functie.
108 'shaer:gates': wardGates(slug, r.other_uri),
109 }));
110 return collection(id, items);
111}
112
113/** The ward's guardians with their availability (§3.6.1: never public,
114 * owner-only): the real size of the safety net. Same shape as the daemon. */
115export function guardiansCollection(id, slug) {
116 const uris = relations.listGuardians(slug).map((r) => r.other_uri);
117 return collection(id, availability.statusesFor(slug, uris, Date.now()));
118}
119
120export default { offersCollection, followsCollection, outgoingFollowsCollection, wardsCollection, guardiansCollection, helpCollection, helpItemsFor, wardGates, wardGuardianStatuses };
121
122// ── Wat er voor een ward gated is (shaer-ahy.1) ─────────────────────────
123//
124// STOND IN routes/guardian.js, en daar kon alleen de PWA erbij. De Shaer-apps
125// lezen dezelfde toestand via de wards-queue, en een tweede berekening naast
126// deze zou vroeg of laat een ander antwoord geven op dezelfde vraag -- dat is
127// hier geen schoonheidsfoutje maar twee guardians die een verschillend beeld
128// van hetzelfde kind krijgen. Een plek dus, en beide schermen lezen eruit.
129/** The guardians of a ward WE host, with availability (3.6.1: owner-only in
130 * spirit; the co-guardians are among the owners of the relationship). Null
131 * for a remote ward: its server tracks availability, not us. */
132export function wardGuardianStatuses(wardUri) {
133 const base = (process.env.PUBLIC_BASE_URL || '').replace(/\/+$/, '');
134 if (!base || !String(wardUri || '').startsWith(`${base}/`)) return null;
135 const slug = String(wardUri).trim().replace(/\/+$/, '').split('/').pop();
136 try {
137 const uris = relations.listGuardians(slug).map((g) => ({ uri: g.other_uri, handle: g.other_handle }));
138 const st = Object.fromEntries(
139 availability.statusesFor(slug, uris.map((u) => u.uri), Date.now()).map((s) => [s.id, s]),
140 );
141 return uris.map((u) => ({
142 uri: u.uri,
143 handle: u.handle,
144 availability: (st[u.uri] || {})['shaer:availability'] || 'active',
145 awayUntil: (st[u.uri] || {})['shaer:awayUntil'] || null,
146 lapse: (st[u.uri] || {})['shaer:lapse'] || null,
147 }));
148 } catch { return null; }
149}
150/**
151 * De gate-rijen van een ward voor het paneel.
152 *
153 * De standen komen uit onze eigen kolommen als we het kind hosten; bij een ward
154 * elders weten we ze niet en blijft het NULL -- onbekend, niet uit. Het aantal
155 * guardians idem: dat wordt op de server van die ward bijgehouden, en zonder dat
156 * getal wordt er geen drempel verzonnen.
157 */
158export function wardGates(mySlug, wardUri) {
159 const statuses = wardGuardianStatuses(wardUri);
160 // Per richting geteld, want het zijn twee zorgen. "follows: 3 wachtend" liet
161 // een guardian niet zien of er drie vreemden bij zijn kind willen of dat zijn
162 // kind drie keer heeft gevraagd of het iemand mag volgen (shaer-p729).
163 const wachtendIn = follows.listReviewsByDirection(mySlug, 'incoming')
164 .filter((r) => r.ward_uri === wardUri).length;
165 const wachtendUit = follows.listReviewsByDirection(mySlug, 'outgoing')
166 .filter((r) => r.ward_uri === wardUri).length;
167 return gated.gateRows({
168 // Uit de BESLUITEN, niet uit onze eigen kolom. Er zijn geen lokale accounts:
169 // elke ward woont elders, dus wardEmbedSetting() gaf voor iedere ward null en
170 // stond er in het paneel overal "onbekend". Wat een guardian wel heeft is de
171 // uitslag van wat hij voorstelde.
172 settings: Object.fromEntries(gated.GATE_CATALOGUE
173 .filter((g) => g.available !== false && gated.featureColumn(g.feature))
174 .map((g) => [g.feature, gated.knownSetting(mySlug, wardUri, g.feature)])),
175 guardianCount: statuses ? statuses.length : null,
176 proposals: gated.listSent(mySlug, wardUri).map((p) => ({
177 feature: p.feature, value: !!p.value, status: gated.sentStatus(p, Date.now()),
178 })),
179 waiting: {
180 'shaer:follows': wachtendIn || undefined,
181 'shaer:following': wachtendUit || undefined,
182 },
183 // De vraag van het kind zelf staat APART van wat er in een wachtrij staat
184 // (shaer-8ru). Allebei "n waiting" noemen maakt van twee verschillende
185 // dingen een getal: drie onbekenden die je kind willen volgen is iets heel
186 // anders dan je kind dat een keer vraagt of muziek aan mag. Wel bij de poort
187 // waar het over gaat, want een aparte lijst vergeet je.
188 requested: gatereq.waitingFor(mySlug, wardUri),
189 });
190}
191
192
193// ── Hulpvragen met hun staat (shaer-lgo, shaer-ahy.1) ───────────────────
194//
195// De PWA had dit al; de apps kregen alleen de losse notes uit de feed en wisten
196// dus NIET of er al iemand op af was. Daarom bleef een afgehandeld verzoek daar
197// gewoon staan -- Barts melding. De staat wordt hier een keer berekend, zoals bij
198// wardGates: twee berekeningen zouden twee guardians een ander beeld geven van
199// hetzelfde kind.
200
201/**
202 * De hulpvragen van deze guardian, met wie erop af is en of het dicht is.
203 *
204 * OPEN VRAGEN WORDEN NOOIT AFGEKAPT, en dat is geen ruimhartigheid maar de reden
205 * dat de app iets mag CONCLUDEREN uit afwezigheid (Barts punt, 8-8).
206 *
207 * Dit stond op 50, en ik noemde 'tientallen hulpvragen bij een guardian' een
208 * randgeval. Bart wees op de jeugdzorgmedewerker: die heeft geen handvol wards
209 * maar een caseload, en voor hem is dat een gewone dinsdag. De gebruiker die dit
210 * het hardst nodig heeft was precies degene voor wie het brak.
211 *
212 * Met een afkap op alles zag een app een oudere vraag niet in de queue, vond geen
213 * staat, en toonde hem -- terecht, want bij twijfel OPEN -- als openstaand. Een
214 * allang afgehandelde hulpvraag die weer om aandacht vraagt. Nu geldt: staat hij
215 * niet in de queue, dan is hij NIET open. Die gevolgtrekking klopt alleen zolang
216 * we open vragen volledig leveren.
217 *
218 * De geschiedenis mag wel afgekapt: die vraagt niets, en wat eraf valt is nog
219 * steeds op de server te vinden.
220 */
221export function helpItemsFor(slug, historyLimit = 50) {
222 let rijen = [];
223 try {
224 // Alle velden die een kaart kan tonen, niet alleen die van de queue: de
225 // PWA had hierom een EIGEN kopie van deze query -- mét een afkap op 50,
226 // waardoor de fix hierboven aan het paneel voorbijging (Barts 429-jacht,
227 // 9-8). Een tweede weg naar dezelfde staat is precies wat er bij de
228 // reply-gate al misging; nu is dit de enige weg, en dan hoort hij ook te
229 // dragen wat een kaart nodig heeft. De extra kolommen kosten de queue
230 // niets: die leest ze gewoon niet.
231 rijen = db.prepare(
232 `SELECT object_uri, note_url, actor_uri, actor_name, actor_handle, actor_icon, content, published, created_at,
233 emoji_json, actor_emoji_json, media_json, quote_json, embed_json
234 FROM ap_mentions WHERE slug = ? AND help_request = 1 ORDER BY created_at DESC`,
235 ).all(slug);
236 } catch { return []; }
237 const staat = help.statusFor(rijen.map((r) => r.object_uri));
238 const mijn = new Set(relations.listWards(slug).map((w) => w.other_uri));
239 const alles = rijen.map((r) => ({
240 ...r,
241 // Bij twijfel OPEN. Een hulpvraag die er afgehandeld uitziet terwijl hij dat
242 // niet is, is de gevaarlijke fout -- niet andersom.
243 state: help.withWardship(
244 staat.get(r.object_uri) || { open: true, pickedUpBy: [], handled: null, oldestPickupAt: null },
245 mijn.has(r.actor_uri),
246 ),
247 }));
248 const open = alles.filter((h) => h.state.open);
249 const rest = alles.filter((h) => !h.state.open).slice(0, historyLimit);
250 return [...open, ...rest];
251}
252
253/** Dezelfde vragen als collectie voor de apps (5.2.1). */
254export function helpCollection(id, slug) {
255 const items = helpItemsFor(slug).map((h) => ({
256 id: h.object_uri,
257 type: 'Note',
258 attributedTo: h.actor_uri,
259 'shaer:handle': h.actor_handle || undefined,
260 content: h.content || '',
261 published: h.published || h.created_at,
262 'shaer:helpRequest': true,
263 // De staat als platte velden: een app hoeft hem niet af te leiden, en kan
264 // hem dus ook niet anders afleiden dan het paneel.
265 'shaer:open': h.state.open,
266 'shaer:handledBy': h.state.handled ? (h.state.handled.handle || h.state.handled.uri) : undefined,
267 'shaer:handledAt': h.state.handled ? h.state.handled.at : undefined,
268 'shaer:pickedUpBy': h.state.pickedUpBy.map((p) => p.handle || p.uri),
269 'shaer:formerWard': h.state.formerWard || undefined,
270 }));
271 const coll = collection(id, items);
272 // Het teken dat de app mag concluderen uit afwezigheid: elke OPEN vraag zit
273 // hierin. Ontbreekt deze vlag (een oudere server), dan valt de app terug op
274 // bij-twijfel-open, en dat is de veilige kant.
275 coll['shaer:openComplete'] = true;
276 return coll;
277}
Note: See TracBrowser for help on using the repository browser.