Well. I'm interested to see what you think is a suitable protocol for business.
I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things.
So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.
I'm not very familiar with all of the chat protocols, but I'm familiar with the possibilities of communication today. It's riddled with proprietary protocols and chromium based applications. And that's why I see Matrix as the next step.
> So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.
That’s why IRCv3 is a thing, slowly replacing the hacks with proper specs. No more NickServ, but instead SASL and account-notify. No more guessing where some batch of messages ends, but a batch message type.
> It's riddled with […] chromium based applications.
So is Matrix.
I’m not saying Matrix is bad, Matrix has some awesome properties (especially regarding encryption). And maybe someday it can become awesome, once it gains a proper binary transport system, which is more efficient and keeps a single socket open. And maybe then, we can finally replace IRC, XMPP, etc.
But until then, I’ll keep working on improving IRC.
>I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things.
Let's take those each at a time, shall we?
>Emojis
This has nothing to do with the protocol. If you can send arbitrary UTF-8 messages (which you should be able to do, obviously, and can with modern IRC clients) then you can send emojis to your heart's content.
>Search
I've never personally found search particularly useful, but there's nothing about IRC that makes it any harder or easier to search messages. The way all chat search works and will always work is that you log chat messages somewhere and provide a way to search them. That has nothing to do with the protocol and everything to do with the server logging messages.
You can then extend your chat protocol with a command that you send to the server that asks it to search the current channel (or all channels, or all channels I'm in, or all channels I've been in, or all messages sent in all channels that I was in at the time, that's up to the server though - corporate probably want the former, public you'd want the last one) for a particular string/regexp/whatever.
There's nothing particularly complex here from the perspective of the chat protocol and in fact it would be simple to extend the IRC protocol with a command for doing this at the protocol level. It's just much easier to write bots to log messages and web interfaces to search those logs with.
>Session persistence
No, nobody wants this. What people want are to see messages sent while they weren't there and to be able to receive messages while away. The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.
>Web client
There are lots of IRC web clients, and all you need for this is a simple protocol.
>So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.
IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.
Are you serious? I think lots of people do. I think it's one of the draws of Slack.
> The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.
Is that what Slack does? Whatever they do, I think it's what people want. Indeed it is not an experience offered by IRC, perhaps because "most IRC servers don't want" to, sure.
>Are you serious? I think lots of people do. I think it's one of the draws of Slack.
No it isn't. What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc.
>Is that what Slack does? Whatever they do, I think it's what people want. Indeed it is not an experience offered by IRC, perhaps because "most IRC servers don't want" to, sure.
Slack has a much higher barrier to entry than IRC and most people using it are private companies.
IRC servers are publicly accessible and publicly accessed. They have existed for much longer. If Freenode stored every message ever sent on Freenode that would be a nightmare.
Also, 'only if you're a nerd' is very silly. We're talking about this in the context of open source software. Everyone that is capable of non-trivially contributing to open source software is more than capable of operating an IRC client.
In fact, if you can't work out IRC then you're almost certainly too silly to be a programmer.
>Only if you're a nerd. Took me 5 minutes to get started with Slack for our company and managing it is a piece of cake.
Slack requires you to make an account on their website, a new account for every Slack group. IRC you can just join - pick a nickname and type the server's address and you're in.
IRC is completely trivially easy to use, Slack is not.
Setting up an e-mail address and a password is not an incredibly complex task. I have 3 seperate slack groups that are set up just for friends to chat.
Besides which, on most IRC servers, you're going to be using NickServ anyway, which is more complex a flow than setting up a user on Slack.
> What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc.
Okay, to me that is the same thing as 'persistent sessions', but without belaboring the point... can IRC do those things? Right, it depends on the server and client. What servers and clients can? I think it's pretty rare, if it exists.
If your answer is "well, IRC _could_ do that, if only more reosurces were invested in it to make it so", okay, but so what?
You're missing the point. This subthread is not about what IRC does do, it's about whether a chat protocol with support for persistent sessions, search, etc. can still be simple.
Maybe actually read the thread next time? So don't "so what?" me. This isn't about whether IRC can do those things.
Okay, good luck convincing people not to use slack because some hypothetical thing that doesn't exist could have the features they want, while being simpler than Slack and open source. That's your point?
Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2].
>>Search
You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features.
>>Session persistence
>No, nobody wants this.
Really? Are you sure?
> The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.
Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features.
>>> Web Client
IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about.
>IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.
Honestly, I might sound ignorant, but I've never ever heard of DCC file transfer. And matrix has implemented E2E encryption in some of their clients(all the major ones), and implementing them in the rest is a priority. I don't ever thing IRC will have this. I'd be glad if I was wrong.
Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about.
One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to?
Or do you want to ignore them so that they continue using a closed messenger and wonder why they're dominating the mindshare today?
Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.
>Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2].
What a load of crap. Emojis are simply sequences of Unicode code points. IRC supports UTF-8. A client with a button that brings up a big list of emoji is trivial to build.
>You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features.
That's irrelevant. You claimed that the simplicity of the IRC protocol was something unobtainable with those features. That's what I am disputing.
>Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features.
It's precisely about whether it's possible. You claimed that simple protocols for chat were not compatible with the features you listed.
>IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about.
I agree that IRC was never intended to be run in a browser and doesn't run in a browser well. But that is irrelevant.
>Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about.
Nobody is fucking boasting about anything. The point is that all of what you mention is easily possible with a simple protocol. "We should all use slack because simple standardised protocols can't do X, Y and Z" is FUD.
IRC has really complicated features like file transfer. So I don't think that IRC is being held back by an inability to implement things that require a complex protocol anyway. But even if it were, what you mention does not require one.
>One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to?
What are you talking about? I haven't said anything of the sort.
>Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.
Very, very few OSS projects have moved to slack. The vast, vast majority use mailing lists, forums, IRC if they use anything other than GitHub. Most people just use GitHub issues and email, not even mailing lists but plain email.
>I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.
The vast majority of this thread, as I see it, is the opposite: bashing IRC, a protocol that has been successful for a long time, is open, is inherently distributed and which there are many clients on many platforms for, while going 'look at how awesome [thing nobody uses] is!!'
Also the majority of IRC users aren't using freenode and the use of IRC by OSS is a tiny portion of the total use of IRC.
The point was it isn't built, where as there's auto completion support for emojis which wouldn't even need that "trivial" software. That's in the matrix's sdk. If it's so trivial, please, build for the IRC community. I use hexchat on my desktop and weechat on the server. Would you mind building me one if it is trivial?
> That's irrelevant. You claimed that the simplicity of the IRC protocol was something unobtainable with those features. That's what I am disputing.
Fine, I concede. But I'm surprised you're still going for this. I tried out a bunch of different IRC applications and couldn't find search in any. Oh well.
> It's precisely about whether it's possible. You claimed that simple protocols for chat were not compatible with the features you listed.
My argument was about the ecosystem and the applications and the contributors worked on those applications. You can extend any protocol to worked with other servers and your own extensions to work with your own version of the server code.
If IRC protocol is so amazing, then do you have a reason why it is constantly changed? I've seen it adopted to XMPP, Jabber and others. No sane person today will use the default IRC protocol in an application they intend to keep proprietary.
Discussing what's possible is a waste of time because any feature can be built given time and effort. The point is how easy and how maintainable/stable. More importantly, is it available now?
>I agree that IRC was never intended to be run in a browser and doesn't run in a browser well. But that is irrelevant.
I don't understand your logic. Why isn't something running well in a browser irrelevant? Do you expect everyone to use the command line or native applications all the time?
> "We should all use slack because simple standardised protocols can't do X, Y and Z" is FUD.
Huh. Well I wonder why there are sizable OSS communities moving to Slack. What's your take on this?
> So I don't think that IRC is being held back by an inability to implement things
Then why aren't we seeing the features that are in Slack in any IRC client? It's obvious people want the features in slack. Session persistence is an important feature for people in most OSS projects I've seen using slack.
> What are you talking about? I haven't said anything of the sort.
Oh come on. Your response to many of my points was basically 'it's possible', but not about if it is available today. If I were a non-technical user, what should I do if I want those features? I would just move to slack if there's nothing better than IRC out there.
>Very, very few OSS projects have moved to slack
It's true that many OSS projects didn't move to slack, but that's just because of inertia. Maybe we just look at different OSS projects, but many of what I see use slack, and the numbers aren't going down. Slack itself talked about how there are lots of OSS projects choosing slack and it's straining them .
Here's an article about OSS usage of slack[1]. Note how OSS projects are trying to mimic slack, not IRC. There's a reason for that, and you're conveniently ignoring that. Here's a discussion where you can see many people talking about the shortcomings of slack and why how IRC is failing them.[2]
There are bunch which I personally use, like Monero and Golem project. The problem is that the total number is rapidly increasing.
>a protocol that has been successful for a long time, is open, is inherently distributed and which there are many clients on many platforms for, while going 'look at how awesome [thing nobody uses] is!!'
No one is arguing about it's openness or success in the past. Just that it's time to move on.
>Also the majority of IRC users aren't using freenode and the use of IRC by OSS is a tiny portion of the total use of IRC.
IRC is in use for a very, very long time. No doubt. But you must be joking if you compare that you use of slack. There are so many people and companies (who could've used IRC by hosting it themselves) that it eclipses the use of IRC.
Slack is a widely used product, but its use is tiny compared to IRC. IRC isn't just tech people, it's very widely used by a really huge, diverse range of people.
Your original comment said 'the days of simplistic IRC protocols are gone' and then you gave a bunch of features with the implication that simple protocols can't handle those features.
I simply explained why those features are absolutely implementable over simple protocols, and also why IRC isn't actually a simple protocol - DCC is an example of something not at all simple in IRC.
I didn't say that IRC itself, in its current incarnation, solves those problems.
Ultimately you're basically saying 'I want a couple of features and because slack provides them, I'm going to justify my use of slack by comparing slack to the least featureful chat thing out there: IRC'. IRC's strengths aren't its features, it's its openness, familiarity, hackability, conceptual simplicity and community control. In fact, the things people that like IRC dislike most about it are the few parts that aren't open, hackable, simple or controlled by the community.
I don't particularly like IRC as a protocol. Maybe its time has come, maybe the replacement will be called 'IRCv3' or 'IRCv4' or called something else. Whether that replacement is called 'IRC' is not important. What is important is that it remains open (in spirit and in practice), hackable, simple and controlled by the community. Slack replaces a distributed, network-failure-proof system (IRC) with a centralised, corporate-controlled, paid, closed, proprietary solution. That's the worst possible collection of properties. Yeah you can search messages, yes it has a nice user interface, but that's about it.
>The point was it isn't built, where as there's auto completion support for emojis which wouldn't even need that "trivial" software. That's in the matrix's sdk. If it's so trivial, please, build for the IRC community. I use hexchat on my desktop and weechat on the server. Would you mind building me one if it is trivial?
I can't tell if this is a joke. This is literally:
1. map names to emojis
2. autocompleting input field on those names
3. append a couple of bytes to a string
This is 100% purely a user interface feature, it has nothing at all to do with the server or the protocol. You could implement this for literally any chat client that supported UTF-8 quite easily.
> it's very widely used by a really huge, diverse range of people.
Well you must be around cooler people than I am. Today, if someone wants to start a group chat with persistence (I'm surprised you seem to think this is useless), without having to bother with setting up their own server, IRC will not be on that list. But there is a large group that wants this, and its increasing, because people don't want to bother with a bouncer.
> Your original comment said 'the days of simplistic IRC protocols are gone' and then you gave a bunch of features with the implication that simple protocols can't handle those features.
This is a bit similar to FORTRAN's situation. FORTRAN can still do the things C++ can still do, but you don't see people using FORTRAN. IRC is a simple protocol and is simple, until it has it be used for increasingly complex features and also being adopted for the web requires all sorts of proxies and workarounds.
> I didn't say that IRC itself, in its current incarnation, solves those problems.
What are you saying then? You said people can use IRC now for all the features I talked about, but then now you changed your stance.
Then what solves those problems? I think Matrix solves those problems, so what do you think is a better alternative? Does it have a community comparable to matrix? Say so and I will switch right now. The guys working being matrix know what they're doing. HTTP transport isn't the fastest, but it is simple to implement for a web developer. And with more and more people preferring in-browser clients, I saw HTTP as a good choice.
> Ultimately you're basically saying 'I want a couple of features and because slack provides them, I'm going to justify my use of slack by comparing slack to the least featureful chat thing out there: IRC'. IRC's strengths aren't its features, it's its openness, familiarity, hackability, conceptual simplicity and community control. In fact, the things people that like IRC dislike most about it are the few parts that aren't open, hackable, simple or controlled by the community.
Are you aware of what my first comment you replied to was about? I was replying to someone talking about how Matrix is a 'bad protocol for business', further saying:
>I don't think you're very familiar with chat protocols if you think it's even remotely suitable as a replacement for IRC.
I never recommended slack. Completely against that actually, and I'm rooting for matrix.
> I don't particularly like IRC as a protocol. Maybe its time has come, maybe the replacement will be called 'IRCv3' or 'IRCv4' or called something else. Whether that replacement is called 'IRC' is not important. What is important is that it remains open (in spirit and in practice), hackable, simple and controlled by the community. Slack replaces a distributed, network-failure-proof system (IRC) with a centralised, corporate-controlled, paid, closed, proprietary solution. That's the worst possible collection of properties. Yeah you can search messages, yes it has a nice user interface, but that's about it.
Holy cow. I've been linking to matrix and Riot links, how did you still think I'm talking about slack? I was talking about how slack is getting the mindshare of OSS communities and that's not good.
>I can't tell if this is a joke.
No I assure you it's not. You linked to a single web client. That's not the same support for emoji's as matrix's.Those are emocodes, and on the big list of supporting clients here[1], I see only IRCCloud (which is the same web client you linked me to) implementing it. No other IRC clients does this.
> This is 100% purely a user interface feature
That's why I listed the clients I use - Hexchat and weechat. Please share the easy code that can add those features to them. While you're at it, licensing it with a FSF approved license would be much appreciated.
>Well you must be around cooler people than I am. Today, if someone wants to start a group chat with persistence (I'm surprised you seem to think this is useless), without having to bother with setting up their own server, IRC will not be on that list. But there is a large group that wants this, and its increasing, because people don't want to bother with a bouncer.
I don't care what you use personally. The reality is that many hundreds of thousands of people use IRC frequently. Communities all over the world use IRC. Most of them are non-technical. Most have never heard of Matrix, or Riot, and certainly have no interest in using Slack.
>This is a bit similar to FORTRAN's situation. FORTRAN can still do the things C++ can still do, but you don't see people using FORTRAN. IRC is a simple protocol and is simple, until it has it be used for increasingly complex features and also being adopted for the web requires all sorts of proxies and workarounds.
No, it's nothing at all like Fortran. That's a silly comparison.
>What are you saying then? You said people can use IRC now for all the features I talked about, but then now you changed your stance.
No I didn't. I never said that IRC could do all those things today. Are you even reading my comments?
>Then what solves those problems? I think Matrix solves those problems, so what do you think is a better alternative? Does it have a community comparable to matrix? Say so and I will switch right now. The guys working being matrix know what they're doing. HTTP transport isn't the fastest, but it is simple to implement for a web developer. And with more and more people preferring in-browser clients, I saw HTTP as a good choice.
Again, you're missing my point by a country mile. If you had said "IRC doesn't currently support this" I would agree with you. But you didn't. You said that simple protocols could never support these features. You said that the days of simple chat protocols are over. And quite frankly, that's rubbish. That's all I am saying, all I have ever said. Stop pretending that I'm saying IRC has all the features you are asking for. I am saying that you can implement those features in a simple way on top of a simple protocol. That is all.
>Holy cow. I've been linking to matrix and Riot links, how did you still think I'm talking about slack? I was talking about how slack is getting the mindshare of OSS communities and that's not good.
No you've just asked me repeatedly and for no good reason to show you how IRC does all the things that I've repeatedly said it does not do. I don't know why you're incapable of understanding the difference between "IRC has features X, Y and Z" and "it is possible to implement features X, Y and Z on top of simple protocols, so no the days of simple protocols are not over". But you do seem to be incapable of understanding that, as it's about the fifth time I've said it.
>No I assure you it's not. You linked to a single web client. That's not the same support for emoji's as matrix's.Those are emocodes, and on the big list of supporting clients here[1], I see only IRCCloud (which is the same web client you linked me to) implementing it. No other IRC clients does this.
You can use shorthand emocodes (with autocomplete!) to send them and they’ll be converted to unicode so anyone using another IRC client that supports emoji can enjoy your graphical exuberances.
You could at least read the link. You type them as emocodes, which are mapped to the actual Unicode emoji. All that is sent over the wire is normal Unicode emoji. That is why I'm saying that this is a purely UI issue.
This is what emoji are. They are Unicode grapheme clusters formed from a group of Unicode code points. That's the implementation, and the interface is, on both Slack and IRCcloud and everywhere else I've seen them, either a giant grid of emoji to pick from, or emocodes :simple_smile:, usually both.
>That's why I listed the clients I use - Hexchat and weechat. Please share the easy code that can add those features to them. While you're at it, licensing it with a FSF approved license would be much appreciated.
I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things.
So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.
I'm not very familiar with all of the chat protocols, but I'm familiar with the possibilities of communication today. It's riddled with proprietary protocols and chromium based applications. And that's why I see Matrix as the next step.