Samenwerken: ketenkeuring matrix-rust-sdk (Apache-2.0) — de permissieve route naar vol Matrix #991

Closed
opened 2026-07-30 12:59:57 +00:00 by brenno · 3 comments
Owner

Vervolg op #976. De famedly matrix-Dart-SDK is daar NO-GO (AGPL-3.0). Maar matrix.org's eigen matrix-rust-sdk is Apache-2.0 en levert een volledige Matrix-client mét E2EE (Element X draait erop). Dat is de permissieve route naar 'Matrix vol' zonder herlicensering van OciDeck — hij verdient een eigen gedocumenteerde GO/NO-GO, net als #976.

Te keuren:

  1. De Cargo-boom van matrix-rust-sdk zelf — alle crates + licenties (is het permissief-verenigbaar, Apache/MIT?), transitieve omvang, en de kwetsbaarheidsscanning (cargo-audit/OSV op crates).
  2. De bindingslast (nieuw en niet gering). Er is geen Dart/Flutter-binding; die bouw en onderhoud je zelf via flutter_rust_bridge (of door de uniffi-FFI te omhullen). Dit is een doorlopende ingenieursverplichting, geen eenmalige klus — de binding beweegt mee met de API van matrix-rust-sdk.
  3. Native vs. web — de kernvraag. Native (macOS/Windows/Linux, iOS/Android) is het solide geval: Rust→native lib→Dart-FFI, zoals Element X. Web is de moeilijke kant: de beproefde browserroute is een JS-client (matrix-js-sdk) met alleen de crypto in WASM (matrix-sdk-crypto-wasm, 'designed to run on a JavaScript host'); de volledige rust-sdk in de browser past niet netjes op Flutter-web/CanvasKit. Beslispunt: wat wordt de web-stand? Real-time op de losse apps en web terugvallen op WebDAV-async (#989), een JS-brug, of voorlopig geen live-samenwerking op web.
  4. De Rust-toolchainkost op de bouw-/uitbrengketen — toolchainpin, CI/release-runners, code signing van de native blob. Zie de consequenties genoteerd bij #976.
  5. SBOM-tool naar Cargo.lock — carry-over van Bevinding 3 uit #976; nodig ongeacht de bron van de crypto.

Uitkomst: een gedocumenteerde GO/NO-GO in assurance/, zoals #976. Vereist géén AGPL-beleidswijziging.

Referentie: #976 (assurance/ketenkeuring-matrix-sdk.md), COLLABORATION.md §6, §9. Alternatief voor #977 (blijft op pauze); WebDAV-async (#989) blijft de goedkope tussenstap.

Vervolg op #976. De famedly `matrix`-Dart-SDK is daar NO-GO (AGPL-3.0). Maar matrix.org's eigen **matrix-rust-sdk** is **Apache-2.0** en levert een volledige Matrix-client mét E2EE (Element X draait erop). Dat is de permissieve route naar 'Matrix vol' zonder herlicensering van OciDeck — hij verdient een eigen gedocumenteerde GO/NO-GO, net als #976. **Te keuren:** 1. **De Cargo-boom van matrix-rust-sdk zelf** — alle crates + licenties (is het permissief-verenigbaar, Apache/MIT?), transitieve omvang, en de kwetsbaarheidsscanning (cargo-audit/OSV op crates). 2. **De bindingslast (nieuw en niet gering).** Er is geen Dart/Flutter-binding; die bouw en onderhoud je zelf via `flutter_rust_bridge` (of door de uniffi-FFI te omhullen). Dit is een doorlopende ingenieursverplichting, geen eenmalige klus — de binding beweegt mee met de API van matrix-rust-sdk. 3. **Native vs. web — de kernvraag.** Native (macOS/Windows/Linux, iOS/Android) is het solide geval: Rust→native lib→Dart-FFI, zoals Element X. Web is de moeilijke kant: de beproefde browserroute is een JS-client (matrix-js-sdk) met alleen de crypto in WASM (matrix-sdk-crypto-wasm, 'designed to run on a JavaScript host'); de volledige rust-sdk in de browser past niet netjes op Flutter-web/CanvasKit. **Beslispunt: wat wordt de web-stand?** Real-time op de losse apps en web terugvallen op WebDAV-async (#989), een JS-brug, of voorlopig geen live-samenwerking op web. 4. **De Rust-toolchainkost op de bouw-/uitbrengketen** — toolchainpin, CI/release-runners, code signing van de native blob. Zie de consequenties genoteerd bij #976. 5. **SBOM-tool naar `Cargo.lock`** — carry-over van Bevinding 3 uit #976; nodig ongeacht de bron van de crypto. **Uitkomst:** een gedocumenteerde GO/NO-GO in `assurance/`, zoals #976. Vereist géén AGPL-beleidswijziging. **Referentie:** #976 (assurance/ketenkeuring-matrix-sdk.md), COLLABORATION.md §6, §9. Alternatief voor #977 (blijft op pauze); WebDAV-async (#989) blijft de goedkope tussenstap.
Author
Owner

Opgepakt. Tak: chore/ketenkeuring-matrix-rust-sdk. Verwachte reikwijdte: één GO/NO-GO-keuringsdocument onder assurance/ (assurance/ketenkeuring-matrix-rust-sdk.md), parallel aan #976 — geen code- of pubspec-wijziging, want de keuring gaat vóór de bouw. De feiten (Cargo-boom, licenties, bindingsroute, web-stand, toolchain, SBOM) worden bij de bron nagekeken, niet uit het geheugen.

Opgepakt. Tak: chore/ketenkeuring-matrix-rust-sdk. Verwachte reikwijdte: één GO/NO-GO-keuringsdocument onder assurance/ (assurance/ketenkeuring-matrix-rust-sdk.md), parallel aan #976 — geen code- of pubspec-wijziging, want de keuring gaat vóór de bouw. De feiten (Cargo-boom, licenties, bindingsroute, web-stand, toolchain, SBOM) worden bij de bron nagekeken, niet uit het geheugen.
Author
Owner

Keuring afgerond en geland in merge 45c9e1be (PR #993): assurance/ketenkeuring-matrix-rust-sdk.md, parallel aan #976 en geregistreerd in de assurance-README.

Uitkomst: NO-GO om het nú te bouwen; principieel GO als de erkende toekomstige route naar realtime-Matrix. De reden verschilt fundamenteel van #976 — daar was de blokker een publieke belofte (de AGPL-licentievloer). Die vervalt hier: matrix-rust-sdk en vodozemac zijn Apache-2.0, opnemen herlicenseert niets en haalt de licentiepoort. Dat was de vraag van #991, en het antwoord is ja: de permissieve route bestaat en vergt géén beleidswijziging.

Wat overblijft is kosten, geen principe: (2) er is geen Dart-binding — die bouw en onderhoud je zelf, doorlopend; (3) de web-stand is onopgelost (native solide zoals Element X, web experimenteel via aurora — aanbeveling: native realtime, web async via #989); (4) de Rust-toolchain en (5) de SBOM-blinde vlek uit #976 blijven staan. De vier GO-voorwaarden bevatten anders dan bij #976 geen licentie-/beleidsvoorwaarde.

Aanbevolen weg: Fase 0.5 (WebDAV-async, #989) als scheepbare tussenstap. De formele knoop — de doorlopende bindings-/toolchainverplichting aangaan — ligt bij de beheerder. Feiten nagekeken bij de bron (matrix.org-repo, bindings/-mappen, Cargo.toml), geen code- of pubspec-wijziging.

Keuring afgerond en geland in merge 45c9e1be (PR #993): assurance/ketenkeuring-matrix-rust-sdk.md, parallel aan #976 en geregistreerd in de assurance-README. Uitkomst: NO-GO om het nú te bouwen; principieel GO als de erkende toekomstige route naar realtime-Matrix. De reden verschilt fundamenteel van #976 — daar was de blokker een publieke belofte (de AGPL-licentievloer). Die vervalt hier: matrix-rust-sdk en vodozemac zijn Apache-2.0, opnemen herlicenseert niets en haalt de licentiepoort. Dat was de vraag van #991, en het antwoord is ja: de permissieve route bestaat en vergt géén beleidswijziging. Wat overblijft is kosten, geen principe: (2) er is geen Dart-binding — die bouw en onderhoud je zelf, doorlopend; (3) de web-stand is onopgelost (native solide zoals Element X, web experimenteel via aurora — aanbeveling: native realtime, web async via #989); (4) de Rust-toolchain en (5) de SBOM-blinde vlek uit #976 blijven staan. De vier GO-voorwaarden bevatten anders dan bij #976 geen licentie-/beleidsvoorwaarde. Aanbevolen weg: Fase 0.5 (WebDAV-async, #989) als scheepbare tussenstap. De formele knoop — de doorlopende bindings-/toolchainverplichting aangaan — ligt bij de beheerder. Feiten nagekeken bij de bron (matrix.org-repo, bindings/-mappen, Cargo.toml), geen code- of pubspec-wijziging.
Author
Owner

Besluit bevestigd en vastgelegd in het keuringsdocument (merge 5397d18a, PR #994): NO-GO om het nú te bouwen, principieel GO als de erkende toekomstige route naar realtime-Matrix. Volgende stap blijft Fase 0.5 (WebDAV-async, #989); het licentiebeleid blijft ongewijzigd. Afgehandeld — sluiten.

Besluit bevestigd en vastgelegd in het keuringsdocument (merge 5397d18a, PR #994): NO-GO om het nú te bouwen, principieel GO als de erkende toekomstige route naar realtime-Matrix. Volgende stap blijft Fase 0.5 (WebDAV-async, #989); het licentiebeleid blijft ongewijzigd. Afgehandeld — sluiten.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
LibreKAT/Ocideck#991
No description provided.