Why does open protocol usually mean crippled U/X?
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.
[1] - https://github.com/thelounge https://thelounge.chat/
[2] - https://github.com/convos-chat/convos/ https://convos.chat/
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.
Why do low level engineers work freely on FOSS but designers or UX devs don't is the question.
Gnome is probably the best example of good design in the FOSS space and look how people talk about it. Even in this thread you have people claiming being able to view images and video inline in a chat is an "anti feature". Can you imagine trying to design a product for people so detached from reality?
In fact, they will probably say something like "just use the CLI, it's a superior way anyway".
I use it, but discord’s mobile client is a far better experience.
I’m just pointing out that… well, discord has advantages other than the protocol.
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.
> 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.
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.
I do believe there are TUI clients for Matrix, but I am unsure of their maturity and state, or how they compare to Irssi.
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.
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.
> 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.
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.
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.