Why Slack is inappropriate for open source communications
dave.cheney.net
dave.cheney.net
With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies, and then a million people could use it, or one person could, and you wouldn't have to lift a finger. A million people could fork your application, or one person could, and you wouldn't have to do a thing. Variable costs for an OSS developer were $0. Fixed costs were just the cost of your computer and an internet connection.
But if you deploy an open source service to the cloud, it's going to cost you more than a few pennies, and if a million people try to use your service you have two headaches: financial and operational.
In theory something like Ethereum solves this problem, but it's not really ready for the scale yet, and it's hard to use.
In theory something like a Heroku Button[1] on Github solves the problem, but Heroku artificially introduces a 30 second delay for accessing free applications, and put lots of their infrastructure behind a paywall that the deploy-er has to manage and pay for.
This has been a difficult problem to solve, because unlike the x86 machine of the OSS explosion in the 90s, the "cloud computer" is still actively being invented. Ethereum didn't even exist a few years ago, and Heroku is a moving target. Linux Containers are also brand new, and then there's Docker and other VM standards, not to mention Google, Azure, etc... we are still grasping in the dark to try to answer the question, "What does a standard cloud machine look like?"
Until we answer that question, closed source services are going to have an immense advantage over open source ones. After we answer the question the power dynamic there will reverse and there will be a cambrian explosion of user-facing open source services.
It isn't a product maturity thing either. At a theoretical level, we don't know how to make blockchains scale. Every node needs to process every transaction, and we don't know how to get around that.
Would be great to move to a model where the end user can pay for the server time. sandstorm.io was (is) exciting for more than a few reasons. But overall it's still an unsolved problem.
In the case of chat, I'm convinced that the ability to register data in a shared, immutable store like a blockchain with many stakeholders of disparate interests will be valuable to that end even before microtransactions start being sent with every packet on the internet.
When I read on HN the engineering posts from Netflix about the enormous engineering efforts required to make their video service scale, I can't help but think: that's a solved problem, Emule/BitTorrent have been providing good access to video for decades! Of course, there is the "monetization" issues... (but there is also on Netflix, good luck finding non-US or indie content there.) On other side of the spectrum, look at Syncthing vs Dropbox.
The thing about Slack is particularly crazy because even their client does not scale too: it was too slow to be usable daily in my 7-year old computer. A freaking chat app!
Admittedly, I hesitate about whether the best solution of the OSS community is to jump and try to replace all those things. At the same time, the kind of software I enjoy most both developing and using is desktop software. That is kind of software that is uses to empower our creativity. While the proprietary software world moves its engineering power to the cloud, we can still use it to build tools that help people expand their imagination. I am thinking on helping making Gimp and Inkscape and Blender and coding tools all those better, but also making new tools that we have not thought of. I think there is still a lot of potential for exploration, creating new interaction models, etc. in this area that we have not explored yet. Sadly for the libre software world, Apple still gets a lot of developer mindshare in that area too...
I'm having a bit of cognitive dissonance trying to understand what an "open source service" is. If it's "open source", in terms of the OSI definition, your "million people" could just download and self-host it. To my mind, at least, if it can't be self-hosted it's not "open source".
If you're talking about selling access to servers running an instance of the application then you're talking about running a service bureau, not distributing software. The economics are completely different.
Open source isn't wholly incompatible with this model, for sure - you can still have open source code that can be hosted by the developer for a fee. But the specific idea of throwing something up on the web and letting people use it if they want isn't as effective, because not having to worry about the software (including how it's hosted) is part of the draw of using third-party software in the first place.
I feel very strongly that decentralized computation and software freedom are powerful forces for good. Conflating hosting and software plays to an agenda of curtailing individuals' and businesses' ability to self-host and to have freedom. I think this agenda is driven by hosting providers' profit motive primarly, but it plays into agendas of unrelated parties who seek to curtail freedom for their own ends.
The creation and maintenance of software is a service-- it always has been. Creating and maintaining software has never been a "product" because it doesn't suffer from scarcity. The best world I can envision is one where the underlying infrastructure, authorship, maintenance, and administration are all able to be decoupled based on need.
I agree RE the fragility. Even on my mid-range rack mount units, I'd rather stick to just having them serve up iSCSI or NFS to something more... server like that runs the actual instances.
Their package system (for 3rd parties) seems to still be a mess: https://github.com/SynoCommunity/spksrc/issues/2216
(I know several teammembers and preordered via Indigogo, but am otherwise unaffiliated.)
https://machinebox.io/#pricing is one example that I like of a product that goes back to software-as-a-product. I've not dug into the operational aspects of this product, but if done well should be able to scale from a dev's laptop to k8s or other PaaS.
This is exactly where I am with https://landscape.io - can't keep it running for free, can't get people to pay.
You can still create a Digital Ocean droplet, Docker container, or VM Image - and do the same thing (upload & forget). Then it's up to the user to pay $5/mo to host it, a process which doesn't need to take more than a few mouse clicks.
Wouldn't it be easier - and free - to "upload and forget" onto github ?
If someone had a software release, why wouldn't they choose github to be the release point - even if it's just a single tarball ?
Are there costs involved in hosting binaries/tarfiles on github ?
Personally, I self-host everything on my personal www homepage.
If I did not self-host everything, I assume I would put it up on github, right ?
VC's want their income tap. These yachts don't run themselves!
https://www.openshift.com/ https://blog.openshift.com/updated-openshift-deploy-buttons/
Some SaaS providers already choose to run an OSS product which they develop for their needs but also share (like GitLab, Discourse and Sentry). Others choose not to publish their code, and lock the software to their infrastructure. These are business strategies as well as ethical decisions. Different technologies might change the cost/benefit ratio, but people that really want to be OSS already are.
You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients.
There's E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintain session history on new devices.
I think it has a bright future and you should consider it too.
[2]:https://riot.im
Here's the spec if you're interested[1].
There's also a weechat script if you want a command line client[2]
Too bad much of the web stinks, with terrible responsiveness and usability and impose those results through bloated protocols and spaghetti architecture on anything that tries to interface with them.
Multiple times on caltrain I've had people ask me how I'm on the internet as I have meetings on IRC without even noticing the connectivity has gone poor -- while their webchat stuff with multiple megabytes of ajaxy whatever won't even load.
I agree that the web is slow and crap a lot of the time, but chat using gzipped JSON over HTTP/2 would be just as fast as IRC as long as it's only sending the same level of info as IRC.
Because otherwise you'll get to the same place as we were with HTTP/1.1: your nice 'simple' protocol will need to be replaced with one that can support multiple streams, etc.
They are, for what matrix intends to do.
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.
This was so crippling that XML actually seemed like a good idea. Just imagine!
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.)
The critical difference? Speed of development. Websockets was so blindingly quick to get working. Haven't hit the edge cases yet though. If I were doing it with raw sockets I'd have to reimplement many of those layers and write a mobile app as opposed to a mobile webpage with only 300 lines of JS.
> Ever used HTTP for peer-to-peer communication? Sort of. They're peers, but one always acts as the server, I just haven't needed to make them true peers, but I could if I needed to. One of the nodes connects to a public server and has other private nodes connect to it. (300 lines of Python/Twisted)
On the other hand, it's hard to impress with blinkenlights and basic motor driving.
I'm currently going through a phase of thinking on how I could apply functional programming theory and techniques to the next iteration of this embedded system...
Now, is that websockets or is that "not C"?
I mean, speed of development certainly is valuable, but I would think that same speed of development only needs little more than an 8 bit µC (or, for that matter, is even possible on an 8 bit µC if the memory size is at the upper end of the range).
> Sort of. They're peers, but one always acts as the server, I just haven't needed to make them true peers, but I could if I needed to.
But that's the thing: You could if you needed to. Instead of it just being the natural thing to do. Though I guess NAT also is part of the problem here, which is another of those idiocies of the "modern internet".
The second point answers the first. It is websockets rather than C, because the client is a random user on a mobile web browser.
Now if I could control the other endpoint and were it not for those modern idiocies, P2P could easily be done in C. The problem then becomes discoverability (if you're after true distributed P2P) rather than the actual communications.
(I did port the lightweight lwIP TCP/IP stack to a 16-bit microcontroller and custom RTOS many years ago...)
And I still prefer doing that over writing a matrix client with HTTP and JSON.
Specifically because my solution works via throttled internet with dialup speeds, while matrix doesn’t.
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.
In terms of the line protocol - we all agree that HTTP+JSON is an inefficient baseline for Matrix. It's just a matter of time for someone to propose a proper binary transport (although HTTP2+gzipped JSON really isn't that bad, and works fine on dialup speeds). Luckily this thread has prompted a few people to offer to contribute one though, so perhaps we'll see some progress there at last :)
What is large, you might ask? 18'000 users in a channel.
And still it should feel and be as easily usable as a channel with 10 users, even via dialup.
That's the point where every byte that isn't used optimally becomes a problem. And where HTTP2 eith gzip or even brotli just isn't enough.
Where Java's IO is too slow, and you need to use the new native noncopying IO subsystem.
But I'll also be happy if, someday, we'll have a truly universal protocol for this.
That's too bad - mostly for the people that won't experience it or see it as viable.
In 2017 I use (al)pine as my sole mailtool. It's many, many times faster and more efficient than web based email - and much more private and secure.
HTTP2 (if used) already makes the metadata parts of the protocol pretty concise and low-overhead; it's just the messages themselves that are large. So it'd be nice if—at least for the message bodies—there was an optional binary layer-6 encoding (e.g. CBOR, BERT-RPC) that clients and servers could try to negotiate with their Accept headers, with an expectation that many servers would implement it, and an allowance for constrained clients that implement that encoding but not JSON.
$ telnet irc.freenode.net 6667
...
NICK Ara4n
USER Ara4n Ara4n irc.freenode.net :Matthew Hodgson
...
JOIN #matrix
PRIVMSG #matrix :test
curl "https://matrix.org/_matrix/client/r0/rooms/!cURbafjkfsMDVwdRDQ%3Amatrix.org/send/m.room.message/uuid?access_token=$access_token" -X PUT --data '{"msgtype":"m.text","body":"test"}'
Meanwhile definitely are some lightweight C matrix clients out there - e.g. https://github.com/matt-williams/matrix-esp8266/blob/master/... is a proof of concept client in C that runs on an ESP8266(!), or the libpurple plugin: https://github.com/matrix-org/purple-matrix.
In the end, if you don't like HTTP or web technologies, there is NOTHING stopping people from contributing alternative transports - COAP, MQTT, capnproto, QUIC, XMPP, WebSockets or whatever floats their boat. But it seems that the simple HTTP+JSON API works well enough that nobody has bothered yet (other than https://github.com/matrix-org/matrix-doc/blob/master/drafts/...).
* No standard maximum message length. If you input a line which is more than 510 characters after being prefixed with the channel name, server name, and other metadata, it may be truncated for some clients. If you're on a network which includes multiple servers, some clients may actually see your message truncated in different locations, based on how long their local server's name is.
* No standard text encoding. Some clients assume ISO8859-1, some assume UTF-8, and some will mix and match (ew).
* No way to determine when certain commands have succeeded. In particular, commands which can generate multiple lines of output (like WHOIS) don't have a standardized termination. Command-line clients sidestep the issue by just showing all the output in one place; higher-level clients have to guess.
* No standard identity services. NickServ is a common bolt-on, but it's a total hack. (It works by pretending it's another IRC server!)
* Bold, colors, and emotes (/me) are all client-side hacks.
* DCC file transfer is a complete and utter mess. It's like TFTP, but poorly implemented, over a TCP transport.
If they would tolerate a little breakage of backwards compatibility, the big networks could easily move to utf8 with standardized identity and colours, etc.
Unfortunately there is a small but very vocal faction of IRC users that are highly entrenched and resistant to change.
Well, doesn't that mean the limit is 510 characters including the command? I never as an user had issue with this. This is also implementation issue, if you use one server such as you do with slack, then you know its capabilities.
> * No standard text encoding. Some clients assume ISO8859-1, some assume UTF-8, and some will mix and match (ew).
Well, there's a CHARSET value in 005 numeric from the server which declares the official encoding.
> No way to determine when certain commands have succeeded. In particular, commands which can generate multiple lines of output (like WHOIS) don't have a standardized termination. Command-line clients sidestep the issue by just showing all the output in one place; higher-level clients have to guess.
I'm not sure what you're talking about, there's 318 RPL_ENDOFWHOIS numeric: https://tools.ietf.org/html/rfc1459#section-4.5.2
> No standard identity services. NickServ is a common bolt-on, but it's a total hack. (It works by pretending it's another IRC server!)
You mean it works by pretending that it is another user. The reason for it is an optional component. Some networks (especially the largest one) are running successfully without such services. I kind of like this approach because it leaves the server protocol simple (networks often provide multiple services NickServ, ChanServ, MemoServ etc) and makes the component optional.
> Bold, colors, and emotes (/me) are all client-side hacks.
If you think about it, does it have to be server side? Server is just to relay messages, what they mean is up to a client. In fact pretty much any chat network that allows multiple clients has different looking emoticons. So making it part of the network doesn't help at all with unification.
> DCC file transfer is a complete and utter mess. It's like TFTP, but poorly implemented, over a TCP transport.
HTTP is also over TCP so not sure what you are trying to say here (BTW: TFTP works over UDP).
But ignoring the TCP part, yes DCC feels like it has problem, but that's mainly because of NAT becoming popular. Hopefully as IPv6 is adopted we get back to previous times where ach user had own IP address.
Anyway, comparing DCC to slack etc. Is a bit unfair, because their service is nothing like DCC (Direct-Client-to-Client i.e. P2P) when you upload a file to slack you upload it to their server, but with DCC you're sending it directly to the user without any 3rd party involvement.
Looking at the issues you listed, it feels to me that the problem is not as much with IRC servers, but with IRC clients, in particularly lack of standardization. You could solve most of the issue by defining client protocol on top of IRC, for example:
- handling encoding - abstracting communication with services - colors/emoticons - file transfer (instead of using DCC which sucks with NAT) a client could upload file to a server and provide link to others, emulating behavior of other chat networks
The nice thing about it is that most of this could be implemented in a way that standard clients would still be usable, but if a standard would be created and other IRC clients would respect it, IRC could easily compete with existing solutions.
> 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.)
> 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.)
You're right, I was not aware of the acknowledgments. But this in previous response I said that a lot of issues could be fixed on a client side. DCC is also completely implemented with clients and similarly can be fixed this way. There apparently is already DCC XMIT standard which fixes latency caused by the ACKs (assuming our client wouldn't do same thing as Slack does which is upload files to S3 and share the URL)
> * No standard identity services. NickServ is a common bolt-on, but it's a total hack. (It works by pretending it's another IRC server!)
SASL and account-notify.
> * No way to determine when certain commands have succeeded. In particular, commands which can generate multiple lines of output (like WHOIS) don't have a standardized termination. Command-line clients sidestep the issue by just showing all the output in one place; higher-level clients have to guess.
Batch messages.
You can find more at http://ircv3.net/, there’s a lot of specs on modern IRC features. IRC has changed a lot, you might want to take a look at it again ;)
Does it have Android and iOS clients?
If not, it's not a great alternative to Slack. It's not even an alternative to Slack.
irccloud.com is pretty awesome. They have a pretty good mobile app as well (at least on android - I'm not an iOS user).
(I'm not affiliated with them, I'm just a happy user)
or, site-specific:
There are web-based applications that communicate with IRC but they require a proxy running on a server.
I used to use: https://www.irccloud.com/ (Paid, SaaS)
Riot is really obnoxious to use and get set up, and is also extremely resource hungry.
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 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.
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.
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.
[1]:https://github.com/matrix-org/matrix-react-sdk/pull/296 [2]:https://github.com/vector-im/riot-web/issues?utf8=%E2%9C%93&...
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]
To name a couple large OSS projects which moved to slack Wordpress - https://make.wordpress.org/chat/
Kubernetes - https://kubernetes.io/community/
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.
[1]:https://www.wired.com/2016/03/open-source-devs-racing-build-... [2]:https://news.ycombinator.com/item?id=10486541
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.
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.
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.
Why on God's earth would I do that?
> No, nobody wants this
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.
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.
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.
Mind you, I haven't used IRC for a decade, maybe it's become a whole lot easier since then...
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.
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.
In fact, if you can't work out IRC then you're almost certainly too silly to be a programmer.
I was more thinking about it from the context where Slack provides so many more features over IRC, not just real-time chat.
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?
Maybe actually read the thread next time? So don't "so what?" me. This isn't about whether IRC can do those things.
Then use the Quassel IRC bouncer, with clients. Web client? https://github.com/magne4000/quassel-webserver Session persistence? That’s the entire purpose of it. Search? https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 Emojis? Check.
> 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.
Empirically many people seem to use it fine for business and for IRC-style purposes though :)
Well, except you managed to needlessly intertwine matrix and HTTP such that it's essentially impossible to reasonably port it to a sensible transport protocol.
You are using URIs and HTTP status codes (if you want to call it that, as you are not actually speaking HTTP), which is completely unnecessary (you could transport that same information in JSON, reducing the number of languages that an implementation needs to be able to generate and parse to one instead of three, thus reducing the attack surface by at least 66 % (probably more, given the complexity of HTTP)).
I mean, just look at the "lightweight C client" that you linked to above: Not only is it not in C, but it's already full of bugs that are essentially caused by the complexity of all those languages on has to interface with.
> But nobody's bothered to implement it, because nobody seems to feel HTTP+JSON is particularly broken in practice.
Or, more likely, those who do feel that way have read the spec, facepalmed, and forgot about it?
Totally agreed that HTTP is inefficient and increases the potential bug surface a bit. However, the ubiquity and convenience empirically seems to outweigh the inefficiency and risk. Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes; it shoves a stream of JSON over a websocket. We even wrote an implementation of it: https://github.com/matrix-org/matrix-websockets-proxy. And NOBODY in over a year has felt the urge to actually implement a client against it - instead there have probably been 40-50 new clients, all who were quite happy to use the ugly HTTP API instead. This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever".
Except for the fact that it's necessarily redefining quite a bit of the protocol, also necessarily further complicating any possible universal implementations because this kind of construct doesn't even provide any sensible layering abstractions.
> Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes
Except that the client and the server still need to understand HTTP in order to then implement a bad version of TCP on top of it, more or less, which makes this whole mess even more bloated and error-prone.
> This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever".
What exactly would people facepalming and walking off feel like, that this doesn't feel like it?
In case you hadn't guessed it yet, that was exactly my reaction when I looked at the spec a while ago, and it just so happened that I stumbled upon this thread here, or you most likely wouldn't ever have heard about it, and I can only guess that I am not the only one.
(And no, that reaction was not just based on the use of HTTP, but more generally on the impression from the spec that it's all a huge dysfunctional mess that's essentially impossible to implement securely, and that probably will result in even greater interoperability problems than email with all its historical baggage in a much shorter time frame. All of which in turn makes me suspect that the people who are busily writing software for it just are lacking knowledge and experience to see the flaws, and examples like that "C" client do not exactly help to convince me of the opposite.)
Funny how the silent majority is alway on 'my side'. No-one ever claims that the silent majority is against them.
In terms of the websocket transport proposal requiring HTTP to set up the websocket... yes, this is true. I guess you really don't like HTTP - I'm amazed you're willing to use it to communicate on HN! In terms of Matrix being a "huge dysfunctional mess that's essentially impossible to implement securely" - you're entitled to your opinion; it's just a shame it doesn't seem to be particularly well-founded.
Great, and where is that actually specified?
> or whether you encode the data as JSON, CBOR, BSON, protobufs or whatever
Except that you still need at least a sort-of JSON generator for the signing stuff, thus only adding bloat by using a different format?
> It's just a transport!
Except that it isn't. HTTP is "just a transport" for JPEG files. You don't need to touch JPEG encoders and decoders to swap HTTP for SFTP, that is what "just a transport" means.
> We want people to propose alternative transports!
Which is just idiotic, both because you make it unnecessarily difficult if that really is what you want, and because a federated system that doesn't have a common transport protocol just doesn't work. And if you need to expose an HTTP engine for compatibility anyway, it would be just braindead to add further complexity on top of that.
> I guess you really don't like HTTP - I'm amazed you're willing to use it to communicate on HN!
I don't like unnecessary complexity because it makes it unnecessarily hard to build secure software. The HTTP engines in browsers are probably some of the best-audited ones out there, so it's somewhat acceptable to use them ... but even they have their history of vulnerabilities. The last thing we need is a new large distributed system that's creating even more botnet material than we already have.
> it's just a shame it doesn't seem to be particularly well-founded.
lol
Your complaint about the layering seems to be that the HTTP URIs sometimes include values (e.g. event types) associated with the JSON payloads, and that this is a layering violation. This is because HTTP isn't being used as a dumb data transfer transport (e.g. your HTTP v. SFTP example) but as an RPC transport - and you pass parameters when you make an RPC call. Sure, it means you have to map the RPC mechanism if you switch transports, but it's hardly the end of the world. In future I guess we'll specify the CS API semantics as some IDL style format to make it easier to map to other RPCs.
The idea that you can't expose alternative transports because "adding additional complexity when you are already exposing an HTTP engine is braindead" is just obtuse. If you really don't trust HTTP then by all means turn off the HTTP listener the client-server API and only support clients which talk your better transport protocol. You're obviously stuck talking it on the federation API for now, but we've always reserved the right to switch to an entirely different federation mechanism (e.g. a pure TCP line protocol, WebRTC datachannels, the IPFS DAG or whatever) in future - the migration would be similar to bridging Matrix with any other new network.
The idea that HTTP client libraries like python's, go's or curl's are somehow less reputable or audited than those used in web browsers seems questionable at best. But agreed that the last thing we need is a large distributed network which can be used as a botnet, and obviously it's in our interests to avoid that. Unconvinced that vulnerable HTTP stacks is the biggest risk there though...
Are the algorithms for the distributed data structure actually documented anywhere? Just schemas don't really get you particularly far is you want to build a reliable global scale network.
> Your complaint about the layering seems to be that the HTTP URIs sometimes include values (e.g. event types) associated with the JSON payloads, and that this is a layering violation.
No, it's not a layering violation, it's just that that makes HTTP not "just a ...
> This is because HTTP isn't being used as a dumb data transfer transport (e.g. your HTTP v. SFTP example) but as an RPC transport - and you pass parameters when you make an RPC call.
... transport", but an RPC mechanism. Which means that you cannot swap it out for another transport, but only for another RPC mechanism. Which is completely unnecessary.
Also, you keep writing "HTTP", as if you were using HTTP. You still are not.
> but it's hardly the end of the world.
Said about everyone responsible for the protocols and frameworks and stuff that are the causes for the mess of vulnerabilities we find ourselves in today. Yes, actually, exactly that is the end of the world, so to speak.
> In future I guess we'll specify the CS API semantics as some IDL style format to make it easier to map to other RPCs.
Yay, more bloat!
> If you really don't trust HTTP then by all means turn off the HTTP listener the client-server API and only support clients which talk your better transport protocol.
Now, that is obtuse. "If this really turns out to be a security problem, just reinvent it all on your own in better, and the problems will be fixed!" Thanks, yes, I was aware of that option. But it's not exactly a good argument for doing it the way you propose.
> You're obviously stuck talking it on the federation API for now,
Exactly!
> but we've always reserved the right to switch to an entirely different federation mechanism (e.g. a pure TCP line protocol, WebRTC datachannels, the IPFS DAG or whatever) in future - the migration would be similar to bridging Matrix with any other new network.
AKA: It won't happen. Most likely. That's network effects rearing their ugly head. Reserving the right means exactly nothing: If the matter of fact is that the world speaks SMTP, reserving the right to switch email transport to MUCHBETTERFORREALMTP will have exactly zero consequence. Even the pain with IPv4 is causing hardly any movement ... or maybe it is now, slowly, more than a decade late. Heck, even explicit compatibility mechanisms don't help, see TLS: Implementations from big vendors fuck(ed) up version negotiation so badly that more than one mechanism in the protocol had to be abandoned in newer versions because they couldn't negotiate backwards compatibility with the old version with those broken implementations, so introducing a new TLS version in clients would have had tons of website break.
> The idea that HTTP client libraries like python's, go's or curl's are somehow less reputable or audited than those used in web browsers seems questionable at best.
I didn't say that, but those are three of hundreds of implementations, and none of them is exactly light-weight.
Also: https://curl.haxx.se/docs/vulnerabilities.html
And I am not saying that that makes curl a bad library.
> Unconvinced that vulnerable HTTP stacks is the biggest risk there though...
Well, for one, it's maybe the biggest risk that you cannot easily avoid in an implementation (because it's something that you cannot do without, unlike, say, parsing image formats in the client, which probably would be the biggest risk otherwise), but also, see above: It's almost always the small stuff that's "not the end of thr world" that actually is, in the end. If you asked the people that have built the protocol specs and the software that ended up being used to build the botnets of the world, what would they say? "Yeah, we intentionally put in this huge hole so people could build a botnet"? I guess not.
Jonathans-MBP:node jon$ node app.js | ts
Apr 11 18:27:22 Got push rules
<snip>
Apr 11 18:28:03 Room List:
Apr 11 18:28:03 [0] Invite from @sms:matrix… (0 members) ---
Granted, I'm a fairly heavy Matrix user, and the fact that I'm in nearly 100 rooms probably has something to do with it. :)
Coincidentally, the new version of Riot which uses the new indexeddb backend should be going live tomorrow (live today on riot.im/staging).
I can do that with IRC. I can do that with all IRC bouncers.
And it’s a daily use case for me, and many other users (mobile networks provide free 64kbps network in many places)
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.
$ time (
(curl -s --limit-rate 8K 'https://matrix.org/_matrix/client/r0/login' \
--data '{"type":"m.login.password","identifier":{"type":"m.id.user","user":"matthew2"},"password":"secret"}' -A '' --compressed &
curl -s --limit-rate 8K 'https://matrix.org/_matrix/client/r0/directory/room/%23riotdemo%3amatrix.org' -A '' --compressed) &&
curl -s --limit-rate 8K "https://matrix.org/_matrix/client/r0/rooms/%2eNNtfYnugaAKouPTJdp:matrix.org/send/m.room.message/uuid?access_token=$access_token" \
-X PUT --data '{"msgtype":"m.text","body":"test"}' -A '' --compressed &&
curl -s --limit-rate 8K -Gg 'https://matrix.org/_matrix/client/r0/sync' \
--data-urlencode 'filter={"room": {"rooms": ["!NNtfYnugaAKouPTJdp:matrix.org"], "timeline": {"limit": 20}, "include_leave": false}}'
--data-urlencode "access_token=$access_token" -A '' --compressed
) > /dev/null
real 0m3.258s
user 0m0.057s
sys 0m0.025s
Now in practice, most Matrix clients (e.g. Riot) currently don't bother to lazyload the initial /sync response with filters, which is why it can be slow the very first time you ever log in on a device. But this is just a matter of optimisation work on the clients - https://github.com/vector-im/riot-web/issues/1846 and https://github.com/vector-im/riot-web/issues/2914 etc. Meanwhile, any app built on matrix-{js,ios,android}-sdk caches sync results locally these days, so the slow initial sync is only ever a problem on the very first login.
So, to be clear: HTTP is inefficient, but in practice it really isn't that bad. Can't wait to spend the time to switch to a proper binary transport system down the line, though, but to do so now would be premature optimisation.
Try it again with 1000+ user rooms, or even 8000+ user rooms.
The worst case I'm currently trying to support is a bridge for a game's chat system with 18'000 users in one channel (and users still expect the client to connect in 4 seconds on mobile, and be stable).
And without a custom binary protocol and lazy sync, Matrix will not support that. True, it's also at the upper limits of the Quassel protocol for now, but Matrix is even further off for now.
That said, as I mentioned above, if Matrix someday gets full support for a good binary protocol and real clients, it might truly replace IRC.
I'm always down for more FOSS, and don't ever paint me otherwise.
It's bad because the protocol is heavy and complex. Plenty of technical complications detailed in other comments.
So far the other feedback seems to be "HTTP is overly complex" (which is very subjective), "Matrix is too tied to HTTP" (despite evidence to the contrary), matrix-js-sdk is slow (which we've fixed), and "Riot is extremely resource heavy" (which is relatively true - it's already better than Slack, but we're working on it).
I'd genuinely like to know what your specific bad experience was so we can fix it, as it seems to have really pissed you off to be seen as "garbage" and "not remotely suitable" and "not suitable for business" :)
I set it up over the weekend and it took me less than an hour, and that was because of my HAProxy + Lets Encrypt setup requirements. It's not perfect, but it wasn't obnoxious to do.
Additionally the Riot client on Android via F-Droid has been great on my battery life on my phone, significantly less than Hangouts (which I'm replacing with Matrix so that's why I compare the two).
This is in no way a disagreement with the author.
Note that I have read the claims at http://matrix.org/docs/guides/faq.html#what-is-the-differenc... but critizising the minimal XMPP baseline feature set while claiming that XMPP is not being “well designed for mobile use cases” seems like someone wants to have their cake and eat it too – I have used XMPP over low-bandwith high-latency mobile data connections for years and noticed that XMPP's stream syncronization is a really nice feature for that use case.
The FAQ entry on XMPP needs to be updated, tbh - XMPP works fine on low bandwidth connections, and is typically lower bandwidth than Matrix (at least when using HTTP/1.1). The "not well designed for mobile use cases" was talking more about push notification support & history synchronisation, both of which XMPP has improved since.
I know groups that (for business or pleasure) use Slack, Discord, Skype, Google Hangouts, IRC, etc.
All of these clients are a bit more obstrusive than they need to be in terms of pop-up notifications, software updates, cpu, memory, transfer, etc. They all screw up enough that there's always a little apprehension that something will go wrong when you get a number of people together for a meeting.
It is one thing to deal with one of these things, but when you have to install ten to get your work done you have a problem. I have a high performance computer and I want to keep it that way.
The modern office large office is pretty bad in this respect. Really not uncommon to see things like
• Need to have Slack open
• Need to keep an eye on Basecamp/pm software
• Need to have Outlook open / check in on for email and calendar invites
• Need Skype open because not everyone uses Slack
• GitLab is open in another tab
I've started counting the minutes that I use in a day just logging in to things with our SSO, because it has started to actually add up, haha. It has gotten silly.
If you need to log in more than once, can you really call it SSO? =)
I don't have that many open, and it still takes me around 5 minutes every day to open them back up.
Imagine having about 7 tabs open. By the time I'm finished with the last tab, something new has come up on the first tab I checked. Huge waste of time. I'm trying to wean myself from all these services, but it's not easy.
This or that project is on GitHub, but join the developers on Slack. And I hate Slack.
If it really can't wait <25 minutes, they can call me or come to my desk. It's amazing how many things aren't "immediate" if you create a slight cost with requesting attention.
My favorite application is Microsoft Outlook, which consistently takes up ~50% of my CPU on my 2015 maxed out Mac.
Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into. You write:
> Schedule your time spent and group distracting reminders and notifications in one place
If this "one place" is a separate silo from Slack, Outlook, Basecamp, Skype, SMS, Discord, Hipchat, IRC, and Github...it's not the one place I'll need to check. It's the n+1th place.
Now, if I can put my credentials into Calmbird (securely would be nice, but you can have the plaintext if you can make this insanity stop) and have it do the API connection to - or, if necessary, the nasty DOM-manipulation, Windows message hacking, and client-impersonating - to put all these services and their notifications in one place, that would be a solution to the proliferation problem.
Also:
> schedule automatic emails to your clients with updates
My clients don't want automatic emails, especially from templates/digests. They want me to hand-craft them as if it was the most important thing in my life. And while they can understand a curt update message or a missed daily status notification, the real point of these updates are to confirm that I'm still on the project. If a message accidentally went out with a placeholder like "I'm still working on {todo-insert-task-here}", and I didn't know about it, that would be...bad.
This isn't possible for web services due to the state of U.S. law. Speaking to a server without the consent of the server's owner is both a crime and a tort under the CFAA. There is also liability for copyright infringement, among other things.
IANAL
At least in Europe, news organizations pushed this kind of argument in their campaign against adblockers and failed in front of the courts. US law may differ, of course.
The implied access and license is probably valid as long as you're abiding the ToS. If you're violating the ToS after agreeing to it ("agreeing" means that proper notice is given to make the ToS binding, etc.), the implied license would probably not work. If you've been specifically asked to stop, either directly or indirectly (e.g., through an IP ban), any implied license or access privileges would almost definitely be revoked at that point.
>At least in Europe, news organizations pushed this kind of argument in their campaign against adblockers and failed in front of the courts. US law may differ, of course.
Ad blockers differ because they alter the payload after receiving it under legitimate terms (though this could still probably be considered copyright infringement under the argument that the license is for viewing only, not alteration). The CFAA would not be applicable because when the adblocker comes into play, you're not accessing someone's network (which is what the the CFAA addresses).
If a site clearly disallowed AdBlock users in their ToS and adequate notice was given to users that they were to be bound by these terms, it would be "unauthorized access" to the server, which is not allowed under the CFAA.
- Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into
That is not the aim, the real goal here is exactly what you state next i.e you'll be able to (securely via OAuth, so you can also revoke access anytime) log into your Slack, Basecamp etc. and Calmbird will be the one 'dashboard' where you log into, kind of like having a social network client that supports Twitter, Facebook etc.
> My clients don't want automatic emails, especially from templates/digests. They want me to hand-craft them as if it was the most important thing in my life.
That is very true from personal experience, this is a feature where you'll craft a sort of an 'emergency' email yourself in advance and when you indicate in calmbird that you're working, it'll send if off to your client if there's an email from them, optionally with the latest updates. It's not a 'machine-generated' email in the traditional sense and this feature is in my current version entirely optional, which is how it will stay at launch, (if it stays at all, I'll certainly be thinking a lot about how can this be improved, there's no point if it's not going to be useful.)
I don't have a need for the product myself, but I do like the name for it.
I have a similar setup, and I don't waste any time logging into all of them because I simply always have them running. Why would you need to login every day? Are you shutting them down at the end of every day... if so, why?
I don't mind Gitter though, because it has a useful feature (code snippets) and it is available through a web app as opposed to a separate install.
Are they using some API? Or do they ask you for your username/password for each service and "helpfully" login for you?
Seems to be wrapping them all.
That said, I wonder what's Discord's official stance on such things. Their bread and butter is voice chat, and they seem to be fairly open minded. Maybe they will eventually provide a public API for basic text messages.
And as much as I hate it, the success can't be denied. Especially when looking at some conferences I've been to over the years. If they even had an IRC channel, it was mostly dead, but the Slack channels were buzzing with activity during the conference. I'm not sure why that is. Ease-of-use? The fact that many attendees are familiar with Slack from work, but not with IRC?
IRCCloud at least lets you see chat history, which IRC doesn't have out of the box but Slack does.
The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work...
Also integrations in general are smoother in slack than in IRC. Someone has already written the bot and its a click away to install and it generally works.
Which can also be done with IRC clients.
This is a video of a search system I built for the Quassel IRC client: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4
Quassel is a distributed system, so you have a bouncer and client which integrate tightly, with clients for Linux, Windows, Mac, Web, Android, iOS, which stores backlog in a database.
This search system is a very simple one, and simply uses postgres’ fulltext word vector search.
It's a web/android/iphone client only, but it's IRC. The moment someone grows tired of the client, they can get their own.
They could schedule downloads to their remote boxes and wouldn't have to tie up the home phone line for three days downloading the latest warez from that guy who had an ISDN line and let 10 people(!) simultaneously download from his bot at a screaming 5k/s.
Now I can have all those things (including the equivalent of 1000 ISDNs), and I don't really use IRC anymore, young me would be so jealous.
For example I can have jenkins email build fails to slack in, oh, probably less than two minutes, I've done it before. From memory I make a custom email addrs in slack and tell slack which channel to feed it into, and then add that address to my jenkins that already sent buildSpam.
In IRC I could do it... google implies there's a ZenIRCBot project on github and probably many others. Probably there are bots and tools that google didn't immediately find.
Its not rocket surgery to use fetchmail and some kind of Perl IRC library to simply POP everything out of a mailbox into a directory /tmp/wtf and probably about 3 lines of perl to read all the files in /tmp/wtf, connect to irc on some channel, output what it found, and if successful delete the emails from /tmp/wtf. Then put fetchmail and the 3 line perl script into cron and away we go.
Looks like Zapier is kinda in between "I could do it" and "AAS"
There's a reason people like slack so much. It does a ton of stuff out of the box with no headaches. Nobody wants to maintain all that stuff.
So instead of paying someone to maintain it, you pay someone to maintain it who keeps all your data from you and prevents you from accessing it, and who admits he’ll read all your stuff.
How is that better again?
That said, IRCCloud already does it for free, in the cloud, just works™, and the Quassel people are also working on improving ease of use and deployment.
You aren't paying "someone" you're paying an entire company that is dedicated to making the application highly available, with all the bells and whistles, with zero hassle.
Really, if you think IRC is so similar to Slack, then why are so many companies, organizations flocking to it? There has to be a reason.
If HN has higher discussion quality than reddit, why are not all devs on HN instead? If Linux is better for servers, why are people still starting projects on Windows? etc...
The power of marketing, directly or word-of-mouth, is important. And a decentral community can never do as perfect marketing as a company can do.
There are IRC clients and apps, and third party integrations as powerful as Slack, and as easy to use. But you have to find them, install them separately – there’s no single combined effort to market a single "just works" solution, yet ;)
Slack doesn't prevent you from accessing your data, in fact they explicitly built exporting features.
We're talking about open source, so reading your stuff shouldn't be a problem. For proprietary, maybe, but even then, reading someone's private slack info would be highly damaging to their brand, and to what benefit?
There is no such barrier for the current set of chat apps. Download > Login with google, start chatting with the person who invited you. Search history? File sharing? No need to remember anything about dcc/xdcc, no need to manage servers running bots, no need to manage anything, really; it's all taken care of by the nerds that run the service.
I think one might actually be able to build a business by building a Slack that runs on top of IRC, and releasing client apps that actually significantly reduce the flexibility that a standard IRC client gives you. If you can get the on boarding flow to invite -> download -> log in -> start chatting with the people you want to chat with, you could crush slack (assuming you had the marketing budget to compete with theirs).
I think, however, that IRC will remain in some ways as a small haven from eternal September (haha, yeah, I know). The barrier to entry is a feature, not a bug.
Someone did, it's called IRCCloud.
That's the entire problem I've been talking about above: Anything you can imagine regarding IRC already exists. The only issue is that you don't know about it yet, and have to find it. And without marketing, or any lists of what is good and not, this is hard.
with respect to something like e-discovery its all a matter of perspective. If this were true, which it isn't, I wouldn't necessarily mind, as the financial worth of combined ancient IRC logs is unquestionably a net negative value.
Wait... did you just tell me to go fuck myself?
(I haven't used either very much, so please correct me if I'm wrong.)
But yes you're right, nothing in the IRC protocol for it. There is something in IRCv3 to provide chat history but I don't know if it's even in the current version of the spec.
(You say "they're a client too" - I confess, I don't know what they are apart from a client.)
At the moment if you join a channel you can't read its backlog, no. They could implement it though if they used logs from their users... kinda wish they would. But hey.
Then I'm not entirely sure what you were referring to, when you said "IRCCloud can". Backlog from before you joined the channel is the specific feature that I was saying couldn't be done.
It's interesting to know that IRCv3 does have that support, so I was wrong about it not being possible. But if nothing implements it, it's not very helpful.
IRC and FreeNode channels have been the standard for communication and not for archival purposes. I use an IRC bouncer with my home server and I never look back through the thousands of communications except to see a reply to my question.
Why does a Open Source Community channel need archived communication unless it is just a few developers only chat?
That's not even wrong.
IRCv3 has a lot of enhancements that should move IRC out of the 1990s as far as a communication protocol, but there's not a whole lot of movement on it. I think FreeNode has some v3 support.
We don't have a lot of developers dedicating time to this. I'd love to myself, because it's something the OSS community needs, but it's also very difficult to contribute to projects when you're already doing 40 hours a week at a day job.
Today I feel like most of the OSS projects that are getting support are ones that are corporately supported:
http://penguindreams.org/blog/the-philosophy-of-open-source-...
That’s as wrong as you can get.
Networks with support, ranked by amount of supported features, are: InspIRCd Testnet, EsperNet, IRCCloud Teams, Snoonet, Rizon, IRCHighWay, freenode: http://ircv3.net/support/networks.html
Clients with support, ranked alphabetically, are:
Desktop: AdilIRC, BitchX, ChatZilla, Colloquy, Conspire, Hexchat, IceChat, Instantbird, Irssi, Konversation, KVIrc, LimeChat, mIRC, Mozilla Thunderbird, Quassel, Textual, WeeChat.
Web: IRCCLoud, Iris, Kiwi IRC, The Lounge, Mibbit, Quassel-Webserver
Mobile: AndChat, IRC for Android, AndroIRC, Colloquy, IRC7, IRCCloud, LimeChat, Palaver, Quasseldroid, YAAIC
Bouncers: Quassel, ZNC
Bots: Limnoria, Sopel, Moon Moon
http://ircv3.net/software/clients.html
And libraries are: cinch, Communi, irc-framework, Kitteh IRC Client Library, Net::Async::IRC, pydle, Rust irc, Warren, zIRC
That’s quite a whole lot of movement. That’s every project related to IRC
You don't log into irc from your work or your home or your anything.
You run screen in your shell account and log into irc once and never log in again.
Christ - do we need a refresher course here in how to use the Internet for the incoming freshman class of 1994 ?
Chatting is interesting because of other people. That's why I'm chatting.
In Slack, I can ping people that are offline. And all they have to do is open Slack again or reconnect to the internet and they get notified. I don't need to count on them being an IRC veteran.
All these people pointing out ways to enhance your personal IRC experience are missing the point.
Oh yeah, and I can post code in Slack.
TheLounge and ircanywhere are missing a lot in comparison.
And other projects, including the GPL project Quassel, do have mobile clients (although Quasseldroid, which I maintain, isn’t exactly the best client in the world).
Yet even Quasseldroid manages to be better.
That said, there is truly a need for a really good, FLOSS irc client ob mobile.
EDIT: and we aren't talking about code-base, are we? If so, Lounge's is pretty solid (although it is in a pretty constant state of transition from ES5 -> ES6)
Quassel actually has both of those, but they’re still in separate projects atm: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4, and will only be integrated into the main codebase in the next version.
That said, the performance of Quasseldroid, due to the nature of the thing, is a lot better.
And I don't think you can say due to it's nature it's faster... I run Lounge in 20+ active channels on my iPhone SE and it runs perfectly. Native != more performant (and if the code base is as bad as you say I wouldn't expect it to be).
But what I consider a bug is already the best case scenario for the web client.
And 20+ active channels is nothing.
I'm in 460 active channels, with combined 40'000 users, and I get about a hundred to 200 messages a minute, while using the app on 64kbps connection.
(That's my test case for what should usable)
And quasseldroid already has code for those two, and a rewrite is almost done, I'm just waiting for the core changes to happen, and then release version 2.0
WordPress.org seems to fully integrate Slack into its processes. And as a now outsider, intuitively, it seems they've been able to scale their community more and continue their rapid development.
The OP does make a fantastic argument on the open/public point, but synchronize communication is also a necessity for collaboration.
The WordPress community Slack forced Slack to implement some server-side changes when it hit ~5,000 people though (I don't remember the exact number, but I remember when things started to not work), and I suspect it's the largest resource-consuming instance in my Slack client.
Compared to IRC, I have to:
- Figure out how to configure my client.
- Figure out how to interact with the user account and moderation bots on Freenode or $other_server.
- Figure out how to set up something like ZNC in order to federate the client on my phone with the client on my laptop so I don't miss messages.
- ...
/join #rust-lang
However, having that global identifier / IRC network connection is a tradeoff - it forces you to use a single consistent identity for every single interaction on that network. For some people this is a plus; for others it is a negative. Slack's teams option allows people to use different identities for different instances.
> [...]
> - Figure out how to configure my client.
> - Figure out how to interact with the user account and moderation bots
I disagree with your initial claim. :P
Those are irc basics, things you only have to learn once, and there is documentation online and on the web. It's worth it to spend the time to learn a tool that you can use throughout your profession, even as the proprietary flavor-of-the-month services come and go.
This all reminds of a few years ago when folks were banging on about how we needed to use Gitorious instead of GitHub for Open Source hosting. Gitorious is dead now and it wasn't until GitLab came along and recognized the usability problem that we got a viable Open Source alternative.
Trying to get everyone in our group setup with mumble was a pain for the people who only use their computer to game. When we switched to Discord it took maybe 10 minutes to get our group of ten all in one chat.
I use slack at work and love it. I fully agree that it isn't that different from IRC and I hate that it's another walled garden (of sorts), but it fixes a lot of the little annoyance in dealing with IRC.
Also, fwiw, most of my colleagues use IDE "search project for string" in places where I use grep. Also, if I'm being honest, you should hire nearly all of them before you hire me.
I think you've picked two false flags.
I like knowing that it's going to handle unicode properly, in all cases, for everyone on the Slack channel. I like that it handles right-to-left text for everyone reading.
I like not having to ever think about, is my bouncer down? I also like not having to think about, where am I going to run my bouncer? It's nice not having to think about that stuff at all. I've got a lot on my plate, keeping a bouncer up and running somewhere (just so I don't lose history!) doesn't need to be another thing I do.
I like the plugins, the integrations with various other services. I like the convenience and polish. No IRC client compares to Slack for integrations and polish. It takes friction out of my daily chat experience.
I've even moved some private irc channel chats to Slack channels, because it's just a more pleasant experience in 2017. No regrets about any of that.
Despite the nostalgic kick of it, I never used it as a serious work tool at any of my jobs, haven't used IRC at all in probably a decade, and totally agree that options like Slack are just plain better work communication tools.
I had to use IRC again in 2015, and pretty much nothing had changed, except now I was 20 years older.
Most of the criticisms of Slack seem to boil down to: this (whatever it is) is something IRC could do. But it (whatever it is) is virtually always something IRC doesn't do, something it does in some half-arsed fashion (that requires a huge amount of fiddly setup), or something that's supported by only a few clients. How is this not obvious? I'm perpetually mystified that anybody would admit in public to not understanding why Slack is taking a massive dump on IRC.
(Criticisms of Slack's closed nature are valid. It's also worth asking why it has to take up 2GBytes of RAM just to show a tree view, an HTML view and a text box! But don't tell me that you can't understand why Slack is winning anyway.)
It's not a generational thing - it's a "lifer" vs. "non-lifer" thing.
Some people are coding with computers because it's an exciting, lucrative career with great benefits!
Other people are coding with computers because they can't imagine doing anything else, and would do it for free if IT wasn't central to business in the 21st century.
The sign-up process for Mattermost is easy. It's intuitive, cross-platform, mobile-friendly, etc. While we geeks are used to IRC, onboarding people to IRC is no different than any other product: the smallest glitch, weird UI, confusing elements will make people drop off pretty quickly. I have always had to sit down with someone to show them how to connect to IRC. We would waste time at code sprints showing people how to connect.
With Mattermost, we have unlimited logs (so we can cross-ref/permalink conversations in the issue trackers), threaded conversations (great for when the channel is noizy), emoji reactions (friendlier atmosphere), etc.
However, I agree with the article: Slack is inappropriate for open source communities. Mattermost and Rocket Chat are good alternatives. Between my IRC habits and what I can do with Mattermost, I find Slack very frustrating (and I don't use it anymore). Then again, as much as I like IRC, it's not an alternative either.
For anyone who'd like to try an open source Slack-alternative, you can start in less than a minute with auto-deploy via Bitnami: https://www.youtube.com/watch?v=AKqHWqrAgpk&t=9s
Goes to AWS, Azure, GCP, Oracle Cloud, all data under your control, Mattermost Team Edition runs under MIT license.
Also, check out our new React Native mobile apps: https://github.com/mattermost/mattermost-mobile
The biggest benefits for us:
- Easy to use web push endpoints w/ API keys (great for scripting with curl)
- Integration with Gitlab / Jenkins
- Chat Logs (see what happened while you were away)
- Public listing of channels (no more "oh you have to join #whatever to see that")
- Mobile Web App (I can't get the Android app to work with our self signed cert, but that's OK).For others, here's another article of replacing IRC with Mattermost in education: https://opensource.com/education/16/3/mattermost-open-source...
1) Person pushes to dev branch
2) Chat log shows the feature pushed
3) Chat log shows Jenkins received push and is downloading
4) Chat log shows whether tests were successful (yay) or not (boo).
^^ that's the basis. It helps keep everyone up to speed on what's going on, especially for testing.
One more example: Notifications when merge requests are made / merged in the chat.
By adopting an incompatible web model, they lock people and their messages in, and can charge per user in the room. As a good IRC client, the most they could get away with is a subscription charge per client, which has the downside of creating a barrier to entry that limits adoption (requires everyone who wants to use it to pay, v. a central employer or organization that can compel people onto a chat platform).
Users like web-based because it means that they just click a button and the thing they want magically appears with no install process. Companies like web-based because it allows them to box all the secret sauce behind a server that can't be introspected. There's no risk of someone cracking their program and distributing it for free, and they get to keep complete control over the crown jewels, which are now and always have been the data that the program purports to manage.
Just keep your hands off my mailman ...
If you find yourself repeating the same thing a lot in chat, it would be a good idea to document it somewhere and just paste a link. With a link to the relevant documentation, a lot of people will just do the rest of the legwork on their own, and will now be able to quickly reference it going forward, and hopefully bug you less in chat (you can always be explicit and refuse to answer people, asking them to read the docs instead).
If you find you're pasting too many links too frequently, then it's time to make an FAQ with those links, and start linking to that.
Culture-change is about the hardest thing to achieve.
* Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread.
* Allow the user to collapse a thread so they no longer see it in-line.
* Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan).
* Allow the user to navigate between threads using only their keyboard.
As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).
Just because Slack isn't good at slow conversations doesn't mean it's bad. Just because email is bad at including people who joined after the fact doesn't mean it's bad. Those aren't their strengths, and that's fine. They still serve their own purpose just fine.
You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.
> Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?
Given that the cost to you is 0, what cost to them is required for it to be justified to you?
It seems odd that providing a free but limited service is evil, based only on it being slightly more expensive to give you an even better service for free.
Ok, well the alternative is no free version. Yeesh, people are so entitled. They're trying to give you a mostly full featured version of their software in hopes that you'll pay them someday.
On reddit, if the time is not right, the discussion will not be had and ends up in oblivion.
Doesn't work with reddit.
New services replaced many things that forums were used for, but not all.
Probably the main reason why Slack – and Gitter, and IRC too still – are widely used by open source projects is that they're free, financially, and mostly free in terms of maintenance.
Interestingly enough, most people I know found the Google groups interface significantly worse compared to their Usenet client.
WTF?
How is it even remotely sane to provide a user interface instead of an API/protocol?
I don't care to learn your forum's user interface, and I don't care to poll your forum for new content. I have a mail user agent that's configured to fit my needs and that I know well how to operate, and that's where all the mailing lists that I am subscribed to push their new content into this one unified interface for me to interact with them. Web forums for the most part are just a pile of broken usability.
It's the way of the world. 20 years ago we had NNTP, POP, and IMAP, and you could read them all with Gnus, customized with finely-tuned filtering and killfiles. But it's hard to "unlock value" from these things, so then there were ad-strewn forums, and now SaaS abominations, because how dare you not change your mail client when its developer thinks you should?
I have recently been participating on Reddit and I still like HN, but I am spending less time of late on another forum I still belong to. For me, part of the answer is that forums are heavily influenced by moderators and most of them are not anywhere near as good as what you see on HN. So, if you have personal friction with the mods, good luck with that!
The internet is this awesome opportunity to rub elbows with people around the world. Then the admin structure very often gets you stuck in "I shot the sheriff" * hell, where no matter what you fucking do, some asshole who doesn't like you and is in charge rides your goddamn case and deletes your shit for bs reasons and so on.
I don't know how to solve this problem. Most forums don't seem to be able to get it right.
* This is an old song where the plot is that the sheriff was making his life unbearable and there was no other way out, so he finally shoots him.
That's why I preferred Usenet over forums. All filtering is done by the client and is under your sole control (outside of moderated groups).
But the main huge drawback, from my point of view, is that non-anonymous model of conversation means people more inclined to judge you from looking at your profile and not from the specific local reputation, which was a thing with forums.
Usenet, on the other hand, didn't have these problems, though it pretty much ended up the same way.
Synchronous communication, indeed, is bad for the main communication channel. However, as a secondary communication channel, it can serve important needs.
When people are looking not to just get a single issue resolved, but to form a community, this community is often based on informal communication and emotions. Seeing the same people in the member list every day, exchanging little inside jokes, getting to know individual members of the community on a personal basis — this is something completely irrelevant for the user of the open-source product, but can be an important emotional component that motivates people to stay in the community and continue to put in effort into the project.
And, of course, a synchronous channel, where you can get more lax on moderation, is a much more suitable tool for this purpose.
Is this a problem?
Ostensibly one should hope to be able to communicate online in the same manner that one does offline: without paying an intermediary
Further, if the 'natural trend' of economics is towards commoditization of products, why then are we abandoning those things which facillitated decentralization in order to support another entities profit motives?
We're gravitating towards better products. Sorry, but having used IRC a lot, Slack is just better.
your point fails to address this point; similarly 'better' has varying metrics.
...about what other people are writing in the main communication channel, creating precedents about what should be discussed with "individual members of the community on a personal basis" and deciding the content that should be written on the main channel for the benefit of outsiders asleep in other time zones, ...
I've intended to reply to communications before only to discover that someone else replied first while I was asleep in my other time zone.
I strongly agree with both criticisms of using Slack for open source, and I am impressed that Dave wrote this post, given that some of those criticisms apply to his own product.
However, I think the proposed solution of relying on mailing lists, issue trackers, and forums is the wrong solution.
Support for synchronous communication is not the problem with using Slack/IRC/etc. for having discussions in open source organizations. After all, even with "asynchronous" media like email, bug trackers, or forums, often people reply basically immediately (within minutes or maybe hours), just like you can in chat, and it might be hours or days before everyone has a chance to see the conversation and respond.
The problem is that the messages have no organizational structure beyond the channel. In Slack and friends, there's no easy way to see what _actual conversations_ happened while you were away, and it's really hard for a channel to discuss multiple things, so conversations either die or become hard to read when someone starts talking about something else. Combined, this means you have to (1) read _everything_ in order to know what happened and (2) be continuously online in order to participate effectively. This may not matter if your community is super low-traffic, but if you have hundreds or thousands of messages being sent daily, this effectively excludes everyone who doesn't have a LOT of time to spend on the chat community.
It doesn't have to be this way. Nothing prevents creating group chat software that handles both synchronous and asynchronous communication well. In particular, Zulip is built around a simple threading model that solves both of these problems. In our own chat.zulip.org community, people constantly contribute valuable commentary or feedback to a thread that started a few days and hundreds of messages ago. And I can come back from a week's vacation, and skim the 5000 messages that might have happened while I was gone, and easily reply to all the threads where I have something to add.
(As a sidenote, it's easy to post permanent links to conversations in Zulip, which we use regularly in the Zulip issue tracker to point to the original discussion that led to a given proposal. But the important problem isn’t the link part, it’s separating the conversations from each other: without something like Zulip's threading, reading chat logs can be a slog).
Other things I like about it:
- e-mail addresses in addition to nicknames
- working full text search over everything
- plenty of well thought out keyboard shortcuts
- high quality production tooling (they even have Nagios checks, out of the box!)
(a) Can't be referenced or linked from the Web, and
(b) Is a form of synchronous communication
The same factors, BTW, apply equally to in-person discussions held at open source conferences. I wonder what the author thinks of the value of those insofar as "open source communications" are concerned.
Meanwhile my mostly idle Slack with perhaps a couple hundred users across four teams was consuming 1.3GB of memory.
Not to put too fine a point on it: it is a piece of shit software.
The value of synchronous communication is very real and it should not be precluded, but the points are totally valid. Slack is a closed-garden and it does not contribute to the global conversation if the access and historical record is controlled from within.
Slack extended their not profit pricing to 501(c)(6) not profit organizations which covers CNCF projects like Kubernetes.
Nobody changes clients, tooling, etc. That's the difference between a closed walled garden like slack and an open protocol.
The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.
I say this as someone who's used IRC a crapton and is a strong advocate for open protocols (and for more than just ideological reasons): Realistically, if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions, which is happening today anyway. A protocol needs users.
The only thing IRC has got going for it is federation and openness. It's not easily extensible, it's not secure, it can't benefit from most of the advances we've made in comms and protocols since the 90s, and there isn't even a common format for your messaging history - most clients just use text logs!
If you want to advance the state of comms and ensure humans are using open protocols to communicate rather than walled gardens, you first have to acknowledge these flaws and needs. Propping up IRC as something it's not doesn't do anyone any favours.
Other IRC networks than Freenode and OFTC exist too.
As far as security goes, SSL is an option for client<->server connections. I hope that at this point it is default for server<->server connections. What else are you expecting for security?
IRC won't survive the loss of Freenode. With Quakenet dying off (its userbase went from ~65k in 2013 to 23k today), Freenode is the last central bastion that keeps the protocol in people's minds.
FOSS projects today are migrating off IRC, onto Slack and Discord instead. This is why you have an article here talking about it and it's not the first one. If Freenode disappeared, this would accelerate massively. The projects won't bother going to another network because the topic of "Where do we go now?" is going to be asked and in most cases is going to be answered with "Well, we wanted to move to Slack/Discord anyway...".
There will be a few projects left on OFTC, certainly. But they'll give up and go elsewhere eventually as well when they'll see their userbase shrinking 5-10x due to other projects migrating elsewhere and taking their users with them. They'll probably end up on Matrix.
You aren't serious, are you? Because the new client runs on the same virtual machine, you are not changing clients? That does not really make sense to you, does it?
> The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.
(1) I haven't ever heard of a computer changing its operating system from MacOS to Windows because anyone but the owner of that computer decided to make that switch. How would that happen?
(2) Erm, no, not necessarily?
If the UI changes, the client has effectively changed for the user. Otherwise you might as well argue that clients are all equivalent if they are running on the same OS.
>but the UI also changes when you go from a Mac IRC client to a Windows one
Only if you use clients that don't look the same.
> if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions
No supporting evidence that they would drop IRC if this happened. You must have missed the part about a network switch being literally a config change. Compare that to dropping irc which is all of your tooling.
>most clients just use text logs!
There is nothing wrong with a text log. Also, which common format is your browser storing your slack messages in?
Most of your complaints apply just as equally to chat inside of a web browser (other than the security issues).
>Propping up IRC as something it's not doesn't do anyone any favours
Tell me how my comment is incorrect. You literally change a config to change networks, that's it.
But that said, I don't put anything on Github if I can avoid it. Disgusting organization with awful management.
It's near feature parity with Slack and it's also one of the best IRC clients around. I used to run ERC in a tmux session just so I could stay connected and not lose messages. No more.
> But personally I prefer a little personal interaction over a long chat.
Although it's hard to schedule an 80 second meeting between five people, but a quick set of questions and answers might only take that long.
Chats are much less interrupting. When someone walks in, you have to look at them (it's rude to keep typing and look at your screen), your brain starts to assess who it is and their mood and pulls into an appropriate facial expression, and you have to start listening because your audio buffer is much more volatile than your chat client's message log. Even if you're just finishing the "hope to hear from you soon" of an email, you typically have to acknowledge someone's presence and already detect who it is (someone two levels above your paygrade, you'd not want to keep waiting, while you would let a peer wait for that email to get sent out). I don't know how much of that subconscious activity really interrupts flow, but I notice it's annoying.
For chat, group messages don't trigger notifications and they just get looked at when I have a second. If someone needs me specifically, they'll mention me or send a private message. In those cases, I will notice the notification but will (depending on how concentrated I am) either not process it beyond "there's something" or not beyond judging whether it's urgent (based on the first five words, or whatever makes it into the notification). I catch myself thinking "wait, someone sent me something, I totally forgot" and it turns out there are no unread chats. What must have happened is that I alt-tabbed back and forth to make the unread-message counter go away (and give them the double tickmark to indicate I saw it) because what they sent did not need further processing (something like a final "okay"). That did not interrupt flow.
---
On top of that, what others have said: external people (at clients', at home, whatever) can follow chats along; you can do stuff in between messages; you can pick your nose during conversations; and you can have an 80 second meeting between five people.
I think an uninterrupted private office and "instant" messaging are not mutually exclusive things.
Personally I've noticed people tend to take a longer time saying something in chat than they would in person. And if I have to wait for a reply I'll probably start doing something else, potentially making the chat conversation go even slower.
I have little experience with group chats, in my limited exposure to them they tended to be more focussed on fun than productivity.
I also seem to be one of the few people that can quickly context switch between a conversation and actual work.
If someone wants to talk in person or via voice instead, my heart always sinks a little, because it means I have to drop whatever I was doing and give the conversation my full attention instead. Once we're done, I have to try to remember what I was thinking about before the distraction happened, get myself back up to speed...
This doesn't come up so frequently anymore, but it was very noticeable when I used to work remote. Some coworkers were happy with chat, and it was easy to communicate with them; with others, it'd be like twenty seconds of productive conversation, then "can we please just have a call about this" and, oh god, that's it for getting anything done for the next 40 minutes.
I find the same to be true on (small) Slack (or similar) channels. Which is funny given that Slack being synchronous is one of the two main points of the link.
It remains to be seen if it has proper AD integration for example.
You have remote workers, flexible schedules, people traveling everywhere, all doing knowledge work that depends upon sustained focus and reaching a flow state. All of which Slack and synchronous chat detract from.
Slack just happens to be easy and convenient, so orgs end up using it by default.
Obligatory link to 37 signals post on this topic: https://m.signalvnoise.com/is-group-chat-making-you-sweat-74...
And Discourse is pretty great, though much more like a forum.
Using IRC/Slack in place of forums is like using a wiki in place of real documentation.
I hear this a lot, in terms of older tools being considered obsolete.
Other than the natural human tendency towards novelty and the network effects, what, exactly, is obsolete about mailing lists or IRC?
What features are missing in IRC that Slack has for synchronous discussion? (I'll start: animated dancing pigs out of the box and the need to write/plug in your own archiver.)
What limitations do mailing lists impose on open source development that are not present in other tools?
None, in my opinion. On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages — that is coherent enough to be highly useful when searching archives later.
Newsgroups also have this structure and they have the advantage of easily doing an archive search (by being able to download part of or the entire message archive of a given group and using the search features of your mail/news client).
Quoting is still a problem. Most answer above. Some below. Many nitpick in between.
Threading is easily broken. Especially if Outlook users are involved.
Formatting is an issue. There is no markdown or whatever for links. Some people insist on line lengths and other stuff.
One thing I've noticed on Hacker News, Slashdot, and even reddit is that if someone quotes the post they're responding to, they'll invariably post their response below it. And if they quote multiple parts of the parent post, they'll interleave their responses. I don't recall ever seeing a response where the quoted text is below it.
I've really never understood the rationale behind top-posting. It makes it much more difficult to understand the context of the response without having to jump between the original message and the response.
> Threading is easily broken. Especially if Outlook users are involved.
That's because Outlook does not follow the relevant RFCs in terms of maintaining a message through through the In-Reply-To and References headers.
> Formatting is an issue. There is no markdown or whatever for links.
Most GUI clients will make links clickable. There are also conventions such as using astericks, _underscores_, or /slashes/ for bolding, underlining, or italicizing text, but a lot of clients don't render them consistently, IME.
> Some people insist on line lengths and other stuff.
There is an RFC that adds format=flowed to the Content-Type header. Then every line that ends in a single whitespace character will be joined with the next line and wrapped at screen width instead of at the position of the CRLF characters. Clients that don't support it will still see the wrapped text.
Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX. Google groups mostly fixes this because they're really just a forum that supports emails.
IRC is terrible because everyone has their own client, so you never actually know what someone will see when you post something. Post a link, - will it get auto-expanded? How will it look? Will it get auto-linked? If you @ someone, will they get notified? if so, how visibly?
IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.
Slack has mindshare, which leads to having a ton of integrations with other platforms, which just multiplies its effectiveness.
I 100% agree that I wish they offered a publicly visible option, so anyone can view without logging in. I also wish they natively supported self-registration.
I have to echo another commenter on here. If you want the best of all worlds, a forum is what you're looking for. Publicly visible, easily linkable, long form, asychronous communication. Whether that's google groups or something else is up to you.
This part I really do find annoying about IRC. I use IRC by far the most but this still gets me. Even if you run it in a screen somewhere it's a hassle from a mobile device. There's solutions for all of it, but you have to string a series of things together to get to something just about every other option offers you out of the box. Unless you have a particular need for IRC or have used it for a while and know how to deal with it, the other options are more appealing to newcomers. Depending on how young your project or community is that can make all the difference.
Unfortunately, the Slack gateway implementation is subpar. In my experience, it will send me the last message I sent before I disconnected when I reconnect, but it won't send any of the other messages that were sent in the meantime. The other problem is that group chat only works over the IRC gateway, not the XMPP one (at least I could join it from my XMPP client, but I couldn't send any messages to it).
In contrast, the old XMPP server we used would just replay messages in group chat when you reconnected, so at least you wouldn't miss anything when you weren't connected.
Edit: s/Slack implementation/the Slack gateway implementation/
Gmane actually works really well at addressing the problems you describe in terms history. Their NNTP gateway allowed me to download and search the git mailing list messages since 2009 in my email/news client.
Sure, there's lots of freely available alternatives, but even tiny (but non-zero) costs in time and money are the difference between widespread usage and relative non-use.
I setup Gitter on a GitHub repo for a project by clicking a button and accepting a pull request that Gitter auto-generated for me to add a link to the repo's Gitter channel in my project's README. That's the competition that every older tool is failing miserably to meet, let alone exceed.
You are ignoring the costs that come from lock-in (inflated prices, lack of innovation) and migration in case the proprietary solution shuts down. That's the psychological tendency of humans that these companies exploit.
Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.
A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.
It's tradeoffs all the way down!
That's not lock-in. Lock-in is when you are dependent on a (quasi-)monopoly, not just any potential migration cost.
> Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.
No, actually, they don't. The point, as above, is that it's not the sole decision of another party when a 'shut down' happens, that is, again, there is no monopoly. First of all, if you have free software running on your own machine, there is noone but you who can decide to just shut it down today, but also, in the long run, you can just take over maintenance of the software yourself, or you can buy/hire a software developer to do it for you, or you can get together with other users of the software to hire a developer.
Also, more generally, with regards to open interfaces/protocols rather than necessarily free software: No, email cannot be "shut down" because "the unpaid developers burn out". And changing my email client or server or hosting service does not necessitate everyone else I want to communicate with to do the same.
None of that guarantees that you can keep using things indefinitely at an arbitrarily low price, but that's besides the point: The price is determined by a market, and not by a (quasi-)monopoly.
> A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.
Well, yeah, those people are just clueless, if only because they confuse freedom with not paying for something. If you want to have something maintained, how about you pay for it? How does it make any sense to say that you prefer being forced to pay for something because you otherwise fear that it's not being maintained if you don't pay for it?
Also, none of this has anything to do with open protocols (which was the primary topic of this thread, kindof): Microsoft is being paid very well for maintaining Outlook and Exchange, which is both proprietary software. They still speak SMTP with the rest of the world, instead of forcing everyone to buy Outlook and Exchange to be able to communicate with their users.
and Telegram and Wire and Riot and Semaphor and Tox and... Plenty of non-closed tools.
I really like Slack for a lot of things, but it's often a tool used incorrectly due to its popularity.
It's quite amusing that the author takes his (valid) argument about the problems of closed, synchronous communication straight to the language of privilege, discrimination, and oppression.
You understand that 'discriminate' and 'privilege' are regular words with regular definitions that were used by regular people for hundreds of years before you came along with your chip on your shoulder, right?
Or to abuse a metaphor, OP is arguing we need to use boats instead of cars to ship heavy things overseas, not that cars are an unsolved problem.
Full Disclosure: I work at Discourse.
Discourse is also not easy to setup, its quite involved and complex and you need some Ruby and systems expertise. Infact I think Discourse only supports Docker installs. So you need to know Docker too.
Given the complexity you should be pretty comfortable with Ruby to run it with any amount of confidence. The hosted option seems much better than trying to run it yourself.
Also the Official Install Guide[1] doesn't require any Docker-fu.
Also, we give hosted Discourse for free for open source projects with a big enough community to have a forum[2].
1: https://github.com/discourse/discourse/blob/master/docs/INST...
2: https://blog.discourse.org/2016/03/free-discourse-forum-host...
Slack's UI is good. Not perfect, but it's quite usable compared to all the alternatives[2]. People always underestimate the value of good UI.
[1] https://twitter.com/zellyn/status/851818007248678912 [2] I've been on IRC on and off since 1993. It's much worse.
If you want to have an open process (for discussions around proposals, bugs etc), you need an open, linkable, archivable format, ideally hosted somewhere you control. That means mailing lists or a public html server, not a private chat service which may or may not be around, which may delete data or change policies at any time. For this reason Github isn't great either, but at least it has public links and you could scrape the data if required.
So? There are services offering that, too. Linkability is easy to add to IRC as soon as you are using logging systems and modern bouncers such as IRCCloud or Quassel.
Have you never replied to an old forum post and been accused of 'necromancy'?
Have you never been late to reply to an email chain or a thread on a mailing list or forum?
There's no clear line dividing asynchronous versus synchronous communication. Even phone calls can be (partially) asynchronous – "hold on, let me check" let alone "let me call you back in <some amount of time>".
And similarly, if a group of people are responding to each other quick enough, even using an 'asynchronous' medium, then they're basically communicating 'synchronously'.
https://www.effectivediscussions.org/ (ED)
It's open source. It seems to solve the problems mentioned in the article (I mean, openly accessible — can link to a discussion & (soon) to a post in a chat channel. Both sync & async communication (both chat and traditional forum topics).
I'm actually just about to a-little-bit start promoting it. ... Ok so let me try to make you more interested in ED:
- Often, organizations setup a chat (e.g. Slack), a forum (e.g. Discourse) + use e.g. StackOverflow — but then they've split their community into three. However with EffectiveDiscussions (ED) you can gather everyone at one place.
- ED is looking to improve the quality of the discussions. For example, there's a novel voting system that solves (I hope) problems related to people downvoting-because-they-disagree, + a novel algorithm for finding the "best" comments (in threaded HN style topics). Plus some other improvements over HN & Reddit, see https://www.effectivediscussions.org/-32/how-hacker-news-can...
(As you might have guessed, I'm the one developing ED.)
In its early stages, but working beautifully.
[2] https://hackernoon.com/how-jaypads-help-us-build-jaypads-c66...
[3] https://hackernoon.com/how-planning-a-weekend-trip-with-our-...
Now, I am not a proponent of slack, I think it has its own problems, but I don't think email is any better.
Addressing another point, and though I do use a Slack imitator for a small non-work/non-programming group - an advantage of IRC is that it can be part of many chat clients which handle multiple protocols. Thus I have IRC open with multiple Jabber chats and mucs. Slack et al, at least on the desktop, are space hogs (from those I have seen) and when I am working, space is a premium commodity even with two large displays. The last I checked, IRC integration into Slack is cumbersome and lacking, is this still so?
"Slack is inappropriate for open source communications" - Your friends at Slack.
4. TypeScript at Slack (slack.engineering) 183 points .. 5 hours ago | flag | hide | 86 comments
5. Why Slack is inappropriate for open source communications (cheney.net) 615 points .. 12 hours ago | flag | hide | 395 comments
Quite random, but I couldn't help but notice.
https://gozman.github.io/slack-rss/
So that is one drawback to a closed system.
What reasons?
How in the world would you improve mailman ?
Not enough js for you ? Not enough on-hover events ? Too much plain text and obvious links ?
Please, please - to everyone reading this today and into the future - do not fix mailman. Go "fix" something else.
My email address was already validated with main site sign up, I shouldn't need to repeat that for every mailing list I want to subscribe to on top of that.
If you're reading this from the future, please let me know if any open federated systems managed to come into being, or if spammers finally managed to kill off email so important business is conducted via Snapchat.
If not, given that searchable archives are one of the ways Slack makes money, makes me wonder why there's not an open source way to pull the chats and archive them in a way that's cheaper and independent of Slack.
forbid creating an off platform archive
Just try and stop me?
Probably they don't care enough to enforce, but surely you see it's part of the problem that they could?
They can't stop someone from creating an archive that's inaccessible to them, if they don't know of its existense. Anyone can create an archive of something they can read and hide it, and selectively share it.
Such an agreement on curtails specific forms of automated crawling and public-facing archives.
(a) is fiddly and a bit technical but has been solved-ish for ages before slack existed
(b) is fundamental though. If it's a big archive, it costs real money to provide access & search to. If you break it up, search-ability tends to suffer.
None of this is new, slack is just the latest flavor
How often do you find solutions in public archived mailing list posts when Googling problems? I imagine often. While some e-mails are more terse than others, fundamentally e-mail list posts demand a certain structure. Can you imagine having to pour through a 25-page chat log instead?
And with that, the entire idea of "search the archives before asking a question" would go to pot.
The argument for AOL/MSN etc back when the Internet was new openness for the unwashed masses just a dream is exactly the same being made by slack i.e. that by making it locked and taking away the complexity introduced by the existence of cross vendor compatibility new users face less confusion.
But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time.
This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have input from stakeholders around the globe).
But it's often used for the reverse.
If my org takes pride in consensus for everybody, everybody needs to have the time to submit input. It's not uncommon that some active users in a chat go for an ad-hoc decision just because they are more than one and want to work _now_. In the long term this damages the culture, splits the participants and is difficult for newcomers.
I gripe because I am a US left-coaster who works with a team that is increasingly based in Western Europe. By simply deciding to rely on Slack, they have essentially cut me from development conversations other than the weekly live session.
But this is such a big deal. You make it sound like a good interface is trivial. It isn't, and it makes a huge difference.
Check out ircv3.net
That's a pretty huge feature. Never underestimate how making something more usable increases it's popularity.
Get a good GUI client, enter some parameters into a text bar, click 'ok', then chat. exactly the same process as a web browser..
The real problem is the 'endless summer' of tablet-era people who confuse the 'interweb' with the 'internet'. There used to be much more general community advocacy and understanding of promoting open communications 'baked in' to the internet culture which has been eroded by crass commercialization - this is the real problem that needs to be attacked...
Async shines when you have a lot of users, but only if it's very accessible (searchable). Otherwise it's just people repeating themselves constantly.
Also, longer rant on the IRC thing. For the past decade I've been using IRC as my central mode of group communication for all open source work. Last year and as part of my (open source) company, I've completed the switch to Discord.
I'm an open source die-hard and it bugs me that Discord isn't open source yet, but I believe this has a fairly high chance of changing (MUCH higher than Slack has at any rate). I would heartily recommend Discord for open-minded open source communities.
I'm now using Discord for everything. It has given me a unified interface for all my personal and group communications, easily searchable, with voice chat too (and video chat very soon, I cannot wait to never open Hangouts again). Needless to say, I'm a huge, huge fan.
Slack has none of that. The #1 thing that bugs me with Slack is the forced separate accounts for every single Slack instance. And you can't delete any of those accounts, you can only "deactivate" them.
Our open source community uses it. It works really well for us because we're a gamer-oriented open source community, so Discord is already pretty well known in that circle. On an ideological level, its API gives enough control over everything that goes in in it that I'm satisfied I could move to another service, should I need to. If anything, it's harder to move off IRC because there's no public logs, easy point of contact for the regular users, etc.
Also, I'm using Matterbridge to mirror our public channel to IRC: https://github.com/42wim/matterbridge/ (highly recommend everybody here checks it out; it supports a lot of protocols)
IRC has really disappointed me the past few years. I had a lot of hope that irccloud.com would offer a solution to IRC becoming irrelevant in the face of Slack and Discord, but it just hasn't happened. They're understaffed and don't have enough money coming in.
There's also a lot of ideological purity in recommending against SaaS "centralization" for comms but the truth is, it's not better. Last year my HDD crashed and I lost the logs for my organization's original channel going back to its creation... I'm very, very sad about that. Had I been using IRCCloud (or Discord) at the time, I wouldn't have lost all that. Granted, those companies could have, but the chances are lower than me fucking up.
This is the same reasoning why email is usually better off handled by companies whose livelihood depends on offering you the service, than by yourself.
Also like I said elsewhere in this thread, for a project using a Freenode channel and another using a Discord/Slack server, there is no difference between Freenode disappearing and Discord/Slack disappearing. Your host disappears, you have to find a new one, update tons of references and contact lots of users to let them know. On IRC, that's even harder. You can run your own IRC server, but very few do that, and those that do get less mindshare because connecting to yet another server is very annoying on IRC. It also costs you more, both in money and maintenance.
There's tons of FOSS alternatives! No excuses!
Such a shame that you can't make a link in one closed system to another closed system.
> The tools that fit this requirement best are; mailing list, issue trackers, and forums.
Mailing lists suck. They're hard to read, hard to follow, and create an endless supply of unresolved issues that everyone forgets about. Big projects using mailing lists seem to do so out of inertia rather than choice.
I find them quite easy to read using a mail/news reader and connecting via a NNTP gateway like gmane.
(My org uses it having replaced Skype for team chat, and so far it's been an improvement for us.)
Why a proprietary issue tracker that requires that people make an account with them in order to communicate with you?
Offer an email address for bug submissions.
Of course, feel free to use a bug tracker internally if you like, and possibly even with a public user interface for people who want to use it, but a user reporting a bug to your project should normally not need more than a working email client.
I have an email client that's configured to fit my needs and that allows me to efficiently process lots of emails and to write and manage outgoing messages in a single unified interface, and that's all that's really needed for most bug reports, so don't try to waste my time by forcing me to learn your user interface of choice that's not going to have the features that I want to have anyway.
I'm just saying that IRC+Mailing lists aren't good enough.
> these services are not open