The Matrix is my last hope for a free internet.
And that's not even getting into the computational and network problems moving and saving all that state causes as addressed in this very update about how they're trying to mitigate the architectural problems I just mentioned. But they'll only be mitigations. And the legal/social problems will still exist and since everyone (ie, 99%) of people use the Riot.im/Element.io matrix.org homeserver that means social/legal pressures can be easily applied.
I like Matrix. I even use it for video chat because of the sars-cov-2 pandemic. But it is no hope for freedom.
And I say that as a regular on multiple IRC networks, some through Matrix bridge.
Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.
[1] - https://github.com/thelounge
[2] - https://thelounge.chat/
[3] - https://github.com/convos-chat/convos/
[4] - https://convos.chat/
[5] - https://www.mumble.info/
But this doesn't change the fact that irc is obscure minority now, no matter how many shiny web interfaces we put on top of it, so embracing the actually open platform that has a chance of gaining any traction is a no-brainer.
Agreed. I still use it when I need a quick way to chat. That and Devzat SSH chat. I can fire up NGIrcd in about 3 minutes and most of that time is dealing with LetsEncrypt. UnrealIRCD is my preferred IRCD but the configuration is more involved so I don't bother since most people moved to Discord.
Out of curiosity since I have never used Matrix, how many clients can one node/server simultaneously support approximately?
Sorry, I don't know if I'm being honest :) The one I run is used by just few people. Matrix isn't so "internal community" focused like Mastodon in its federation.
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. Check out https://ergo.chat/ with modern clients like https://sr.ht/~emersion/goguma/ (Android), https://git.sr.ht/~emersion/gamja/ https://kiwiirc.com/ (web), or https://git.sr.ht/~taiite/senpai (TUI)
> but in practice using your enhanced server from an unenhanced client will always be painful
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?
"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.
The IRCv3 working group is made of plenty of organizations (non-exhaustive lists at https://ircv3.net/participation / https://ircv3.net/charter) with at most two "representatives" each.
> 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.
Meanwhile, IRC servers: https://www.ircstats.org/servers (note: this counts servers and not networks or users)
> 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 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
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 design and implementations (https://emersion.fr/blog/2022/irc-and-oauth2/).
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.
But you have to admit, irc is a tiny tiny part of IM usage popularity wise, and it's not for no reason.
Curating and sharing links is the same as hosting. And I’m quite happy to be on a platform which doesn’t share or host this content.
> At our request, the EMS-hosted Libera.Chat bridge regularly prunes idle connections to minimize disruptions to IRC channels during bridge restarts.
(Also, only about 35% of users we're aware of are on the matrix.org server, not 99%...)
Most of what you complain about societal pressures either apply to IRC (access to specific servers) or outright fail IRC by default by not providing the feature (state).
To be honest this is probably reason #1 why people stopped using IRC. We want to see the messages that were sent while we weren't here. Yes I know what a bouncer is, no this is not a good solution.
IRC as a protocol is simple and elegant but as a product it doesn't meet today's users expectations at all. And you can't just say users expectations are wrong and they should just align with what IRC provides, it doesn't work like that.
I've been slowly getting wow'ed by the current developments in Nostr, which could be a great, new open protocol for social media. The native implementation of lightning network payments, and the ability to follow paid relays without needing to be bound to them is pretty cool.