-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thoughts about a matrix-rust-sdk connection #721
Comments
Sorry for taking time to respond. Not for the most of its functionality (not yet at least), but there's work ongoing to use the E2EE functionality provided by matrix-rust-sdk. Depending on the experience, we might consider using more of matrix-rust-sdk but that's far from certain - integration between Rust and C++ is not an easy feat and what's worse, things may deteriorate as the Rust language and toolchain are still actively evolving. |
Thanks for your answer! matrix-rust-sdk in general seems embed friendly for other programming languages since it was created with that indent. I saw already existing uniffi-bindings in their repository and with uniffi-bindgen-cpp there also exists a binding generator for C++ (not sure if it works on matrix-rust-sdk). Anyway, of course it will be a lot of additional work to create a high-level C++-API based on that. |
The interesting part would be figuring out how to deal with the asynchronous nature of matrix-rust-sdk. uniffi-bindgen-cpp doesn't support async functions and even if it did, my understanding is that that wouldn't be enough, as the rust sdk requires a tokio event loop. As far as I can tell, we'd need to run the SDK in a separete thread and then figure out how to communicate nicely between those threads...
|
i'm guessing you want the C++ API to appear async as well right? |
Ideally yes. If we can figure out another way of making things work nicely, that would also be fine i guess |
This suggests that a Rust runtime like tokio is possible but optional (the application can provide such a loop itself). |
I'm a happy user of Neochat and a regular reader of the Matrix Weekly Newsletter. Nearly in every Newsletter some changes in the matrix-rust-sdk are mentioned since it serves as test bed for the newer Matrix techniques and backs the next generation Element clients. As far as I know it should be the Matrix library that implements most of the specification.
Neochat, on the other hand offers me a much better user experience than the Element program family. It integrates way better into my KDE desktop, so that I prefer it over Element. It lacks some Matrix features, though, for which the right place to implement this library would be.
Therefore, I was wondering, if it would be possible to combine the two worlds and adapt libQuotient to be a Qt/C++-Matrix library that uses the matrix-rust-sdk for most of its functionality. I have not looked into the code of either of the two projects and have no clue of the internals of Matrix so I'm not qualified enough to have an opinion by myself. It is just an idea and I'm interested in your opinion about that topic.
The text was updated successfully, but these errors were encountered: