ircv3-ideas VS element-x-ios

> "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/).

Element X is not finished or intended for average users yet, as https://element.io/labs/element-x makes clear. It’s a preview of the future of Element.

Matrix itself is a big messy thing, much like the Web - this is both its power and a potential weakness.

Element X is indeed a fancy new client - but it hasn't hit a 1.0 yet. Think of it a lot like Firefox was pre-1.0; it's unrecognisably faster and better than the previous generation... but not all features are there yet. Meanwhile, there are loads of entirely unrelated independent excellent clients out there too; it's not just about Element v Element X.

> But I wasn't able to set up the encryption with my recovery key, there was only the online validation which I couldn't use because I was on the go and didn't have access to my desktop.

This bug is an accidental thinko however: it's placeholder UI which is about to be replaced by implementing login-via-scanning-QR-code (which is almost there), but obviously that also needs the ability to enter recovery keys too. Eitherway, it's being fixed: https://github.com/element-hq/element-x-ios/issues/2424

> also seems to still lack TOFU for my private server

Yup, sorry, TOFU for TLS isn't implemented yet in EX.

> The same with the homeservers, there's synapse and dendrite is supposed to take over at some point but that point is forever far in the future. And then there's conduit, so which one is it?

Synapse is a stable server where the core team is putting its effort currently. Dendrite is a 2nd gen server from the core team, but is beta and a) ended up being focused on P2P and embedded homeservers and experimental MSCs, b) is starved of resource atm due to funding pressure (c.f. https://www.youtube.com/watch?v=s5BrVVf0B1I&t=316s). Conduit is an independent server implementation in Rust, which is promising but beta.

It's like asking whether you should use Apache httpd or beta versions of nginx or lighttpd in the early days of the Web.

> The strategy doesn't really feel well thought out in that sense.

The strategy at Element (which employs most of the Matrix core team) is pretty clear right now:

1. Improve Synapse as the most mature and stable server implementation (and package it in Element Server Suite for those needing an enterprise Matrix distro: https://element.io/server-suite)

2. Finish implementing sufficient features in Element X that it can replace the old classic Element mobile apps asap - converging on a single Rust codebase, so that bugs & audits & new features can all land in one place.

3. Keep building Element Web/Desktop and Element Call.

...and that's it.

If it seems confusing, that's either because we're in the middle of the Element -> Element X shuffle... or because the nature of Matrix is that there's loads of other independent implementations running around too. But that's what makes it fun, too :)

i’d have been in danger of agreeing a year ago, but thankfully we proved otherwise with Element X: https://element.io/labs/element-x. Bit embarassing that we didn’t get there sooner, but human fallibility and all that.

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

And the cake under the cherry is… Element X is open-source[1][2]!

I really can't wait for Beeper[3] to rebuild their fork on top of Element X (it's currently based on Element, formerly called Riot). If this happens this will be an absolute game-changer in the messaging ecosystem.

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

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

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

Yes, eventually. Right now the sliding sync MSC is still in flux (e.g. we just realised today that it's missing an explicit flag to notify once the client has caught up with the server, rather than guessing via heuristics: https://github.com/vector-im/element-x-ios/issues/1269#issue...). As a result, the implementation (which is in golang) is being kept separate from Synapse for now while we iterate on it; plus it's a separate set of folks working on it. This also means that SS can be used with any existing server (dendrite, conduit etc) as needed.

It'll get added natively to Synapse eventually, but it'll likely be quite a way off.

Element X is an entirely new client written in Rust + Swift UI/Jetpack Compose (https://github.com/vector-im/element-x-ios and https://github.com/vector-im/element-x-android) which will eventually replace the legacy Element apps (https://github.com/vector-im/element-ios and https://github.com/vector-im/element-android).

The features already exist serverside; we're just working on getting them out of beta.

Yep, it's definitely been frustrating in the past. The number of iOS Element bugs was overwhelming at times too. It's a lot more stable now, but the bubble layout still isn't the default - I think that's what most people expect from a personal messenger. I'm looking forward to seeing what the Rust rewrite [1] brings for performance/stability.

FluffyChat also has quite nice UX and a bubble layout by default, but threads are still a while off [2]. On iOS it worked flawlessly through the iOS 16 betas while Element had some show stopping bugs, a couple of my friends moved over if they were on the beta.

I haven't had any friends ask me about the verify session buttons. I don't see any prompts on latest iOS Element but it's still too prominent on Element desktop for my liking.

SchildiChat [3] is my daily driver and feels more friendly than Element on desktop (unified DMs & group chats, no verify UX, chat bubbles), but it doesn't have any update mechanism built in, so I'm wary to recommend it to non-technical friends. It was also my goto recommendation on Android before the Element redesign.

I'm confident the ecosystem is moving in the right direction though, and so thankful for the amount of choice.

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

iOS is still not great, but they are making a new one.