Skip to content
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

Open
gerion0 opened this issue Feb 26, 2024 · 6 comments
Open

Thoughts about a matrix-rust-sdk connection #721

gerion0 opened this issue Feb 26, 2024 · 6 comments
Labels
enhancement A feature or change request for the library

Comments

@gerion0
Copy link

gerion0 commented Feb 26, 2024

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.

@gerion0 gerion0 added the enhancement A feature or change request for the library label Feb 26, 2024
@KitsuneRal
Copy link
Member

KitsuneRal commented Jan 15, 2025

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.

@KitsuneRal KitsuneRal moved this to Future versions in libQuotient 1 Jan 15, 2025
@gerion0
Copy link
Author

gerion0 commented Jan 15, 2025

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.

@TobiasFella
Copy link
Member

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

Maybe I can convince @redstrate to try to figure it out :P

@redstrate
Copy link
Contributor

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.

i'm guessing you want the C++ API to appear async as well right?

@TobiasFella
Copy link
Member

Ideally yes. If we can figure out another way of making things work nicely, that would also be fine i guess

@gerion0
Copy link
Author

gerion0 commented Jan 17, 2025

This suggests that a Rust runtime like tokio is possible but optional (the application can provide such a loop itself).
Also this suggests that UniFFI creates (as part of the overall bindings) a C ABI for the Rust side. Maybe it is possible (while not comfortable) to directly use that C ABI from C++. Are C headers generated as well (so a C API)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A feature or change request for the library
Projects
Status: Future versions
Development

No branches or pull requests

4 participants