Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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/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 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) 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.



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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: