matrix-rust-sdk VS conduit

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.

I'd like to suggest Conduit. I found it very easy to install and maintain. https://gitlab.com/famedly/conduit

> "At least as standard" how?

There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.

> A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on.

But any IRC client will work fine on any IRC server, and they can connect to various servers with different implementations.

On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following exactly the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.

It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".

> And there seem to be more visibly independent implementations of Matrix than IRCv3.

Clients, maybe, at least in the number of implementation. It's hard to find stats of this, but I feel that >95% of people in the public federation use Element even in tech-y rooms; IRC has a healthier mix of major clients (weechat, irssi, IRCCloud, Hexchat, KiwiIRC, The Lounge each have >5% of desktop/web users). But I admit that's just my very subjective point of view.

In terms of servers, Matrix has three open source ones as far as I know: Synapse (controlled by Element), Dendrite (controlled by Element, and almost on par with Synapse according to https://arewep2pyet.com/ ), and Conduit. Based on https://gitlab.com/famedly/conduit/-/milestones/3 , Conduit seems to be far from implementing the spec yet (eg. it doesn't seem to support leaving rooms or respecting history visibility).

> things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps)

You can use https://ircv3.net/specs/extensions/message-ids to deduplicate them.

> And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs.

A conversation where people where people are using embedded gifs will exclude me regardless of client, because they are too distracting. At least on IRC I can expect people not to do it too much, and use words or emojis instead of reaction gifs.

> SSO access control; you just can't do that in a nice way if the client doesn't support it

That's a fair point; IRC is made by hobbyists more than companies, so that's not surprising. There is some discussion around it though: https://github.com/ircv3/ircv3-ideas/issues/74 and Sourcehut is sponsoring implementation (https://emersion.fr/blog/2022/irc-and-oauth2/).

To start, this will be strictly Non-Federated. Just a few friends will be using this. Here: https://gitlab.com/famedly/conduit/-/blob/next/DEPLOY.md is the documentation I am following. It tells me I must "use my server name", but what is this exactly? What do I put in there? Do I have to go out and buy a domain?

Either Tinode (https://github.com/tinode/chat) or Matrix Protocol (https://gitlab.com/famedly/conduit)

Matrix Protocol: Fractal (Client), Conduit (Server)

If self-hosting is an option then I'd say Matrix, you can try Conduit (server) and Elements(client). To simplify deployment you can refer to this repo.

You can babble on and on about how its not how you do it, no one needs it, etc... But its a demonstrable need in this space and its caused me great pain trying to write applications that would be used by such people. It's even bit Conduit to the point they have 5+ DB backends coded in now that the user can choose between based on their local system setups.

Give Conduit a try. It uses way less memory than Synapse. It is still in early stages but works great. I have been running one on a Pi4 for like a year, going great so far.

There's a Rust implementation of a Matrix server that uses sled: https://gitlab.com/famedly/conduit/