docs(design): spine-besluit — enkelvoudige XMPP-spine + ketenkeuring, backend-exclusiviteit #1097

Merged

brenno merged 2 commits from design/xmpp-spine into main

2026-08-01 22:47:38 +00:00

brenno commented

2026-08-01 22:47:26 +00:00

Owner

Legt het beheerdersbesluit (2026-08-02) vast: OciDeck kiest de enkelvoudige XMPP-spine als primaire route voor natieve calls + realtime-samenwerken. Eén XMPP/Prosody-verbinding draagt zowel de Jitsi-calls (media-signalering) als de samenwerkings-data-plane (XmppTransport implements CollabTransport). Ontwerp-only, unbuilt, gepoort. Vervolg op #1095.

Wat dit vastlegt

assurance/ketenkeuring-xmpp-spine.md (nieuw) — GO/NO-GO van de XMPP-spine. Pure-Dart/permissief; de crypto is niet nieuw maar hetzelfde minimale relay-schema, over XMPP i.p.v. Matrix (géén OMEMO/ratchet). Principieel GO als primaire spine; NO-GO om de code nú te bouwen tot vier voorwaarden (lib-keuze + SBOM, gedeelde crypto + externe toets óók van de tweede drager, backend-exclusiviteit-invariant, NetGuard/belofte).
NATIVE_CALLS.md — open vraag 0 als beslist gemarkeerd; backend-exclusiviteit als invariant (§1, §6, F5): een sessie draait óf op XMPP/Jitsi óf op Matrix, nooit vermengd. "Hosten via de Matrix-backend" = een wholly-Matrix-mode-sessie, los van de XMPP-mode.
Relay-reconciliatie: ketenkeuring-self-encrypted-relay.md + de README-rij zijn gedateerd bijgesteld — de relay-GO blijft, maar de relay is sinds dit besluit de Matrix-mode-spine, niet langer dé primaire realtime-route.

Botsing (expliciet, per bewaker): veiligheid-op-1 tegen coherentie/snelheid

Het besluit wint met "coherentie tegen optooptelling" (één spine die je tóch al hebt) en "één crypto-kern, twee transporten". Dat is een geldige afweging — maar zij mag niet stilzwijgend kantelen. Twee dingen daarom hardop:

De externe crypto-review wordt gescopet op de tweede drager. "Geen nieuw schema" is niet "geen nieuwe review": de transport-binding is per drager nieuw — herordening/replay (Matrix /sync vs. XMPP MUC/MAM/PubSub), ledenwissel→hersleutelen (Matrix-membership vs. MUC-affiliaties/presence), en mode/sessie-bindende associated-data zodat een Matrix-mode-ciphertext niet in XMPP-mode herbruikbaar is. Vastgelegd als voorwaarde 2.
De XMPP-cliënt is een nieuwe netwerkstack (sockets/websocket, geen http), dus de belofte "the only HTTP client dependency is http" in ARCHITECTURE.md wordt bijgewerkt — net als bij flutter_webrtc. Vastgelegd in Bevinding 5, voorwaarde 4 en het Besluit.

