A Matrix client built with Rust and Slint
780a9338 — Jeremy Baxter 4 months ago
Add basic building/usage section to readme
6b3e0503 — Jeremy Baxter 4 months ago
Improve language in readme


browse  log 



You can also use your local clone with git send-email.


Your Matrix eigenclient.

Eigen is a Matrix desktop client written in Rust with the help of Slint and the Matrix Rust SDK.

#🎨🖌️ Help wanted for the icon!

As all desktop apps do, Eigen needs an icon. Since we're leaning on the whole (mathematical) matrix stuff, and since eigenvalues are typically denoted with lambdas, I thought the logo could have something to do with it, but I haven't thought much about it yet.

If you have any good ideas or design skills, hit me up on Matrix!




First, proceed with building Eigen. Install Rust and Cargo, then use cargo build -r to compile Eigen in release mode. After Eigen has finished being built, you can run the executable by running ./target/release/eigen.

To run Eigen, you will need OpenSSL and sqlite installed, which you probably already have. Additionally you will need a keyring program to securely store passwords, such as gnome-keyring or KWallet. If you're using a desktop environment such as GNOME or KDE Plasma, this is probably already set up for you.

KWallet users may have to install the QCA OSSL plugin, usually under the name libqca-ossl or qca-ossl in your package manager.



The running joke with Matrix-related projects is to name them matrix-related terms. Eigenvalues and eigenvectors are core concepts of linear algebra, being used to characterize linear transformations. The term "eigen" comes from German, meaning "own". So in a sense, this is your own Matrix client :>

#Why just desktop?

I'm still quite skeptical that you can use one codebase to make good quality applications for platforms as different and diverse as desktop and mobile. I've yet to find a good example.

Seeing as keyboard and mouse driven UIs and touch driven UIs are so different, you'd have to be very thoughtful about it and consider all the edge cases of different device form factors and interface constraints, to write a proper one-codebase-to-rule-them-all GUI. At that point, you might as well just write "native" apps and get proper system integration from the get go.

I think a great way to avoid duplicating a lot of business logic is use something like Kotlin Multiplatform or do what Element is doing and make a library with the core stuff and then call it through FFI on each platform-specific codebase (see Element X Android, for example). In fact, we are using precisely their Matrix Rust SDK to develop Eigen!

For now, the major focus will be on Linux (since it's the platform I use), with Windows and macOS being supported as well, though as a best effort. If anyone wants to help me maintain and test those builds, let me know. I'm also open to making WebAssembly builds, given Slint and the Matrix Rust SDK support it. They are not a priority, however.

#Why Rust?

First of all, I like the language. I have some criticisms, but I like it. It's interesting and mostly forces you to write "correct" code when, for example handling memory, errors or concurrency. It's also quite undeniable that Rust's community and ecosystem is quite big and alive, with lots of competent developers using it, and there are tons of quality libraries that can save us work (and probably do it better), which is always nice and important for an open-source project. And that is probably the most relevant factor: there's a very complete and well-supported library for interacting with Matrix servers. Matrix Rust SDK, under the ownership of the Matrix Foundation, is being used by Element to write the game-changing Element X clients and is the reason I even thought of starting this project in the first place.

#Why Slint?


Rust's GUI ecosystem is quite diverse and rapidly evolving; there are libraries and frameworks for all sorts of styles. Before I thought of starting Eigen, I actually worked a bit on Spectral, a promising but now abandoned Matrix client written in C++ with QtQuick/QML (which was then forked by the KDE folks into NeoChat). I really liked the idea and execution of QML, so when it was time to pick a GUI stack for Eigen, I immediately turned to it (in fact, I even started writing Eigen stuff with it; see commit 1e7cbc96). Despite qmetaobject-rs and CXX-Qt being a thing, they felt like a hack, cobbling Rust and C++ together, and ultimately were quite awkward to work with async Rust (a fundamental part of Eigen, as mentioned above), because of Qt's own event loop. I had my eyes on Slint for a while, but I always saw it as a very incomplete and weird clone of QML, until the end of last year. They made incredible progress during 2023 and when I started playing around with it in December, I was quite pleasantly surprised. After asking around about async support, I was satisfied enough with it and started working on Eigen from the ground up again.

#Why sourcehut?

Now it seems I will contradict one of my points above .^.

Sourcehut is quite the outlier when it comes to software "forges" (i.e. platforms to host code and coordinate development). It does away with fancy JS, bespoke "in-app" comments and the popular Pull/Merge Request system and returns to Git's origins: e-mail. Discussions are carried out through mailing lists, which also receive git-send-email patches, merged with git-am. Triaged issues and goals are transferred over to more normal-looking tickets, still compatible with e-mail.

I chose it because I like the flow, I like the work sourcehut has been doing and technically it allows for easier account-less contributions. Now, I won't delude myself. This is unlikely to work out in the future, if the project gains more contributors, but I still think it's a good experiment. If contributors really don't want to use this system after trying it, I will consider moving to Codeberg.

#How can I contribute? (patches, bug reports, feature requests)

It's very nice of you to want to contribute, thanks! Since we are on sourcehut, GitHub-like pull requests are not a thing, but it's very easy! Take a look at CONTRIBUTING.md for all the whats and hows.

#Why AGPL?

The GNU Affero General Public License is a slightly modified version of the regular GNU GPL which also mandates code distribution if the software is run and accessible on a server. This is to cover the eventuality of making a WebAssembly build of Eigen, since Slint supports it.


This software is licensed under the GNU Affero General Public License v3, the full text of which can be found in COPYING.md.