IRC isn't bare. You're just looking at it wrong. IRC is the text communication layer of the internet which is the platform. Centralizing all functions into one protocol is not a great idea.
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.
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.
> 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.
Thank you for the links, I prefer to use Matrix(Element on mobile and gomuks in cli on workstations), I also use weechat for certain networks that don't allow bridging with matrix, I also bridge slack into same weechat.
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.
But this doesn't change the fact that irc is obscure minority now
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?
>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.
The world has also moved beyond just text 20 years ago and we were all supposed to switch to Jabber/XMPP. And yet here I am using IRC as much as ever. If I end up using Matrix it will probably be from my favorite IRC client through some kind of gateway, just like all the IM protocols that have come and gone over the decades.
Why is it not a great idea? It’s what every other platform has done for over a decade now and it’s working great. It’s absurd that I shouldn’t be able to send someone an image inline or make a call in a group chat.
And now the server is hosting images and has to police that or it gets shut down. And suddenly content moderation is #2 priority for the service, behind #1 profit, but well ahead of providing a space for communities.
Nope. No one has to or is policing the links people chat about on IRC. Why? Because the server isn't saving state and hosting it. It's all in people's clients. It cuts the gordian knot of content moderation.
