matrix-rust-sdk VS gomuks

Yep, a good example is the element X rewrite

They use Jetpack on Android

https://github.com/vector-im/element-x-android

And SwiftUI on iOS

https://github.com/vector-im/element-x-ios

But both use the same underlying Matrix Rust SDK

https://github.com/matrix-org/matrix-rust-sdk

So they share the core part of the app between platforms, but everything user facing is native

The one place eyebal is already being used is matrix-rust-sdk, mostly for bits of the API that act as a model for specific UI parts in apps built on top of it. A part of those APIs is also using observable vectors from eyeball-im, which I didn't mention initially because it's not as well-documented and polished.

Hello everyone, I am finally making it to all of the great talks about Matrix from FOSDEM 23, and one thing that seemed like an obvious thing that could be built on some of the new projects works (matrix-rich-text-editor, matrix-rust-sdk) is a collaborative (multi-user, live edits) document tool built ontop of rust. That said, I haven't seen any project doing this yet. Does anyone know of one?

Another important piece of the ecosystem for which Rust was used is the SDK. This new SDK was used to write the newest mobile client - Element X. The current Element client will also see its cryptography implementation being changed from Javascript to Rust, this was also made possible by the new Rust based SDK.

Let's say I'll switch as soon as they start using Sanakirja. They're partially right in their analysis of Sanakirja, but their comments are more about the lack of expressiveness of the unsafe keyword in Rust than about Sanakirja itself. I'm preparing a blog post about my dream version of unsafe.

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

I'm not entirely sure what I plan to use Rust with at the moment, however my first project so far has been to write a Matrix bot using the matrix-rust-sdk library :)

Just for everyone else reading, the modern Matrix Rust stack referred to here is the matrix-rust-sdk: https://github.com/matrix-org/matrix-rust-sdk

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 implementations, each with their own bugs and increased audit surface, we're hoping that matrix-rust-sdk will simplify this a lot in future.

The problem with this is that this is just fundamentally untrue. There are plenty of non-Electron apps that are viable. For core functionality of e2ee, messages, exploring directories, sending images, etc, those are available in multiple alternative apps. If you're talking about other integrations like video calling, plugins, and spaces, then you'd be right as I don't know other clients that have those. But, none of those things are really required in the matrix protocol anyways, and those available features in other clients already far surpasses what IRC can do. You don't need these bleeding edge features to have an enjoyable experience on Element, and given the IRC crowd, I would assume they're adverse to bleeding edge anyways. If you want an experience similar to irssi, then you can use gomuks for a superior experience in a familiar(ish) client. So saying Element is the only suitable client implementation is outright false.

There's also a nice terminal client called gomuks.

gomuks is probably the most feature complete one.

gomuks is a command line-based Matrix chat client

I am running my own home server, everyone in my family has an account they use there (the domain is our surname). Non-techy people use it and like it (past the initial setup, since setting up a custom domain requires a few more clicks than :matrix.org account). I am not waiting for the day, though, when they will need to set up a new device without access to the old one.

> I personally haven't met any "real" people who are even aware of Matrix. When I broached it with a non-IT friend, they were actively uninterested in unifying messaging applications as they had "facebook friends" and "whatsapp friends" and interacted with them differently.

I tried to sell it too with the "unify your messaging apps", but this is a wrong selling point to new users. First they need to start using matrix as their messaging app, realize that it works well, including VoIP and video calls. Once trust is there, only then start thinking about using bridges. Because there will be rough edges (e.g. federated voice/video calls do not work).

Because of the way bridges integrate to third-parties, they are not bug-free. Reliability is just not great yet. Maybe except a hosted service, Beeper[1], which is run by people who know most about these bridges and can provide support.

To sum up, I am using Matrix for my family network, and some bridges personally; I am not yet planning to spread the use of bridges beyond myself. Besides the encryption setup, I like the UI a lot. I also use gomuks[2] from time to time, which is a terminal matrix application. I have not stumped into server-side problems.

I am donating monthly to Tulir[3], the most prolific Matrix bridge developer (and, to my knowledge, co-founder of beeper). Because I started using Matrix because of the bridges.

Oh, and I love the Matrix sms bridge[4]. I set it up to see if it works, and I am not going back. It's great.

[1]: https://www.beeper.com/

[2]: https://github.com/tulir/gomuks

[3]: https://github.com/tulir

[4]: https://github.com/tijder/SmsMatrix