3 ms·
We have been planning a new from scratch version that'll be in tree, but with the retirement of libolm which is for good reasons, it means we're going to have t
by rw_grim 2y ago
We have been planning a new from scratch version that'll be in tree, but with the retirement of libolm which is for good reasons, it means we're going to have to write our own OLM implementation at some point as well.
https://matrix.org/blog/2024/08/libolm-deprecation/ https://matrix.org/blog/2024/08/libolm-deprecation/
TL;DR it's on the list, going to be a bit before we get to it.
- Arathorn 2y agohm, you really shouldn’t have to write your own olm implementation(!) either you could swap primitives in libolm (eg fork libolm and merge https://gitlab.matrix.org/matrix-org/olm/-/merge_requests/24 https://gitlab.matrix.org/matrix-org/olm/-/merge_requests/24) or use vodozemac via wrappers.
- rw_grim 2y agolibolm was not using battle tested crypto. That's one of their main reasons for abandoning it. Our plan is to use gcrypto for it which is battle tested. As far as vodozemac goes, we're not pulling rust into our build system.