3 ms·

> This is not a protocol or specification bug, but an implementation bug which was then unfortunately replicated in other independent implementations. > We wi

> This is not a protocol or specification bug, but an implementation bug which was then unfortunately replicated in other independent implementations. > We will also accelerate our work on matrix-rust-sdk as a portable reference implementation of the Matrix protocol, avoiding the implicit requirement that each independent library must necessarily reimplement this logic on its own I like the idea of providing a core Rust/C++ library that can be called in any other runtime via FFI, compiling to WebAssembly, etc. I've used the same technique to ensure consistency in usage of a custom time-series compression format across an organization. Overall this technique seems in-line with the "DRY" principle, and the tradeoffs have been favorable in my experience. I think it will be a good step forward for the Matrix ecosystem.

Arathorn 5y ago
The current way we're approaching this is to split the reference E2EE implementation into its own rust crate (https://github.com/matrix-org/matrix-rust-sdk/tree/master/matrix_sdk_crypto https://github.com/matrix-org/matrix-rust-sdk/tree/master/ma...) which can be used with any SDK (e.g. we're almost finished embedding it into the Kotlin matrix-android-sdk2 client) Separately, there's also the overall matrix-rust-sdk https://github.com/matrix-org/matrix-rust-sdk https://github.com/matrix-org/matrix-rust-sdk for clients to use as a "full fat" Matrix client SDK - as used by Fractal Next (https://gitlab.gnome.org/GNOME/fractal/-/tree/fractal-next https://gitlab.gnome.org/GNOME/fractal/-/tree/fractal-next) etc. We might end up using this in Element too in future (especially in Element iOS, where a Swift UI + matrix-rust-sdk backend could be quite a cute next generation architecture). So while the first generation reference Matrix SDKs (matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk) were completely independent implementations, each with their own bugs and increased audit surface, we're hoping that matrix-rust-sdk will simplify this a lot in future.
- danShumway 5y ago
  Quick comment, just want to show some additional support for the shared crate approach that Matrix is pursuing, it should give people a lot more confidence to try alternate clients. I throw messaging apps in the same category as, for example, web browsers. It's really tough to try an alternate implementation if you're worried that they might have broken a complicated security feature. So having more shared crates mitigates some of that risk.

Arathorn 5y ago

The current way we're approaching this is to split the reference E2EE implementation into its own rust crate (https://github.com/matrix-org/matrix-rust-sdk/tree/master/matrix_sdk_crypto https://github.com/matrix-org/matrix-rust-sdk/tree/master/ma...) which can be used with any SDK (e.g. we're almost finished embedding it into the Kotlin matrix-android-sdk2 client) Separately, there's also the overall matrix-rust-sdk https://github.com/matrix-org/matrix-rust-sdk https://github.com/matrix-org/matrix-rust-sdk for clients to use as a "full fat" Matrix client SDK - as used by Fractal Next (https://gitlab.gnome.org/GNOME/fractal/-/tree/fractal-next https://gitlab.gnome.org/GNOME/fractal/-/tree/fractal-next) etc. We might end up using this in Element too in future (especially in Element iOS, where a Swift UI + matrix-rust-sdk backend could be quite a cute next generation architecture). So while the first generation reference Matrix SDKs (matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk) were completely independent implementations, each with their own bugs and increased audit surface, we're hoping that matrix-rust-sdk will simplify this a lot in future.

danShumway 5y ago
Quick comment, just want to show some additional support for the shared crate approach that Matrix is pursuing, it should give people a lot more confidence to try alternate clients. I throw messaging apps in the same category as, for example, web browsers. It's really tough to try an alternate implementation if you're worried that they might have broken a complicated security feature. So having more shared crates mitigates some of that risk.