> For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.
At that point you've just reimplemented a less-standard version of matrix with extra steps though. Your protocol has become heavyweight and non-standard (you could argue it degrades gracefully to IRC, but in practice using your enhanced server from an unenhanced client will always be painful), you're holding state on the server in the same way you were worried about (and without the mitigation of E2EE)...
> There are IRCv3 specifications that allow this richer experience, and they are at least as standard as Matrix.
"At least as standard" how? 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. And there seem to be more visibly independent implementations of Matrix than IRCv3.
> IRCv3 normally makes sure new specs don't make it worse for older clients. Could you give me some examples to see if we can fix that?
Speaking generically rather than IRCv3-specific, 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). 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. (Or for a more serious example, SSO access control; you just can't do that in a nice way if the client doesn't support it). This kind of thing is what killed the Slack IRC gateway, and it comes back to the first point, because it's ultimately more of a social issue than a technical one: a substantial portion of the IRC community uses clients that don't support these things not because they can't but because they're hostile to the very idea of having embedded gifs or SSO in IRC.
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 simultaneously connect to various servers which support variants of the protocol (eg. through capability negotiation). Also note that 75% of servers support IRCv3 capability negotiation: https://www.ircstats.org/server-features/cap (and the others are often at all not developed anymore)
On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following 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). And I can't think of any non-Synapse server, besides Matrix devs self-hosting.
> 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)
> 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 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.
Speaking of which, Matrix does not provide a way to provide alt-text to images and videos, which ends up excluding plenty of people as well. (To be specific, the spec technically does provide a way, but clients use it for filenames instead: https://github.com/vector-im/element-web/issues/22100#issuec... )
> SSO access control; you just can't do that in a nice way if the client doesn't support it
> 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.
There is a bunch of missing context here. Firstly, Matrix predates Element. When the team who created Matrix set up the Spec Core Team, we deliberately went for a 4:5 mix of folks from the founding project team mixed with folks from the community. Specifically: me (Matthew), Dave, Erik and Rich from the original team, and Hubert, Travis, Andrew, Alexey and mujx from the wider Matrix community. At around the same time, the original Matrix team set up Element as a way to try to fund us to work on Matrix as our dayjobs.
The catch however is that Hubert/Travis/Andrew got so enthusiastic about Matrix that they wanted to do it as their day job - and at the time, Element was the only place you could do that, and so they applied to work at Element. We reasoned that the best outcome for Matrix would be if they were able to work on Matrix fulltime, and so prioritised that over the heterogeneity of the Spect Core Team. They were explicitly asked to participate in the SCT discussions with their community rather than Element-employee hats on, though, and they continue to do so.
Finally, the actual Guardians (Directors of the Matrix Foundation) who ensure that the project remains neutral are 3:2 mix of independent v. Matrix founders. So if anyone thinks that the SCT is deviating from its neutrality, they can and should appeal to the Guardians, who then have the ability to shake up the SCT as needed.
So yes, this is more complicated than a simple 'design by committee' approach, but I'd argue that it gives the ability for the protocol to evolve more rapidly and with less bikeshedding - and meanwhile we have the checks & balances to keep things on track.
> This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.
The official room versions are defined by the SCT; nothing to do with synapse devs. It's the SCT which prevents fragmentation. Synapse and other homeservers can (and do) go wild experimenting with different room versions.
> 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".
Yes, it's very common for people to complain that their favourite feature hasn't been added to the spec yet, or that their unsolicited PR to Element got wedged because the Element team is trying to build a focused coherent app rather than a kitchen sink.
On spec stuff, the solution is to implement the feature anyway on a prefix, demonstrate its usefulness, and then the MSC is easy to unblock. On unsolicited PRs to Element, the solution is to demonstrate it on a branch, or fork, or implement it on a different client. Again, features which have been proven to work well in the wild are easy to incorporate into the official spec.
At that point you've just reimplemented a less-standard version of matrix with extra steps though. Your protocol has become heavyweight and non-standard (you could argue it degrades gracefully to IRC, but in practice using your enhanced server from an unenhanced client will always be painful), you're holding state on the server in the same way you were worried about (and without the mitigation of E2EE)...