Explore: fetch Mattermost data directly from the frontend (backend data minimization)

robbertbos commented

2026-07-25 16:17:15 +00:00

Owner

Vandaag zit de Waggle-backend tussen de browser en Mattermost voor vrijwel alle
MM-data: hij proxyt avatars/bestanden (/api/mm/avatar, /api/mm/file), levert
de kanaal-/personenkiezer (/api/mm/targets, /api/mm/people), en denormaliseert
MM-metadata op eigen rijen (o.a. outgoing_posts.channel_display_name /
team_display_name / channel_type, en cards.source_data). De browser houdt
het MM-token nooit vast; de backend ontsleutelt het per request en praat namens
de gebruiker met MM.

Onderzoek of de frontend MM-data rechtstreeks en veilig kan ophalen, zodat de
Waggle-backend minder Mattermost-data opslaat en verwerkt (AVG-dataminimalisatie /
BIO). Dat verkleint de MM-metadata-voetafdruk in Waggle (minder gedenormaliseerde
kolommen, minder proxying, een kleiner cross-tenant-oppervlak).

Hier moet eerst een plan/ontwerp voor komen - het "veilig"-deel is het hele
probleem:

Het MM-token mag niet in de browser komen (het staat niet voor niets versleuteld
at rest). Direct-vanuit-de-browser vraagt een ander auth-pad: de eigen
MM-sessiecookie van de gebruiker, een scoped/kortlevend token, een
token-exchange, of CORS + de eigen MM-auth op de doelserver.
CORS op de doel-MM-server (die beheert Waggle niet).
Wat sowieso gedenormaliseerd moet blijven: een geplande/mislukte outbox-rij moet
leesbaar blijven als MM onbereikbaar is (verlopen token, gearchiveerd kanaal,
offline) - precies waarom de display-snapshot nu bestaat. Een direct-fetch-model
moet beslissen wat het dan nog snapshot.
De desktop-app-permalink-scheme, avatar-cache-busting, file-range-requests en de
HTML-preview-sandbox worden nu allemaal door de proxy afgehandeld.

Buiten scope voor nu: de backend houdt de metadata die hij heeft (de
outgoing_posts-display-snapshot blijft). Dit issue is de plek om de richting te
ontwerpen; nog geen wijziging.

Gerelateerd: de outbox-display-denormalisatie (fase 4), de /api/mm/*-proxy +
lookups, en het threat-model in docs/security.md.

Vandaag zit de Waggle-backend tussen de browser en Mattermost voor vrijwel alle MM-data: hij proxyt avatars/bestanden (`/api/mm/avatar`, `/api/mm/file`), levert de kanaal-/personenkiezer (`/api/mm/targets`, `/api/mm/people`), en denormaliseert MM-metadata op eigen rijen (o.a. `outgoing_posts.channel_display_name` / `team_display_name` / `channel_type`, en `cards.source_data`). De browser houdt het MM-token nooit vast; de backend ontsleutelt het per request en praat namens de gebruiker met MM. Onderzoek of de frontend MM-data **rechtstreeks en veilig** kan ophalen, zodat de Waggle-backend minder Mattermost-data opslaat en verwerkt (AVG-dataminimalisatie / BIO). Dat verkleint de MM-metadata-voetafdruk in Waggle (minder gedenormaliseerde kolommen, minder proxying, een kleiner cross-tenant-oppervlak). **Hier moet eerst een plan/ontwerp voor komen** - het "veilig"-deel is het hele probleem: - Het MM-token mag niet in de browser komen (het staat niet voor niets versleuteld at rest). Direct-vanuit-de-browser vraagt een ander auth-pad: de eigen MM-sessiecookie van de gebruiker, een scoped/kortlevend token, een token-exchange, of CORS + de eigen MM-auth op de doelserver. - CORS op de doel-MM-server (die beheert Waggle niet). - Wat sowieso gedenormaliseerd moet blijven: een geplande/mislukte outbox-rij moet leesbaar blijven als MM onbereikbaar is (verlopen token, gearchiveerd kanaal, offline) - precies waarom de display-snapshot nu bestaat. Een direct-fetch-model moet beslissen wat het dan nog snapshot. - De desktop-app-permalink-scheme, avatar-cache-busting, file-range-requests en de HTML-preview-sandbox worden nu allemaal door de proxy afgehandeld. Buiten scope voor nu: de backend houdt de metadata die hij heeft (de `outgoing_posts`-display-snapshot blijft). Dit issue is de plek om de richting te ontwerpen; nog geen wijziging. Gerelateerd: de outbox-display-denormalisatie (fase 4), de `/api/mm/*`-proxy + lookups, en het threat-model in docs/security.md.

robbertbos referenced this issue

2026-08-15 12:42:20 +00:00

Cache and log hardening - phase 0 of the #189 data-minimization track #313