HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
matrix-org
matrix-rust-sdk
Rust2020–2026
matrix-org / matrix-rust-sdk

matrix-rust-sdk

Matrix Client-Server SDK for Rust

Systems & InfrastructureLibraries & SDKs
Explore on GitHubRead Hacker News discussions
10Distinct people
17Mentions
0Explicit recommenders
2.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Matrix Client-Server SDK for Rust

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2020-08-12 19:28:08 UTC to 2026-02-09 21:52:08 UTC.

0123452020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC404
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC505
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

What Hacker News says

17 sources
erichocean·Jan 29, 2026
If Matrix now supports MLS, you should ask the site owner to update this: https://arewemlsyet.com/ Based on my inspection of the Rust crate [0] as of today, it does not. YMMV. Separately, as you well know, Matrix has its own encryption (Olm, Megolm) that competes with MLS for group chat use-cases. Why you are acting like it doesn't is beyond me. [0] https://github.com/matrix-org/matrix-rust-sdk
In Cloudflare claimed they implemented Matrix on Cloudflare workers. They didn't
Arathorn·Dec 1, 2025
There's a bunch of outdated info in here, unfortunately: > Does not have an admin panel The admin panel is at https://github.com/element-hq/element-admin (but it's relatively new, so many folks haven't noticed it exists) > No image captions > > This is silly, but while (official?) bridges support image captions, official Element app does not. Element Web & X support captions. (Element Web doesn't currently support authoring them, but can display them - obviuosly this is on the todo list though). Element Classic has basically not been touched in 2.5 years, unfortunately, and so yes - doesn't support them. But at this point the old app is just not being developed; we don't have bandwidth to do both. > Slow notifications This sounds like it might be overloaded server problems ftr. > Element X is Slower > Somehow, it is slower. Clicking on
Read the rest
a conversation takes 0.5-1.0 seconds to load it, compared to almost instant load on Classic. This was an Android specific bug which was fixed a few weeks ago; EXA should now be instant as it should be, at least on nightlies: it was stuff surrounding https://github.com/matrix-org/matrix-rust-sdk/pull/5841 and https://github.com/matrix-org/matrix-rust-sdk/pull/5854. Unsure if the fix has made it into a build yet. EDIT: the fix shipped in stable Element X Android a few weeks ago. > Conversations are sorted by... who knows. It is not recent nor alphabetical. It should be by recency. > Onboarding is bad Sorry, but you have to run an auth server (matrix-authentication-service) if you want Element X to work. EDIT: if i've got any of the above wrong please just say, rather than downvote :D
In Self-hosting a Matrix server for 5 years
jbaiter·Nov 20, 2025
I tried implementing a Matrix bot a few months back, and it was an absolutely miserable experience, since Device Verification/E2EE was not working with any of the available open source Python implementations I found. I then stumbled upon their internal Rust SDK[1] that they use for Element X, which is actually quite nice, and even has FFI bindings for Python and Kotlin[2]. Unfortunately the documentation was really lacking at the time. I managed to put something together with the help of an LLM and the source code and examples to find my way around the various APIs, and it actually works with emoji verification and E2EE (although there are weird bugs around synchronization, but that's probably just an API misuse on my end). It seems they've improved the documentation since and even provide a reference client[3] to see how things work. [1]
Read the rest
https://github.com/matrix-org/matrix-rust-sdk [2] https://github.com/matrix-org/matrix-rust-sdk/tree/main/bind... [3] https://github.com/matrix-org/matrix-rust-sdk/tree/main/labs...
In Verifying your Matrix devices is becoming mandatory
Arathorn·Apr 2, 2025
Telegram certainly has an excellent UI/UX. On the Element side, its quality bar has very much been the target for Element X - and (in my biased opinion) we are getting very close, if not exceeding it in some places. For instance, we just landed The Event Cache in Element X and matrix-rust-sdk (https://github.com/matrix-org/matrix-rust-sdk/issues/3280 - closed 2 days ago after a year of solid work), which provides seamless offline support and local encrypted-at-rest caching of the messages it's seen, which in turn then makes the native SwiftUI and jetpack-compose UIs go brrrrrr.
In Matrix.org Will Migrate to MAS
erlend_sh·Sep 29, 2023
Matrix (primarily developed by the Element company) is rewriting its mobile apps based on a common SDK and rich text editor written in Rust: https://github.com/matrix-org/matrix-rust-sdk https://github.com/matrix-org/matrix-rich-text-editor The apps themselves are written in Swift and Kotlin respectively, but it’s notable that they can now do this duplicate work much more sustainably because the bulk of their app code lives in a unified Rust layer.
In Crux: Cross-platform app development in Rust
Klonoar·Nov 21, 2022
>Well I care, that does not mean that you have to care. The point I'm making is that the protocol being implement-able by yourself or grabbing a lib from someone else is moot, since you will 9 times out of 10 use a library. >Again, look at the lack of client diversity for Matrix and tell me that you do not think that there is at least some correlation in terms of the complexity of the protocol. The problem is not client diversity for Matrix - there's plenty of them. The problem is that Matrix is more than displaying a log on a screen, and most of the clients are frankly abysmal and could use a trained UI/UX owner. >last I checked it meant using either Python or Go The Rust SDK has worked well for me, although I can't state how close it is to Python or Go's libs. That said, I know I'm certainly not the only one using it. The Rust lib could
Read the rest
be wrapped into other languages (e.g, Ruby) if there's not a good SDK for that language. I don't really consider this to be an issue, especially considering the Rust SDK is maintained by the Matrix org themselves. https://github.com/matrix-org/matrix-rust-sdk >Add to this that the more mandatory features you have and keep adding Don't maintain your own bespoke library and you won't have to. :) >But I am not going to behave as if images, reactions, code blocks, threads, end-to-end encryption, voice calls, video calls, etc. do not come at a cost. They do come at a cost, but that's the price of admission for what people expect from modern chat systems. I'd rather live in 2022 than 2004, and I grew up on IRC.
In IRCv3 2022 Spec round-up
twicetwice·Aug 27, 2022
Element [0] is the main/most popular client. FluffyChat [1] is also good. They both have web, Android, iOS, and desktop (Electron) apps. There are at least a dozen other clients but those are the only two I've tried so far. For hosting, I believe the flagship host is Element Matrix Services [2]. It's made by the same organization that leads development (it is all FOSS) of Element and the reference server Synapse. You can also self-host. Synapse is pretty slow and memory-hungry (it's written in Python), but for a small group it still fits pretty comfortably on a $5 DigitalOcean VPS. That's what I'm doing. It took less than an afternoon to set up (`apt install synapse` and then setting some config, mainly—there are a bunch of good guides online) and has been happily running ever since. Matrix is federated, so as long as you set up federatio
Read the rest
n properly, you can seamlessly message anyone on any federated Matrix server. (Federation is opt-in.) There's also Dendrite and Conduit, Matrix servers written in Go and Rust respectively, which are much leaner and faster. Both are still in beta and missing some features, but are definitely usable. If you want to mess around with bots, I've had a lot of fun with both the Matrix Rust SDK [3] and JavaScript bot SDK [4]. Both are quite easy to get started with, and as of a few months ago both support E2EE pretty painlessly too (not totally pain-free though lol), which is cool. Overall, the ecosystem is still maturing imo, but I've been using self-hosted Synapse and Element "in production"—it's me and my girlfriend's primary method of communication—for over a year now with only some minor UX hiccups (mostly issues decrypting E2EE messages in Element). I definitely encourage giving it a shot as long as you're willing to tolerate a few remaining growing pains. [0]: https://fluffychat.im/ [1]: https://element.io/get-started [2]: https://element.io/matrix-services [3]: https://github.com/matrix-org/matrix-rust-sdk [4]: https://github.com/turt2live/matrix-bot-sdk
In Slack’s free plan change is causing an exodus
hkalbasi·Jan 30, 2022
> Apparently, not all tooling has access to sophisticated language servers; for example, as far as I can tell GitHub source analysis won't be able to find where write_u16 is coming from, and the same is true of Sourcegraph. FYI, Sourcegraph supports LSIF generated by rust-analyzer. For example, https://sourcegraph.com/github.com/matrix-org/matrix-rust-sd... shows lock method belongs to tokio. It should be able to show origin of write_u16 as well (In the precise mode, not search based). Gitlab can also consume LSIF, and github should do it someday, IMO, their current way doesn't scale. In most languages you should implement a full compiler front end in order to provide a 100% correct goto definition.
In Rust extension traits, greppability and IDEs
Arathorn·Sep 13, 2021
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 imp
Read the rest
lementations, each with their own bugs and increased audit surface, we're hoping that matrix-rust-sdk will simplify this a lot in future.
In Disclosing E2EE vulnerability in multiple Matrix clients

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.