I would say the opposite rather, the UX of IRC clients (eg, HexChat) is so polished and refined, it puts all the proprietary chat services (and their clients) to shame.

> Why does open protocol usually mean crippled U/X?

Open is entirely unrelated to that, but optional features means crippled UI/UX in the long run. Some server won't support it so users can't use it, or some client won't support it so they will see garbage/nothing when others use that feature.

XMMP showed that well enough and it seems IRCv3 follows suit.

FWIW TheLounge [1] and Convos [2] can front-end an IRC server giving it much of the look of a modern client and also chat persistence when using TheLounge in private mode. The trade-off in my opinion is scalability. With a bog standard IRCD I can handle tens of thousands of clients per node. Adding web persistent increases memory usage.

[1] - https://github.com/thelounge https://thelounge.chat/

[2] - https://github.com/convos-chat/convos/ https://convos.chat/

Who pays for the UI to be developed?

If open source/community, then chronically starved for resources and contributors have divided directions.

If commercial, then they want to differentiate and do embrace, extend, extinguish, in order to drive everybody to their client.

I have come to believe, that the protocol spec and servers, is just the easy part of chat apps.

In an ideal (and therefore unrealistic) world, it would be done by the UX designer/dev equivalent counterparts of the ones developing these open source softwares.

Why do low level engineers work freely on FOSS but designers or UX devs don't is the question.

Because they have different opinions doesn't mean they are detached from reality. IRCCloud shows images in the feed, for instance. I just like the fact that I don't need that overhead in my client if I don't want it.

Because extremely few programmers which are attracted by creating protocols have U/X design skills.

In fact, they will probably say something like "just use the CLI, it's a superior way anyway".

There should be a way to decouple the UX from the program and if people want a Discord “skin” for IRC that looks nearly 1:1 they should be able to have that.

I don't think that would help. The IRC protocol is missing so many messaging features that platforms like Discord have. Just looking like Discord wouldn't fix that.

This very initiative (IRC 3) seems to be trying to fix that. At least parts of it.

What doesnt it have?

Not sure I get your point. Say you use IRCCloud on your phone, you don't need anything else, do you?

IRCCloud is fine, but it's more expensive than Discord, the UX is not quite as nice for reasons inherent to the IRC model, and it's not really more open in any substantive sense (my phone will be running the proprietary IRCCloud application that speaks a proprietary IRCCloud protocol). So why would one bother?

> and it's not really more open in any substantive sense [...]. So why would one bother?

Not for you, because you want to use a turnkey solution, and you don't want to pay for it (instead relying on whatever model they have where you are the product, I guess?). But if you use IRC to talk to me, I can run my own bouncer for free, and I can run the client I want. I can even write my bouncer and my client, and still talk to you.

That's infinitely more open than Discord. It's just that you don't care about others.

> Not for you, because you want to use a turnkey solution, and you don't want to pay for it (instead relying on whatever model they have where you are the product, I guess?). But if you use IRC to talk to me, I can run my own bouncer for free, and I can run the client I want. I can even write my bouncer and my client, and still talk to you.

> That's infinitely more open than Discord. It's just that you don't care about others.

I care a bit about whether you can run your bouncer. But I also care about whether non-technical people can talk to me without an unreasonable level of effort. Expecting everyone else to pay extra for a worse experience so that you can use it the way you want seems pretty entitled.

> Expecting everyone else to pay extra for a worse experience so that you can use it the way you want seems pretty entitled.

Yeah, the price is an issue indeed. I guess that's why we keep having monopolies: it's easier to get VC money if you can ensure user lock-in, and it's easier to make a nice UX if you have VC money.

Now, don't think you don't pay those proprietary messengers. You just pay differently.

IRCCloud regularly gets stuck, has to be manually reset, doesn’t cope well with network changes and seems to have database overloads once per day.

I use it, but discord’s mobile client is a far better experience.

But this is not fundamentally a limitation of the IRC protocol, is it?

It’s got nothing to do with the IRC protocol. The mobile application is effectively a remote for a client running in their datacenter.

I’m just pointing out that… well, discord has advantages other than the protocol.