Waaronder ik van gedachten zou veranderen: als het minimale schema onder de transport-binding tóch richting een eigen ratchet zou kruipen, is de beproefde matrix-crypto (#991) strikt beter en vervalt de reden voor deze route (de rode lijn uit de relay-keuring, hier herhaald).

Bewaker

Beoordeeld vanuit de bewaker-blik: landen-met-aanpassing — het besluit is verenigbaar met het overkoepelende idee (.md onaangeraakt, sessie vergankelijk, vertrouwenspartij bring-your-own en open/gefedereerd). De drie belangrijke correcties (beloftefout, relay-reconciliatie, crypto-review-scope) en twee aanscherpingen (totale code-surface = zwaarste route; kostenkant van exclusiviteit; XXE-weren in de parser) zijn in de tweede commit verwerkt.

Verificatie

Docs-only: geen Dart/pubspec/l10n → make check-uitkomst ongewijzigd. Design/assurance-docs zijn niet gebundeld (geen registratiepoort). Alle relatieve linkdoelen bestaan (geverifieerd).

Legt het **beheerdersbesluit (2026-08-02)** vast: OciDeck kiest de **enkelvoudige XMPP-spine** als primaire route voor natieve calls + realtime-samenwerken. Eén XMPP/Prosody-verbinding draagt zowel de Jitsi-calls (media-signalering) als de samenwerkings-data-plane (`XmppTransport implements CollabTransport`). Ontwerp-only, unbuilt, gepoort. Vervolg op #1095. ## Wat dit vastlegt - `assurance/ketenkeuring-xmpp-spine.md` (nieuw) — GO/NO-GO van de XMPP-spine. Pure-Dart/permissief; de crypto is niet nieuw maar hetzelfde minimale relay-schema, over XMPP i.p.v. Matrix (géén OMEMO/ratchet). **Principieel GO** als primaire spine; **NO-GO om de code nú te bouwen** tot vier voorwaarden (lib-keuze + SBOM, gedeelde crypto + externe toets óók van de tweede drager, backend-exclusiviteit-invariant, NetGuard/belofte). - `NATIVE_CALLS.md` — open vraag 0 als **beslist** gemarkeerd; **backend-exclusiviteit** als invariant (§1, §6, F5): een sessie draait óf op XMPP/Jitsi óf op Matrix, **nooit vermengd**. "Hosten via de Matrix-backend" = een wholly-Matrix-mode-sessie, los van de XMPP-mode. - Relay-reconciliatie: `ketenkeuring-self-encrypted-relay.md` + de README-rij zijn gedateerd bijgesteld — de relay-GO blijft, maar de relay is sinds dit besluit de **Matrix-mode-spine**, niet langer *dé* primaire realtime-route. ## Botsing (expliciet, per bewaker): veiligheid-op-1 tegen coherentie/snelheid Het besluit wint met "coherentie tegen optooptelling" (één spine die je tóch al hebt) en "één crypto-kern, twee transporten". Dat is een geldige afweging — maar zij mag niet stilzwijgend kantelen. Twee dingen daarom hardop: - **De externe crypto-review wordt gescopet op de *tweede drager*.** "Geen nieuw schema" is niet "geen nieuwe review": de transport-binding is per drager nieuw — herordening/replay (Matrix `/sync` vs. XMPP MUC/MAM/PubSub), ledenwissel→hersleutelen (Matrix-membership vs. MUC-affiliaties/presence), en mode/sessie-bindende associated-data zodat een Matrix-mode-ciphertext niet in XMPP-mode herbruikbaar is. Vastgelegd als voorwaarde 2. - **De XMPP-cliënt is een nieuwe netwerkstack** (sockets/websocket, geen `http`), dus de belofte *"the only HTTP client dependency is `http`"* in `ARCHITECTURE.md` wordt bijgewerkt — net als bij `flutter_webrtc`. Vastgelegd in Bevinding 5, voorwaarde 4 en het Besluit. **Waaronder ik van gedachten zou veranderen:** als het minimale schema onder de transport-binding tóch richting een eigen ratchet zou kruipen, is de beproefde matrix-crypto (#991) strikt beter en vervalt de reden voor deze route (de rode lijn uit de relay-keuring, hier herhaald). ## Bewaker Beoordeeld vanuit de bewaker-blik: **landen-met-aanpassing** — het besluit is verenigbaar met het overkoepelende idee (`.md` onaangeraakt, sessie vergankelijk, vertrouwenspartij bring-your-own en open/gefedereerd). De drie belangrijke correcties (beloftefout, relay-reconciliatie, crypto-review-scope) en twee aanscherpingen (totale code-surface = zwaarste route; kostenkant van exclusiviteit; XXE-weren in de parser) zijn in de tweede commit verwerkt. ## Verificatie Docs-only: geen Dart/`pubspec`/l10n → `make check`-uitkomst ongewijzigd. Design/assurance-docs zijn niet gebundeld (geen registratiepoort). Alle relatieve linkdoelen bestaan (geverifieerd).

brenno added 2 commits

2026-08-01 22:47:27 +00:00

docs(design): spine-besluit — enkelvoudige XMPP-spine + ketenkeuring a1b4213f8e

Beheerdersbesluit (2026-08-02): open vraag 0 uit NATIVE_CALLS.md §5 beslist —
de enkelvoudige XMPP-spine wordt de primaire route. Eén XMPP/Prosody-verbinding
draagt zowel de Jitsi-calls als de samenwerkings-data-plane (XmppTransport
implements CollabTransport).

- assurance/ketenkeuring-xmpp-spine.md (nieuw): GO/NO-GO. Pure-Dart/permissief;
  de crypto is niet nieuw maar hetzelfde minimale schema als de self-encrypted
  relay, over XMPP i.p.v. Matrix (géén OMEMO/ratchet — de rode lijn blijft).
  Principieel GO als primaire spine; NO-GO om nú te bouwen tot vier voorwaarden
  (lib-keuze, gedeelde crypto + externe toets, backend-exclusiviteit-invariant,
  NetGuard op de signalering-origin).
- Backend-exclusiviteit als harde invariant: een sessie draait óf op XMPP/Jitsi
  óf op Matrix, nooit vermengd. "Hosten via de Matrix-backend" is een
  wholly-Matrix-mode-sessie, los van de XMPP-mode. Vastgelegd in NATIVE_CALLS.md
  §1/§6, F5 en open vraag 0.
- De relay-GO (2026-07-31) wordt NIET overruled: die blijft de Matrix-mode-spine.
  Kruislinks in COLLABORATION.md en assurance/README.md bijgewerkt.

Ontwerp-only, unbuilt. De bouw-GO hangt aan de vier voorwaarden + de
flutter_webrtc-media-dep-GO.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs(design): bewaker-correcties — beloftefout, relay-reconciliatie, crypto-review

scans / scans (pull_request) Successful in 3m40s

Details

6e821dfdeb

Bewaker-blik op de tak: landen-met-aanpassing. Drie belangrijke correcties + twee
aanscherpingen verwerkt.

- Beloftefout (belangrijk): de XMPP-cliënt is zélf een tweede netwerkstack (sockets/
  websocket, geen `http`), dus de claim "houdt elke belofte overeind" klopte niet.
  De "enige http-dependency"-belofte in ARCHITECTURE.md wordt óók hier bijgewerkt,
  net als bij flutter_webrtc. Gecorrigeerd in Bevinding 5, voorwaarde 4 en het Besluit.
- Relay-reconciliatie (belangrijk): de relay-docs zeiden nog onvoorwaardelijk "dé
  route naar realtime". Gedateerde bijstelling toegevoegd aan
  ketenkeuring-self-encrypted-relay.md en de README-rij: de relay is sinds 2026-08-02
  de Matrix-mode-spine; XMPP is primair. GO blijft, positionering versmald.
- Crypto-review-scope (belangrijk, waarde 1): "geen nieuw schema" mag geen "geen nieuwe
  review" worden. De transport-binding is per drager nieuw (herordening/replay,
  ledenwissel→rekey, mode-bindende AAD); voorwaarde 2 eist die scope nu expliciet.
- Aanscherpingen: totale code-surface is de zwaarste van de vier routes (waarde 10);
  backend-exclusiviteit heeft een kostenkant (geen cross-familie-hergebruik);
  XXE-/entiteitsexpansie-weren in de stanza-parser bij de begrenzingen.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno merged commit 4bac15beb8 into main

2026-08-01 22:47:38 +00:00

brenno deleted branch design/xmpp-spine

2026-08-01 22:47:39 +00:00

brenno referenced this pull request from a commit

2026-08-01 22:47:40 +00:00

Merge pull request 'docs(design): spine-besluit — enkelvoudige XMPP-spine + ketenkeuring, backend-exclusiviteit' (#1097) from design/xmpp-spine into main

brenno referenced this pull request

2026-08-02 01:04:33 +00:00

feat(meetings): F1 native calls — backend-neutrale interface + video-calls-module + call-paneel #1104