Why Slack is inappropriate for open source communications

No, it's not, it's a huge pile of crap, because HTTP is so complicated that you essentially have to distrust any implementation of it that you haven't audited, and even then, it's questionable (plus, most implementations turn out to be buggy if you look closely, and serious vulnerabilities aren't exactly uncommon), and it doesn't even fit many common scenarios without additional hacks like long polling.

Also, "any programming language" is a huge exaggeration. Ever used HTTP on a microcontroller?

> Before, you could only use a programming language if had a production-ready implementation of the protocol you wanted to speak. Otherwise you would spend the next weeks or months tediously writing one.

Now, that's just bullshit. If you have an HTTP implementation, you necessarily also have a TCP implementation. You don't need to write anything in order to use TCP, you just open a socket and use it and forget about HTTP. HTTP serves no purpose in most cases.

Oh, and maybe more importantly: Ever used HTTP for peer-to-peer communication? No, you need a server! Because it's so much more convenient to add a server "in the cloud" than to simply use a TCP connection between two devices that need to communicate. (And no, of course, you technically don't need a server, but in practice that's how people deal with the pointless complexity of HTTP.)

> Well, doesn't that mean the limit is 510 characters including the command?

No. The limit is on what the server sends to other clients when a message is delivered. For instance, if you send:

    PRIVMSG #channel :some long message

    :your@hostmask PRIVMSG #channel :some long message

(I incorrectly said earlier that the prefix is based on the server -- it's actually your client hostmask.)

> HTTP is also over TCP so not sure what you are trying to say here (BTW: TFTP works over UDP).

DCC file transfers work on a chunk-by-chunk basis. The sending client sends one block of data at a time, then waits for an acknowledgement before sending the next one. (This is why I describe it as being like TFTP.)

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.