Irssi's UX is better than that of any other chat software, though. Why it hasn't been replicated for things like XMPP and Matrix is probably due to the more difficult and featureful state transitions of those protocols.

I switched over from irssi to poezio a few years ago (with a self-hosted biboumi as XMPP<->IRC gateway) and I don't miss irssi (anymore).

Of course, the transition was a bit bumpy, but I think that'd go both ways. As someone else said, it's not a direct replica. Yet, it feels close enough and not too close for the uncanny valley.

There are several XMPP clients trying to replicate -more or less freely- the same experiences, such as poezio [1] or profanity [2]. YMMV of course, and nothing will be a carbon copy of irssi, except if you use a plugin (but in my experience bolting another protocol on top of a client for another will result in a poor UX).

I do believe there are TUI clients for Matrix, but I am unsure of their maturity and state, or how they compare to Irssi.

[1] https://poez.io/en/ [2] https://profanity-im.github.io/

I was going to say, "Have you tried poezio?".

Do any IRC clients support inline media upload/viewing, profile pictures, voice/video calls, or replies/threading? These are the things I would consider the core essentials of IM. Any serious platform has all of this plus a whole lot more.

The web front-ends multi-user clients I linked in this thread support file sharing, image uploading. For voice one could run either uMurmur or Murmur that also provides text and voice chat. People can be given permissions to create channels on Murmur whereas uMurmur you static define the channels as it is meant to run on home routers. There is a phone client for Murmur called Mumla. Murmur also supports file sharing but it was not really optimized for that to be used by a large number of people at once in my opinion. The voice quality of the OPUS codec is incredible. Open source video chat would likely be Jitsi and is a bit more complex.

These are not all-in-one solutions yet and certainly not as low-friction as most would prefer. I expect development to improve in all of these platforms as the centralized platforms go through growing pains and buy-outs.

Even then I would not expect everyone to migrate to these self hosted platforms and in a way I actually hope they do not or those platforms may get the unwanted attention from the powers that aim to protect us from our speech.

I think I would leave any platform that added most of these and that it is better for IRC to stay as-is so people like me have places to chat. People like you already have Discord/etc.

Have you tried IRCCloud?

So to get all or some of those features you can use IRCCloud. Is it the same as IRC having those features?

I could (and do) access IRC over Matrix and then I also have access to those features. But in this case also users not using the same client or same server as I am get to see those things.

Ok maybe I should take them separately:

> Do any IRC clients support inline media upload/viewing, profile pictures, voice/video calls, or replies/threading? These are the things I would consider the core essentials of IM. Any serious platform has all of this plus a whole lot more.

Media upload is purely on the client side. If IRCCloud lets you to drag-and-drop an image, uploads it to some server, and then sends the URL, then that's still entirely IRC (I will receive the URL), but IRCCloud is making it easier for you.

Same for viewing content: I send a URL, and your IRCCloud will show a preview (image/video), while my client won't. That's purely on the client side.

For voice and video calls, IMO I don't want it in my messaging app. I can use my browser for that, or a dedicated app. And again, share a link to my videoconference over IRC.

Replies/threading are a tricky one. I hate the replies in Discord, and I don't really get threads. I see Slack channels where the rule is "answer only in threads", which to me says that they want a forum (like Discourse), not an instant messaging app.

> But in this case also users not using the same client or same server as I am get to see those things.

Pretty sure that if you use replies or threads in Matrix when talking in an IRC channel, then people on IRC won't see them as replies or threads.

> Pretty sure that if you use replies or threads in Matrix when talking in an IRC channel, then people on IRC won't see them as replies or threads.

Replies are rendered to IRC with a prefix indicating what they're responding to, but people from IRC cannot "reply" (though maybe some ad-hoc protocol could be devised for this). I don't know if threads are handled the same way, but I assume they are. Of course you can't really bring either of these features to a platform that doesn't support them without modifying the platform.

By "other servers" I meant other Matrix servers, as it is the system that natively supports the features.

Matrix could bridge tem as IRC replies so at least IRCCloud users could see/write them, but are not interested in supporting them for now: https://github.com/matrix-org/matrix-appservice-irc/pull/150...