Hacker News new | comments | show | ask | jobs | submit login
Why Slack is inappropriate for open source communications (cheney.net)
847 points by im_dario on Apr 11, 2017 | hide | past | web | favorite | 521 comments



We are, temporarily, in a kind of dark ages of end-user open source software. The reason is that we shifted from software-as-a-product to software-as-a-service.

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.

[1] https://blog.heroku.com/heroku-button


The costs for an Free / open source developer haven't changed in this "new" world. Distribution of software is the same as it ever was.

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.


You're arguing semantics. What most people are looking for is a "service bureau", and they use the word software to describe that. People don't want to manage their own infrastructure, and right now will happily pay for someone to take care of that for them.

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'm arguing semantics because I believe the semantics matter.

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.


Well said. Ideas are not scarce, only the physical realm is. Its not hard to envision the coder being paid to code; when no more code is being written, there are no more checks coming in. Nobody is owed anything based on past accomplishments. In the information age, reputation is _everything_.


It's not semantics... It's a wholly different methodology. Software is software. Your idea of a 'service bureau' is a completely separate concept that can, in some cases, be attached to software but it's not a core concept of software itself.


Blockchains don't really solve that problem. Scalability is a huge issue, and if you are trying to cram several apps onto the same blockchain they are all going to have scaling issues simultaneously​.

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.


I agree about blockchains, but when talking about P2P solutions in general, many scale way more naturally than centralized services.

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...


The N^2 problem of Bitcoin and Ethereum is solvable through sharding. I agree that on-chain scaling is impossible (and the two projects differ in their taste for decentralization vs scalability at their core), but the build out of workable sharding solutions with reasonable trade-offs and a workable topology are underway by both camps. It's just going to take longer than I think a lot of people who bought in with the pay-per-service use case would prefer.

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.


Setting aside scalability for an issue, how would they solve this problem in the first place?


Along those lines, it sounds like Sandstorm may be a fit for what you're thinking of. It's generally more federated than a totally distributed system, but provides nice mechanics for packaging web apps, distributing them to others, moving from one server to another, sandboxing them, etc. It makes setting up and running web apps as easy and safe as downloading an app from an app store.


Last I checked the development in last few months has greatly died down (after they lost funding). It seems to rely on Kenton for all dev work.


The rate of change for features for the open source sort has not changed drastically, as a lot of effort was being expended on business development and profitability before the funding dried up.


The pendulum is definitely ready to swing back the other way. A related problem with SaaS is the risk associated with whether or not the company will endure (and open-source-on-company-failure is not confidence building imo).

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.


> With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies

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.


"You can still create a Digital Ocean droplet, Docker container, or VM Image - and do the same thing (upload & forget)."

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 ?


Can you clarify what you are driving at with these questions? First off, a lot of people prefer hosted source repositories other than github (e.g. hub.darcs.net, gitlab.com, My Own Private Server). Github naturally imposes various limitations on their "free" plans.


I'm not getting at anything. I'm genuinely curious.

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 ?


At the risk of prolonging a pointless line of discussion: what does github have to do with anything in this context?



Using Cloudron since a week now to host Rocket.chat for similar reasons mentioned in the article. Can totally recommend it!


Why did you choose Rocket.Chat and not Mattermost?


What if we had an easy-to-use home server you could just plug in and start running "apps" on? Being able to download and run services on hardware you control would avoid some of these problems.


The base Synology NAS models fit the bill - everything from blogs to office software is available from the get go. I own one but don't use them and haven't met anyone who does - there is something about hosting this on a box in your living room that feels too fragile.


QNAP NAS models have a similar setup. In addition to their own package format (qpg? I think...), they also are getting the ability to run Docker apps natively.

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.


> The base Synology NAS models fit the bill - everything from blogs to office software is available from the get go.

Their package system (for 3rd parties) seems to still be a mess: https://github.com/SynoCommunity/spksrc/issues/2216


To be fair packaging is a bit of a mess everywhere. We're talking about installing and running things, not publishing them, I can say I was positively surprised by how well everything works in their system.


There's a start-up called Daplie building such a system of hardware and apps. It's open source and the founder has a focus on user-owned data and data security.

(I know several teammembers and preordered via Indigogo, but am otherwise unaffiliated.)


In the long run, I think that's the right location for things like IoT devices: there's no reason for my thermostat to dial back to the cloud when it can just connect to my central computing unit in the closet, exactly like it connects to the central heating and air conditioning units in the closet. Normal people don't mess with HVAC, but they can if they want to (and it's remarkably simple!); likewise I don't imagine normal people would mess with their home system, but they'd be able to if they wished.


> 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.

This is exactly where I am with https://landscape.io - can't keep it running for free, can't get people to pay.


Is that a typo? It looks like it should be "landscape.io", and in the way it's currently written, it gives me a 404


Oops- it was, thank you. Edited and fixed now!


Maybe try to decrease the price and open up to wider public? Pricing is high for small developer.


I don't know anything about your market, but your plans seem awfully expensive and they're differentiated weirdly. I wouldn't choose to pay for a tool that would limit how much trend data I get based on how much I paid.


Could take the "Heroku" out of the Heroku button if there were a really easy way to deploy/connect Docker containers.


I actually think that it's a social and business problem, more than a technical one.

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.


OpenShift might be a potential alternative to Heroku, especially comparing the free plans.

https://www.openshift.com/ https://blog.openshift.com/updated-openshift-deploy-buttons/


The way this problem will get solved is some service running on top of aws which will allow users to install and run any app, packaged in a standardized format. This will be free in exchange for a column beside the app which serves ads or some small amount of money to get rid of the ads.


I agree it seems like a dark ages, but it was inevitable software would move to a rent seeking position in this environment.

VC's want their income tap. These yachts don't run themselves!


Potential solutions: Urbit, Maidsafe


A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision.

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.

[1]:https://matrix.org

[2]:https://riot.im

[3]:https://matrix.org/docs/projects/try-matrix-now.html


"in the spirit of IRC" is a bit of a stretch. This is all a massive blob of web technologies which contrasts IRC's minimalism and it's lightweight clients written in C. It doesn't appear to require any specific service though so at least it has that.


"Web technologies" makes it sound like it requires WebRTC or something. It's a set of HTTPS endpoints that you shove JSON-encoded messages at. Certainly a bit "fluffier" than IRC (no prefix-length binary protocols here, sadly), but much more interoperable in the modern world (i.e. you can write a browser extension that can speak directly to a Matrix server using the built-in JSON+AJAX APIs; Matrix servers won't need specific egress exceptions in enterprise firewalls; etc.)

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.


I'm not sure it's fair to call it a massive blob of web technologies (although I'm biased, given I work on it). To compare sending a message on IRC versus sending one on Matrix:

  $ telnet irc.freenode.net 6667
  ...
  NICK Ara4n
  USER Ara4n Ara4n irc.freenode.net :Matthew Hodgson
  ...
  JOIN #matrix
  PRIVMSG #matrix :test
versus:

  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"}'
(okay, this assume you've grabbed a valid access_token from an existing session, and already know that #matrix:matrix.org's internal ID is !cURbafjkfsMDVwdRDQ:matrix.org, but that's easy to find by curling https://matrix.org/_matrix/client/r0/directory/room/%23matri...).

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/...).


Call me crazy, but I think your example illustrates one reason why IRC is great: I can read it. And I could probably get it right even typing it from memory.


The IRC protocol is surprisingly difficult to implement correctly. I'm not an expert on the issues involved, but a few of the high points include:

* 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.


Agree about DCC but lot of the other issues you list are due to curmudgeonly (IMHO) users insisting on using non-modern clients and networks.

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.


At the same time, that existing base of legacy IRC clients and servers is the only reason it could be worth hanging on to the old protocol. If we're going to break backward compatibility, we might as well take the opportunity to fix all of the other long-standing issues with the protocol.


I still have hope for the IRCv3 project, it appears to be fixing a lot of the issues mentioned. I'm on Matrix, but until #debian moves, I'll be found on Freenode and OFTC.


That was true a few years ago, but is long invalid, due to many recent changes. Nowadays it looks like this:

> * 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 ;)


> * 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.

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.


Responding to a couple points:

> 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
the server will proceed to send everyone else in that channel something along the lines of:

    :your@hostmask PRIVMSG #channel :some long message
which will be limited to 510 characters (512 minus CRLF). Unless you're perfectly aware of how the server will render your hostmask, there's no way to know where the limit will end up.

(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.)


Re: message length, this does still sound like a limit on the implementation, and you could easily make IRC servers that have either longer messages (ircv3 has 1024) or no limit at all (although perhaps that's not a great idea)

> 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)


Agreed that the IRC line protocol is superficially easier on the eyes, but it's far from intuitive (especially the weird USER command). Whereas remembering the URL shape for Matrix is... just another URL (plus you can always cheat and just 'copy as curl' from a browser's network inspector). But each to their own :D


Why would you do such a thing, though? Other than bragging rights (much like I did SMTP over telnet in my school days), there's not much of a reason.


(that said, I think the point of Dave Cheney's article is more that sync realtime chat is bad for FOSS collaboration relative to mailing lists and forums. So until Matrix finally lands threading & forum semantics and smtp/nntp bridges, I suspect it's part of the problem he's complaining about :D)


Threading I know is being worked on, but is SMTP/NNTP anything other than a jape?


SMTP/IMAP is very serious - we would love to bridge email convos into Matrix eventually. I suspect we're a little late to rescue NNTP though but perhaps someone will write a bridge for sentimental reasons :)


You lost me at: "cURbafjkfsMDVwdRDQ"


Well we are moving to a web first world, and passing the terminal days of IRC. Trying to avoid web technologies isn't going to do anyone good. Best we can do is try to make them better are secure. Light weight clients can be written in C if you want. There's nothing that needs a web browser

Here's the spec if you're interested[1].

There's also a weechat script if you want a command line client[2]

[1]: https://matrix.org/docs/spec/

[2]: https://matrix.org/docs/projects/client/weechat.html


> Well we are moving to a web first world,

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.


Yeh in this vain, I'll add that I have very experienced colleagues who are so fed up with the current internet that they don't even fight net neutrality, and would rather another protocol rise in its place.


There's nothing inherently 'web' or 'slow' or 'ajaxy' about Gzipped-JSON-over-HTTP2.

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.


And yet it requires a hilariously complex protocol engine for HTTP for no purpose whatsoever.


I don't agree at all. HTTP/1.1 and HTTP/2 are not especially simple protocols, but they're not that complicated. They aren't unnecessarily complicated, that's for sure. They have a set of features that necessitates a level of complexity, but it's better to do it in HTTP/2 once and only once than to repeat the same failures and reworks and added features and upgrades etc. etc. etc. to get the same level of features in a million different application protocols.

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 aren't unnecessarily complicated

They are, for what matrix intends to do.


Programming sucked before HTTP+JSON became the lingua franca of machine communication. Being able to use any programming language with modern HTTP-based protocols is a real luxury.

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!


> Being able to use any programming language with modern HTTP-based protocols is a real luxury.

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.)


I've just finished my first project using websockets. Coming from the embedded world and bare UARTs plus a little bit of C sockets, I found it hilarious that we've got so many layers to essentially do the same thing that I could do on an 8-bit microcontroller.

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)


> The critical difference? Speed of development. Websockets was so blindingly quick to get working.

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".


> Now, is that websockets or is that "not C"? > 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...)


It's not exactly super hard and complicated to get things working on a microcontroller though. In fact, the first time I did it, I felt it was so much simpler than all this complicated web stuff.


It absolutely is! I love micro-controller development. It's you and the bare metal, not dozens of layers of abstraction that often feel like they're fighting you at every turn.

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...


I spent months implementing an undocumented, custom, binary protocol to speak with an IRC bouncer.

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.


For the record, there are no bad feelings on the Matrix side towards IRCv3 at all. The protocols are very different, and the design & architecture decisions in IRCv3 look fundamentally different to Matrix. In the end, Matrix is trying to be an openly federated object database with pubsub semantics - a standards-based decentralised encrypted Firebase, if you will. I really don't think that collides with IRCv3's aspirations, and we're looking forward to updating https://github.com/matrix-org/matrix-appservice-irc with IRCv3 features as they land. We're also looking forward to IRCv3 stuff to add to https://github.com/matrix-org/matrix-ircd, which is a Rust server which exposes an IRC listener for the entirety of Matrix. The open communications space has enough threat from silos like Slack and WhatsApp without in-fighting, and I'd hope the communities can get along and support each other rather than the opposite.

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 :)


Recently I had a user ask for better support for large channels, in the IRC client I contribute to sometimes.

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.


"Well we are moving to a web first world, and passing the terminal days of IRC."

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.


I see advertising for Matrix every single time the chat topic comes up. Having looked at the protocol, it seems massively more inefficient than just using XMPP, which has numerous clients and a lot of features. Can Matrix do anything that XMPP can not?

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.


For the record, the only person on this thread (afaik) actually affiliated with Matrix is me, and we categorically don't advertise but jump on discussions like this one to try to answer queries and dispel confusion & FUD.

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.


Matrix is an extremely heavy protocol, not suitable for business use imo.

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.


Given Matrix & Riot are entirely FOSS, please do spell out its obnoxiousnesses (rant here, or file on http://github.com/vector-im/riot-web/issues) so we and the wider community can go fix it. Agreed that Riot is too heavy; we're currently doing a performance blitz on it. In terms of Matrix itself being too heavy... we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works well enough that nobody has bothered.

Empirically many people seem to use it fine for business and for IRC-style purposes though :)


The startup times are most notable for me. As an example, here are a few lines from the node example app in the matrix-js-sdk repo:

  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)  ---
This seems like a pretty barebones Matrix client, and it's taken 41 seconds to get to the point where it can display the rooms I'm in on a 2012 MacBook Pro with an i7 processor. (Also notably, Activity Monitor reports that this node process is using 318 MB of memory.)

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. :)


So, this was a design flaw in how matrix-js-sdk was originally implemented - it simply didn't cache any state whatsoever locally, so every new launch meant re-syncing the whole world to the client. This can obviously be improved by lazyloading, but for now we've fixed it by caching full offline state in indexeddb - https://github.com/matrix-org/matrix-js-sdk/pull/363 & friends. This speeds up launch time to a few seconds, if that - and as we go through doing more lazyloading it'll be even better. We also need to make the app progressively loaded in general rather than a big ball of webpack.

Coincidentally, the new version of Riot which uses the new indexeddb backend should be going live tomorrow (live today on riot.im/staging).


So, how can I launch a matrix client that has never been used before and chat, with only a dialup connection, in less than 4 seconds?

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.


So, worst case this is 4 hits; one to /login (if you don't already have an access token), one to /directory to resolve the room alias to a room ID (if you don't already know the mapping), one to /send to send a message, and one to /sync (filtered to the room you care about, if you're mimicking IRC). In practice, this looks like:

  $ 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
...which signs you in, locates #riotdemo:matrix.org (which has 23 users), syncs 20 messages of scrollback from it, and sends a message, simulating a 64kbps link via curl's --limit-rate, and under your target of 4 seconds.

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.


This works with a 20 user room.

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.


yup, agreed that we need better lazy sync for initial syncs to a room with thousands of users. this thread seems to have triggered a lot of interest in writing alt transports for matrix though; will be interesting to see what happens!


At no point did I imply it's garbage because it's FOSS.

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.


At no point did I suggest you thought it was garbage because it's FOSS - I was just pointing out that because it's FOSS we're dependent on the wider community to contribute constructive feedback (and ideally code) to improve it.

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" :)


Go re-design your program on a Pentium-II with 128MB of RAM and you'll understand every single complaint anyone could've had - including the sheer bloat of your project.


I get where you're coming from here, but in the days where you can get a Linux computer for $US35 that has a 1.2Ghz quad core and a gig of RAM, it doesn't make much sense to go through the contortions necessary to develop for a toaster. The cost/benefit just isn't there.


> we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works well enough that nobody has bothered.

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.


What do you have in mind? There is nothing particularly specific to HTTP about Matrix at all - it just needs some kind of request/response mechanism, and a way to stream events back and forth. For instance https://github.com/matrix-org/matrix-doc/blob/master/drafts/... is the proposal for Matrix over websockets (which streams server->client events over a websocket in a manner which has nothing to do with HTTP). But nobody's bothered to implement it, because nobody seems to feel HTTP+JSON is particularly broken in practice. Similarly switching HTTP for COAP would be trivial, but nobody's bothered afaik.


> What do you have in mind?

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?


Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;)

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".


> Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;)

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.)


From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API - e.g. what arguments do you pass when you paginate? what data do you get when you sync? how do you tell it where to sync from? etc. I genuinely don't care whether you do RPC via an HTTP PUT, a COAP PUT, an MQTT Publish, or some funky custom RPC of your own devising - or whether you encode the data as JSON, CBOR, BSON, protobufs or whatever. To say that switching transport from HTTP to Websockets is "necessarily redefining quite a bit of the protocol" entirely misses the point. It's just a transport! We want people to propose alternative transports!

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.


> From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API

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


The encoding-agnostic schema for Matrix events is defined at https://github.com/matrix-org/matrix-doc/tree/master/event-s.... We haven't yet written up a transport-agnostic description of the client-server API, mainly because the spec is WIP and we haven't got to it yet, and because in practice it's trivial to procedurally convert the HTTP endpoints into whatever RPC mechanism you prefer. PUTing some JSON to a HTTP URI trivially maps to a JSON-over-TCP RPC mechanism or whatever it is you're pushing for.

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...


> The encoding-agnostic schema for Matrix events is defined at [...]

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.


> What exactly would people facepalming and walking off feel like, that this doesn't feel like it?

Funny how the silent majority is alway on 'my side'. No-one ever claims that the silent majority is against them.


Where did you pull that supposed majority from?


Well. I'm interested to see what you think is a suitable protocol for business.

I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things.

So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.

I'm not very familiar with all of the chat protocols, but I'm familiar with the possibilities of communication today. It's riddled with proprietary protocols and chromium based applications. And that's why I see Matrix as the next step.


> The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more 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.


>I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things.

Let's take those each at a time, shall we?

>Emojis

This has nothing to do with the protocol. If you can send arbitrary UTF-8 messages (which you should be able to do, obviously, and can with modern IRC clients) then you can send emojis to your heart's content.

>Search

I've never personally found search particularly useful, but there's nothing about IRC that makes it any harder or easier to search messages. The way all chat search works and will always work is that you log chat messages somewhere and provide a way to search them. That has nothing to do with the protocol and everything to do with the server logging messages.

You can then extend your chat protocol with a command that you send to the server that asks it to search the current channel (or all channels, or all channels I'm in, or all channels I've been in, or all messages sent in all channels that I was in at the time, that's up to the server though - corporate probably want the former, public you'd want the last one) for a particular string/regexp/whatever.

There's nothing particularly complex here from the perspective of the chat protocol and in fact it would be simple to extend the IRC protocol with a command for doing this at the protocol level. It's just much easier to write bots to log messages and web interfaces to search those logs with.

>Session persistence

No, nobody wants this. What people want are to see messages sent while they weren't there and to be able to receive messages while away. The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.

>Web client

There are lots of IRC web clients, and all you need for this is a simple protocol.

>So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.

IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.


>>Session persistence

> 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.


>Are you serious? I think lots of people do. I think it's one of the draws of Slack.

No it isn't. What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc.

>Is that what Slack does? Whatever they do, I think it's what people want. Indeed it is not an experience offered by IRC, perhaps because "most IRC servers don't want" to, sure.

Slack has a much higher barrier to entry than IRC and most people using it are private companies.

IRC servers are publicly accessible and publicly accessed. They have existed for much longer. If Freenode stored every message ever sent on Freenode that would be a nightmare.


> Slack has a much higher barrier to entry than IRC and most people using it are private companies.

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...


Also, 'only if you're a nerd' is very silly. We're talking about this in the context of open source software. Everyone that is capable of non-trivially contributing to open source software is more than capable of operating an IRC client.

In fact, if you can't work out IRC then you're almost certainly too silly to be a programmer.


Yup, I completely forgot the context while I was writing my comment. You're right there.

I was more thinking about it from the context where Slack provides so many more features over IRC, not just real-time chat.


>Only if you're a nerd. Took me 5 minutes to get started with Slack for our company and managing it is a piece of cake.

Slack requires you to make an account on their website, a new account for every Slack group. IRC you can just join - pick a nickname and type the server's address and you're in.

IRC is completely trivially easy to use, Slack is not.


Setting up an e-mail address and a password is not an incredibly complex task. I have 3 seperate slack groups that are set up just for friends to chat.

Besides which, on most IRC servers, you're going to be using NickServ anyway, which is more complex a flow than setting up a user on Slack.


> What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc.

Okay, to me that is the same thing as 'persistent sessions', but without belaboring the point... can IRC do those things? Right, it depends on the server and client. What servers and clients can? I think it's pretty rare, if it exists.

If your answer is "well, IRC _could_ do that, if only more reosurces were invested in it to make it so", okay, but so what?


You're missing the point. This subthread is not about what IRC does do, it's about whether a chat protocol with support for persistent sessions, search, etc. can still be simple.

Maybe actually read the thread next time? So don't "so what?" me. This isn't about whether IRC can do those things.


Okay, good luck convincing people not to use slack because some hypothetical thing that doesn't exist could have the features they want, while being simpler than Slack and open source. That's your point?


>>Emojis

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&...


>Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2].

What a load of crap. Emojis are simply sequences of Unicode code points. IRC supports UTF-8. A client with a button that brings up a big list of emoji is trivial to build.

>You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features.

That's irrelevant. You claimed that the simplicity of the IRC protocol was something unobtainable with those features. That's what I am disputing.

>Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features.

It's precisely about whether it's possible. You claimed that simple protocols for chat were not compatible with the features you listed.

>IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about.

I agree that IRC was never intended to be run in a browser and doesn't run in a browser well. But that is irrelevant.

>Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about.

Nobody is fucking boasting about anything. The point is that all of what you mention is easily possible with a simple protocol. "We should all use slack because simple standardised protocols can't do X, Y and Z" is FUD.

IRC has really complicated features like file transfer. So I don't think that IRC is being held back by an inability to implement things that require a complex protocol anyway. But even if it were, what you mention does not require one.

>One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to?

What are you talking about? I haven't said anything of the sort.

>Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.

Very, very few OSS projects have moved to slack. The vast, vast majority use mailing lists, forums, IRC if they use anything other than GitHub. Most people just use GitHub issues and email, not even mailing lists but plain email.

>I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.

The vast majority of this thread, as I see it, is the opposite: bashing IRC, a protocol that has been successful for a long time, is open, is inherently distributed and which there are many clients on many platforms for, while going 'look at how awesome [thing nobody uses] is!!'

Also the majority of IRC users aren't using freenode and the use of IRC by OSS is a tiny portion of the total use of IRC.


> trivial to build

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


Slack is a widely used product, but its use is tiny compared to IRC. IRC isn't just tech people, it's very widely used by a really huge, diverse range of people.

Your original comment said 'the days of simplistic IRC protocols are gone' and then you gave a bunch of features with the implication that simple protocols can't handle those features.

I simply explained why those features are absolutely implementable over simple protocols, and also why IRC isn't actually a simple protocol - DCC is an example of something not at all simple in IRC.

I didn't say that IRC itself, in its current incarnation, solves those problems.

Ultimately you're basically saying 'I want a couple of features and because slack provides them, I'm going to justify my use of slack by comparing slack to the least featureful chat thing out there: IRC'. IRC's strengths aren't its features, it's its openness, familiarity, hackability, conceptual simplicity and community control. In fact, the things people that like IRC dislike most about it are the few parts that aren't open, hackable, simple or controlled by the community.

I don't particularly like IRC as a protocol. Maybe its time has come, maybe the replacement will be called 'IRCv3' or 'IRCv4' or called something else. Whether that replacement is called 'IRC' is not important. What is important is that it remains open (in spirit and in practice), hackable, simple and controlled by the community. Slack replaces a distributed, network-failure-proof system (IRC) with a centralised, corporate-controlled, paid, closed, proprietary solution. That's the worst possible collection of properties. Yeah you can search messages, yes it has a nice user interface, but that's about it.

>The point was it isn't built, where as there's auto completion support for emojis which wouldn't even need that "trivial" software. That's in the matrix's sdk. If it's so trivial, please, build for the IRC community. I use hexchat on my desktop and weechat on the server. Would you mind building me one if it is trivial?

I can't tell if this is a joke. This is literally:

1. map names to emojis 2. autocompleting input field on those names 3. append a couple of bytes to a string

This is 100% purely a user interface feature, it has nothing at all to do with the server or the protocol. You could implement this for literally any chat client that supported UTF-8 quite easily.

https://blog.irccloud.com/emoji/


> it's very widely used by a really huge, diverse range of people.

Well you must be around cooler people than I am. Today, if someone wants to start a group chat with persistence (I'm surprised you seem to think this is useless), without having to bother with setting up their own server, IRC will not be on that list. But there is a large group that wants this, and its increasing, because people don't want to bother with a bouncer.

> Your original comment said 'the days of simplistic IRC protocols are gone' and then you gave a bunch of features with the implication that simple protocols can't handle those features.

This is a bit similar to FORTRAN's situation. FORTRAN can still do the things C++ can still do, but you don't see people using FORTRAN. IRC is a simple protocol and is simple, until it has it be used for increasingly complex features and also being adopted for the web requires all sorts of proxies and workarounds.

> I didn't say that IRC itself, in its current incarnation, solves those problems.

What are you saying then? You said people can use IRC now for all the features I talked about, but then now you changed your stance.

Then what solves those problems? I think Matrix solves those problems, so what do you think is a better alternative? Does it have a community comparable to matrix? Say so and I will switch right now. The guys working being matrix know what they're doing. HTTP transport isn't the fastest, but it is simple to implement for a web developer. And with more and more people preferring in-browser clients, I saw HTTP as a good choice.

> Ultimately you're basically saying 'I want a couple of features and because slack provides them, I'm going to justify my use of slack by comparing slack to the least featureful chat thing out there: IRC'. IRC's strengths aren't its features, it's its openness, familiarity, hackability, conceptual simplicity and community control. In fact, the things people that like IRC dislike most about it are the few parts that aren't open, hackable, simple or controlled by the community.

Are you aware of what my first comment you replied to was about? I was replying to someone talking about how Matrix is a 'bad protocol for business', further saying:

>I don't think you're very familiar with chat protocols if you think it's even remotely suitable as a replacement for IRC.

I never recommended slack. Completely against that actually, and I'm rooting for matrix.

> I don't particularly like IRC as a protocol. Maybe its time has come, maybe the replacement will be called 'IRCv3' or 'IRCv4' or called something else. Whether that replacement is called 'IRC' is not important. What is important is that it remains open (in spirit and in practice), hackable, simple and controlled by the community. Slack replaces a distributed, network-failure-proof system (IRC) with a centralised, corporate-controlled, paid, closed, proprietary solution. That's the worst possible collection of properties. Yeah you can search messages, yes it has a nice user interface, but that's about it.

Holy cow. I've been linking to matrix and Riot links, how did you still think I'm talking about slack? I was talking about how slack is getting the mindshare of OSS communities and that's not good.

>I can't tell if this is a joke.

No I assure you it's not. You linked to a single web client. That's not the same support for emoji's as matrix's.Those are emocodes, and on the big list of supporting clients here[1], I see only IRCCloud (which is the same web client you linked me to) implementing it. No other IRC clients does this.

> This is 100% purely a user interface feature

That's why I listed the clients I use - Hexchat and weechat. Please share the easy code that can add those features to them. While you're at it, licensing it with a FSF approved license would be much appreciated.

[1]: https://www.webpagefx.com/tools/emoji-cheat-sheet/


>Well you must be around cooler people than I am. Today, if someone wants to start a group chat with persistence (I'm surprised you seem to think this is useless), without having to bother with setting up their own server, IRC will not be on that list. But there is a large group that wants this, and its increasing, because people don't want to bother with a bouncer.

I don't care what you use personally. The reality is that many hundreds of thousands of people use IRC frequently. Communities all over the world use IRC. Most of them are non-technical. Most have never heard of Matrix, or Riot, and certainly have no interest in using Slack.

>This is a bit similar to FORTRAN's situation. FORTRAN can still do the things C++ can still do, but you don't see people using FORTRAN. IRC is a simple protocol and is simple, until it has it be used for increasingly complex features and also being adopted for the web requires all sorts of proxies and workarounds.

No, it's nothing at all like Fortran. That's a silly comparison.

>What are you saying then? You said people can use IRC now for all the features I talked about, but then now you changed your stance.

No I didn't. I never said that IRC could do all those things today. Are you even reading my comments?

>Then what solves those problems? I think Matrix solves those problems, so what do you think is a better alternative? Does it have a community comparable to matrix? Say so and I will switch right now. The guys working being matrix know what they're doing. HTTP transport isn't the fastest, but it is simple to implement for a web developer. And with more and more people preferring in-browser clients, I saw HTTP as a good choice.

Again, you're missing my point by a country mile. If you had said "IRC doesn't currently support this" I would agree with you. But you didn't. You said that simple protocols could never support these features. You said that the days of simple chat protocols are over. And quite frankly, that's rubbish. That's all I am saying, all I have ever said. Stop pretending that I'm saying IRC has all the features you are asking for. I am saying that you can implement those features in a simple way on top of a simple protocol. That is all.

>Holy cow. I've been linking to matrix and Riot links, how did you still think I'm talking about slack? I was talking about how slack is getting the mindshare of OSS communities and that's not good.

No you've just asked me repeatedly and for no good reason to show you how IRC does all the things that I've repeatedly said it does not do. I don't know why you're incapable of understanding the difference between "IRC has features X, Y and Z" and "it is possible to implement features X, Y and Z on top of simple protocols, so no the days of simple protocols are not over". But you do seem to be incapable of understanding that, as it's about the fifth time I've said it.

>No I assure you it's not. You linked to a single web client. That's not the same support for emoji's as matrix's.Those are emocodes, and on the big list of supporting clients here[1], I see only IRCCloud (which is the same web client you linked me to) implementing it. No other IRC clients does this.

You can use shorthand emocodes (with autocomplete!) to send them and they’ll be converted to unicode so anyone using another IRC client that supports emoji can enjoy your graphical exuberances.

You could at least read the link. You type them as emocodes, which are mapped to the actual Unicode emoji. All that is sent over the wire is normal Unicode emoji. That is why I'm saying that this is a purely UI issue.

This is what emoji are. They are Unicode grapheme clusters formed from a group of Unicode code points. That's the implementation, and the interface is, on both Slack and IRCcloud and everywhere else I've seen them, either a giant grid of emoji to pick from, or emocodes :simple_smile:, usually both.

>That's why I listed the clients I use - Hexchat and weechat. Please share the easy code that can add those features to them. While you're at it, licensing it with a FSF approved license would be much appreciated.

Why on God's earth would I do that?


>Riot is really obnoxious to use and get set up, and is also extremely resource hungry.

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).


You have completely misunderstood the post.


I do realize that the post talked about how real time communication must be avoided. But there are still projects that prefer real time communication and use slack for that. Matrix is a good alternative, and I pointed that out.

This is in no way a disagreement with the author.


Why is there not a web based IRC app?



IRC is a TCP-based protocol and browsers don't support TCP connections.

There are web-based applications that communicate with IRC but they require a proxy running on a server.


There is!

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)


I use. https://github.com/thelounge/lounge (npm install -g thelounge)

I used to use: https://www.irccloud.com/ (Paid, SaaS)


Lounge is very good


Rocket Chat is a great (open source) slack alternative: https://rocket.chat/


Another great alternative to Slack in the spirit of IRC is "Internet Relay Chat".


> A great alternative to Slack, in the spirit of IRC, is matrix[1]

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.


You might consider doing a simple Google search instead of presenting a possible conclusion based on a guess. In any case, Riot is great and works on both Android and iOS.


Yes, they have amazing (and multiple) clients for both Android and iOS. Especially Riot, which is not just a cheap web wrapper that a lot if the alternatives, it's native and in my experience, I have not had any problems, performance inckuded, using it for slack on my Android phone.


Err..Pretty sure it is a web wrapper? Just checked out their GitHub and didn't even see a desktop app.


I think the point is that the ios and android apps are pure native; no react native or HTML. riot-desktop is indeed just an electron wrapper of riot-web (although it works quite well); but then there are native desktop matrix clients like Quaternion and NaChat for those who want them :)


It does! Check out Riot.im


What drives me nuts is that there are so many of these things.

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.


>It is one thing to deal with one of these things, but when you have to install ten to get

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.


> 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? =)


If it's anything like my experience, the trip from clicking on the button to open the app and wait for the myriad of redirects, before clicking through to the page you actually want to monitor is non-trivial (and sometimes doesn't occur if the tab isn't in the foreground).

I don't have that many open, and it still takes me around 5 minutes every day to open them back up.


At least you have SSO! Imagine what if you had different credentials to each of these services (even logins)! There are big companies that operate like that...


Having different credentials would actually be faster. One key chord to ask 1Password to fill in my password and log in, and I'd be done. Instead, with SSO, every time I need to log in, I need to type in my email address, go through a bazillion redirects to Google where it asks me which of my accounts I want to use (even though I already typed in my email, and even though I only ever use one of those accounts for SSO), click it, often have to then enter my Google password and/or OTP code, then go through a bazillion more redirects back to the app.


There are also lots big companies that have "SSO" but it is half-baked or incomplete with regards to which services and you end up with MSSO - multiple single sign on.


Install 1Password and it's basically like having SSO.


And why shouldn't he have different credentials? A password manager would make this a cakewalk.


I don't even bother logging out, ever. I just have them open in different tabs.

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.


I turned all of my notifications off and use Pomodoro timers.

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.


This is exactly what I do! I find it very simple and effective. I set mine for 60 minutes. It really helps focus. 60 minutes is about as long as I can focus without a break anyway.


As a freelancer, I have EXACTLY this problem, so I started hacking away on my own solution. Don't want to shamelessly promote myself here, but if you're interested, link is in my profile.


A few comments that I hope are constructive. Looking at your page, I'm not confident you're avoiding the issue by which these tools proliferate:

https://xkcd.com/927/

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.


Great comments, I'll try to address them:

- 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.)


Aka Trillian from the last Great Messenger Client War.


Well, perhaps but I am more trying to develop a service to avoid the Slacks and Basecamps of the world, while still being aware of what's going on, rather than just being a multi-network client.


>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.

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


If you publicly advertise your service I can probably assume your consent to speak to it. I don't have to wear a funny hat while doing so just because some hidden legalese on your website says so.

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.


>If you publicly advertise your service I can probably assume your consent to speak to it.

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.


Don't forget this problem: https://xkcd.com/1810/


One goal of matrix is to use federation to synchronize with other chat protocols, so you don't have to convince your friends or associates to use it.



As an aside out of curiosity, is the client/freelancer graphic representative? Are you really in the Kimberleys with a client in Western Sahara? Just struck me as odd as there are few places on earth that are less-densely populated (while still being populated) :)

I don't have a need for the product myself, but I do like the name for it.


> 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.

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?


That sounds abysmal. Slack is the only thing on that list I keep open., and I've gotten a pretty good set of notification settings configured.


I want to add, I keep system monitor up 100% of the time.

My favorite application is Microsoft Outlook, which consistently takes up ~50% of my CPU on my 2015 maxed out Mac.


In the good old days of ICQ and Jabber you could install a client that would integrate several protocols into a single lightweight UI (e.g. Miranda IM). Unfortunately the new wave of messengers is much more successful at guarding their protocols against such integrations.

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.


Franz is pretty alright for this. http://meetfranz.com/


There is also http://rambox.pro/ which is open source


There's also a FOSS alternative to Franz: http://rambox.pro


If I can't use my own client (pidgin/finch), then I'm just not going to use the chat-service. I don't mind being logged into $chat_client_of_the_week, I mind logging into all of the $chat_clients_of_last_week though.


I like using IRC, that's the best for communicating with people about oss stuff. The client takes virtually no processing power too.


I feel the same way. Standardization is a feature, but it also comes with its costs (difficulty of extending features). In many places lack of standardization is okay, but I feel like for most chat purposes (especially about programming), plain text over IRC works just fine.

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.


What if software engineering as a skillset hit its peak within the last 5 years and now it is just going downhill in general? The quality of "companies" isn't going down - companies are made of people, and some of those people are in charge of creating and testing its technology...


I just use Franz:

http://meetfranz.com/


Two questions spring to mind that are not immediately obvious from the website - how do they get access to your messages in different accounts?

Are they using some API? Or do they ask you for your username/password for each service and "helpfully" login for you?


It appears to be just a wrapper around web interfaces. Electron or some such nonsense. Truckloads of megabytes - binary size as well as memory consumption.


They pretty much wrap the website versions of the services.


Or better yet, Rambox ;)

http://rambox.pro/


Definitely checking that one out, thank you.



Franz isn't a new standard, by the look of the homepage.

Seems to be wrapping them all.


I think one of the strengths of matrix (in addition to federation) is first-class bridging. I already communicate to several IRC networks, gitter and slack via matrix. I only have to use one matrix client and it enables me to communicate with people on several different networks/services. No monstrous electron apps that load the web UIs of several services in different tabs. The server-side in matrix handles the bridging and I can use any matrix client I like.


Also Hipchat


Is that really happening that open source communities use Slack as their primary communications channel? I haven't seen that happening in the communities I participate in (Python/Django/...). What I do see is that more and more communities switch from IRC to Slack as the primary "sync" channel (while still maintaining mailing lists, bug trackers and the like).

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?


On one large free software project, we adopted Mattermost (an open source / self-hosted equivalent of Slack). We went from ~12 active users and ~50 lesser active users, to ~ 100 active and ~ 500 lesser active users. I agree that more folks should consider moving away from IRC.

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.


Thanks for the mention on Mattermost!

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


We migrated from IRC to Mattermost and haven't looked back. It integrates so well with our Gitlab/Jenkins flow, too. It's been great.

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).


Fantastic! Thanks for the mention! Yeah, scripting integrations with curl is super useful.

For others, here's another article of replacing IRC with Mattermost in education: https://opensource.com/education/16/3/mattermost-open-source...


Why do you want a chat client to integrate with gitlab or jenkins?


Oftentimes the 'sync' conversations are either triggered or resolved by commit/build events.


Do you mind expanding on this and showing a full flow? That sounds a little wonky to me but I could be missing something.


Our flow is like this:

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.


How do you like mattermost compared to rocket.chat? My group switched from flowdock to rocket.chat to save money and we've definitely seen a dip in participation. Rocket.chat's mobile app constantly seems to have issues with remembering what server you were logged into between updates and the desktop version doesn't recognize when you're caught up with a channels messages leaving it marked unread unless you go out of your way to manually tell it. Plus I really miss threads...


I was at a dev meetup for Python: I really thought he was joking when he said, what is IRC? And then I realized that we have a whole generation of devs that have no idea what IRC is or how to use it. Amazing the amount of knowledge and experience lost between a single generation.


I've tried to give IRC a chance a few times, but it always felt like there were a few too many odd little things to learn before I could be productive and comfortable. I didn't get used to it and dropped it. It never felt inviting.

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.


I've been IRCing for 24 years. I know about bouncers, different clients, etc., and I still prefer Slack to IRC.

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.


I used IRC a lot as a teen back in the late 80s early-to-mid 90s. This was back when to make a private channel you would have to join a channel that was a negative number and hope nobody else wandered in on a guess (which was unlikely to happen since the number of users was literally under 200 at peak times). Pre-Eris, Pre-EFNet, etc.

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 used IRC a bit in the mid 90s when I first encountered this whole internet thingy. Even though I was young and dumb, it struck me as a bit lame: nerd bullshit with fiddly setup. The async aspects of usenet and email struck me as more scalable, and the web had, you know... graphics.

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.)


I think these are all key points. The user experience in Slack is so easy, convenient and polished. It takes friction away from communication, allowing effort to be focused on the tasks at hand.


I probably wouldnt hire a developer that didn't use IRC


Because in the skillset of developers, IRC is such a difficult one to acquire?


Grep isn't a difficult skill to acquire but I wouldn't hire someone that didn't know it. Some skills can be good proxies for a range of other skills an experience and a lot of developers are in that "don't know what they don't know" range.


Sure, I just have to disagree on IRC being a good indicator for that.

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 don't even know how to shoe a horse.


"And then I realized that we have a whole generation of devs that have no idea what IRC is or how to use it."

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.


I don't think it's necessarily a generational thing. I know people in their 30s who don't know what IRC is (or who at least haven't used it), and I know people in their 20s who DO use it (or at least know what it is). And it's not as though the knowledge is lost; IRC still exists and there exists plenty of information about it. It's just not carried around in people's heads as much. None of this is good or bad; it just is.


I don't think it's a generational thing either. I know how to use IRC and how to connect with it. The problem is the difference in the amount of energy demanded by the set-up process. Connecting to Slack is extremely simple and I don't have to fiddle with the settings in order to get a decent experience.

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.
  - ...
It's an epic yak shave that sucks massive amounts of time and energy a from the thing I joined the community to do: improve a piece of software that isn't IRC.


Same thing has happened in gaming with the introduction of Discord. No one wants to bother with mumble, team speak, or vent.

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.


The benefit, though, is once you are set up with IRC, joining new channels is a breeze, especially since most open source software uses a single network (Freenode). All I have to do is type something like

  /join #rust-lang
and I'm in the new channel. Compare this with Slack, where, no matter how many teams you've joined in the past, you have to go through the exact same rigamarole to join a new Slack team.


Discord avoids that issue by having a global identifier, similar to your connection to an IRC network.

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.


> I know how to use IRC and how to connect with it.

> [...]

> - 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.


That still ignores the existence of a huge usability problem. The investment of time may pay off in the long run, but IRC is large enough investment (and ongoing maintenance, ZNC doesn't just take care of its self forever) that people will take a route of less resistance when presented.

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.


Slack chat provides a number of nice features that IRC (at least out of the box... I know there have been attempts) does not.

IRCCloud at least lets you see chat history, which IRC doesn't have out of the box but Slack does.


Slack only provides a bit of history unless it's a paid account. What open source community could support that many paid users on Slack?


That "bit of history" goes a long way, though. In particular, it means you don't lose context when you disconnect temporarily, which makes a huge difference for both mobile and laptop use cases. (Obviously, this is also one of the reasons why bouncers were invented for IRC - and why they're popular. But Slack having it out-of-the-box is a huge yak saver.)


IRCCloud's chat history is quite bad. I still find myself leaving bots in all chats to be able to grep logs.


So get a better IRC client? Really not hard to do things like syntax formatting and auto link follow (GUI versions of IRCII had plugins for this in the late 90s, so it's not like it's even a novel idea).


IRC as a protocol is very outdated. If I log in at home and forgot out log out at work, I need another username.

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-...


> but there's not a whole lot of movement on it. I think FreeNode has some v3 support.

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


"If I log in at home and forgot out log out at work, I need another username."

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 ?


Kids these days use tmux.


A better IRC client isn't going to provide chat history.


Just run your IRC client in screen/tmux like we've done for a quarter century.

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.


> Just run your IRC client in screen/tmux like we've done for a quarter century.

Wait... did you just tell me to go fuck myself?


I believe they did, Bob.


> 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...

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.


Encapsulates this era as the battleground of silo'd "as a service" vs "can be done"

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"


Jenkins has a IRC plugin, already in the stock distribution. Jenkins bot idles in channel, and logs all sorts of failures or successes, or whatever. With the irc server + channels setup, this also takes less than 2 minutes.


You can have Jenkins send IRC messages using a single invocation of netcat. This should take less than two minutes.


"log in to slack" vs. "deploy 3 services in the cloud by yourself and force everyone to use a specific irc client (good luck)"

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.


> 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.


> 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.

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.


> 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 ;)


How many people maintain their own email servers vs. use gmail?

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?


"prevents you from accessing it"

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.


You can get upset over this and argue with people, but that's not going to make anyone choose IRC over Slack.


Slack, Hipchat, Campfire, etc. are all just IRC for normal people. There is without a doubt a barrier to entry to IRC that actually requires a bit of understanding of how the protocol works. "I'm in #this-channel-you-told-me-about, but no one else is in here, wtf?". "Oh, you're on the wrong network - it's EFNet, not Freenode".

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.


> 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).

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.


Then start actual marketing. And make sure that I can switch from Slack to your product without any hangups, and have exactly the same feature parity, especially for non-technical users.


This is the first I've heard of an IRC bouncer. That's a great idea. It still seems like it's and extra step you have to add though, when really it'd be nice to see some work on IRCv3 so you could have multiple clients connect to one IRC server with the same username and sync without the need of a proxy.


The current answer to that is basically "Use IRCCloud", and that's what I link people who don't already know IRC to.

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.


When I was a wee lad I was always envious of people on IRC who had these things called "shell accounts" that let them stay connected to IRC 24/7.

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.


Or you can use a web based interface like the lounge.


A few people have replied, saying how to get chat history with IRC, but as far as I can tell, none of them work like Slack. With Slack, you can see history from before the first time you connect. It looks like none of the IRC solutions enable that; the IRC protocol doesn't make it possible, without the server (or a channel member) keeping logs.

(I haven't used either very much, so please correct me if I'm wrong.)


IRCCloud can, they're a client too :) I highly recommend them if you are serious about IRC.

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.

https://www.irccloud.com/


How does it do this? When you use IRCCloud to go to a channel for the first time, where does IRCCloud get the history for that channel from?

(You say "they're a client too" - I confess, I don't know what they are apart from a client.)


Like I was saying, IRCv3 has support for replaying the channel's history, as long as it's stored serverside. But I don't know if anything actually implements it, even IRCCloud which is v3-compatible.

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.


> At the moment if you join a channel you can't read its backlog, no.

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.


We are talking Open Source Project Communication not small group communication.

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?


Yes it is. This is exactly what Quassel and IRCCloud do.


"A better IRC client isn't going to provide chat history."

That's not even wrong.


An IRC bouncer (e.g. znc) can do this, but it's far from seamless.


The problem is that you might be running a nicer IRC setup, but almost nobody else is. Doesn't do you much good if everyone else logs off the second they close their laptop lid, or can't scroll back up to see what you just said because they had to relaunch their client.

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.


Not everyone is going to use the same client.


There's also TheLounge and ircanywhere which try to be FOSS IRCCloud


Eh, no, if you want to get a FLOSS product comparable to IRCCloud, Quassel + Quassel-Webserver are more appropriate comparisons.

TheLounge and ircanywhere are missing a lot in comparison.


What is Lounge missing compared to IRCCloud?


Mobile.

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).


Lounge has a responsive view you can save to home screen on iOS and android. Looks like this: http://i.imgur.com/MmajSU1.jpg


I've seen it, but it's nothing like even Quasseldroid. And quasseldroid is already a horrible codebase (mostly because I took over maintenance when I knew nothing about code quality).

Yet even Quasseldroid manages to be better.

That said, there is truly a need for a really good, FLOSS irc client ob mobile.


You're saying they're nothing like each other but are providing no examples. Besides one being an app and one being a website, what are the differences? Neither quasseldroid or Lounge have push notifications or searchable messages yet, so they seem to be pretty identical feature-wise.

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)


> Neither quasseldroid or Lounge have push notifications or searchable messages yet, so they seem to be pretty identical feature-wise.

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.


Quassel has them, doesn't mean Quasseldroid does :P

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).


The bad part of the codebase is bugginess, and RAM usage. Especially because it always keeps all messages in RAM.

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


If not primary, at what percentage is it a core form of collaboration?

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.


> 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 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.


Slack is successful because IRC web clients are so cumbersome and annoying. Most of the things Slack provides easily could've been provided in a web-based IRC client, but where's the upside for Slack in that?

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.


"What I do see is that more and more communities switch from IRC to Slack as the primary "sync" channel"

Just keep your hands off my mailman ...


Issue #2, that slack is based on synchronous communication, is something that is always ignored. Sometimes I log in to slack and see a conversation that I want to add something to, but it is 4 hours old with 50+ new messages on varying topics. Even with Slack's new threaded messages it is hard to evolve the conversation after all the synchronous folks have moved on to other topics.


I don't understand why people seem to thing that chats will solve all the problems. Chatting is having to write the same thing a million times.


> Chatting is having to write the same thing a million times.

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.


The problem is though, that some people like to be the local expert on IRC/Slack with all the answers. They don't want to document it elsewhere.


Then that person is doing all the legwork, but someone else can come along and create a KB themselves with those answers.


Fix your group's culture. Document things. If people refuse to document things, then do it for them and shove your docs in their face. Do it until they write the documentation themselves.


> Fix your group's culture.

Culture-change is about the hardest thing to achieve.


It's also the most important thing. If your culture is bad, changing what tool you use isn't going to fix everything. You're just going to have a new tool everyone uses poorly.


Could clever chatbots help there? Might be hard to avoid being intrusive though.


It's easier to ask for help NOW and get customized answers NOW than to dig through a wiki/documentation for the answer.


Proving the point that someone then has to repeat the content of the docs.


Of course - I'm just saying it's easier for the customer/consumer.


It's easier for you. As the person who answers your question, it's easier for me to point you at the documentation


What you're looking for is email. Multi-user chat simulates a real life conversation, and in real conversations it's also awkward to say "hey so going back to what we were talking about 15 minutes ago..." after the conversation has moved on.


No, email is terrible. There's no history. You can't "scroll up" to see what people were talking about. You can't link to another specific email to reference it (yes, there's archive services, but then you have to go dig through an archive to try to find a horridly formatted email to link to, which is completely separate from the normal consumption platform).


I actually argued here recently that email was hard to switch away from because of the history. You can keep your emails forever. I have emails from 2007 sitting in my inbox. And if I want to keep them, I can download them with IMAP or POP. If I send an email to five people and they remember to hit "reply all", well that's a conversation, isn't it? And if I need to show someone an email they weren't party to originally, I can forward it to them.


That puts the onus on every single person to maintain the history of the project. Lots of people delete mail (not me, but lots of people). Also, you can't retain history of what was sent before you joined. Also, emailing individual documents means people can't research by themselves.


I mean, email isn't meant to be a document repository. Slack (or other chat) is great for immediate conversations with many people. Email is great for slower conversations with a more limited number of people. A wiki is great for a very slow conversation. An actual document repository is great to be able to link to when using any of the other conversation methods.

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're correct, but Usenet does provide those features and is very similar to email from a user standpoint.


This is just wrong.


I never used Slack, but in IRC I'd quote what the user said (a format like "<user> message", optionally with a time) if it's really relevant; and in Telegram it's a simple matter to rightclick and reply (which allows people to click/tap it to jump back to context) which I feel much less bad about.


If I really wanted to bring up a topic that had passed, I would break out to a separate channel and invite the relevant people and drop a note in the main channel with a "bringing things back up about $conversation in #newchannel". This works better than writing to threads in my experience.


I have recently started using slack and I see the same. Once a conversation has moved on it gets awkward to move back to the previous topic.


This may be a shortcoming of the UI, more than anything else. There's definitely room for improvement here as I often miss updates to threaded conversations even as I'm looking for them.


I think they could make threads work with some simple changes:

* 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).


Chats (of whatever type) have never been a good solution for this, that's why mailing lists exist. Improvements there would be nice, sure, but are unlikely to come from a chat service. They just solve different problems.


This is more of a usage problem that anything else. If your organization makes decisions based on synchronous communications, without stopping to notice who wasn't included and get their input before final decisions are made, that is a cultural problem, not a tooling problem.


The biggest problem I had is that if you wanted to scroll back through those 50+ new messages you need 32GB of RAM.


Good points but the bigger problem for me is the lack of an archive.

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.


Well, some of the open communities are using http://slackarchive.io/


Thanks for the pointer! Hadn't seen this before.


thanks for the pointer. I started using this today for pytorch


If you have a nonprofit for your project, you can also get on their nonprofit plan. At https://hackclub.com we get unlimited archival without paying for this reason.


Last I checked they only offered 85% discounts for non-profit teams. Has this changed?


We're on a completely comped plan with them. Not sure if we were grandfathered or have some sort of special deal.


I completely agree with this. I'm part of a group that's trying to help people in the local community learn programming and we're using Slack to chat outside of any scheduled sessions. We're at over 1000 members in Slack now and are seeing messages disappear before the two-week mark. We don't collect any money from our members and Slack's pricing model makes it unfeasible for us. At this point, Slack's search feature is hit or miss when searching for anything over a week old.


With respect - Slack is a business that runs on a freemium model. You can't expect them to handle your (large) user base for free just because.


With respect - you are reading something that wasn't necessarily there, the person you were responding to said nothing about expecting Slack to change their business model.


Which sounds like another reason Slack is inappropriate for open source communication. Money is a completely valid reason.


That still doesn't make Slack an appropriate choice for open source. Even if the project didn't mind paying, Slack's business model is wholly incompatible with the traffic that an open source project would expect (lots and lots of not very active users)


Just a note: if you go from free to paid, you can recover those lost messages. They're never actually deleted, you just can't view messages after the 10k limit in the free version.


Wow, that is kind of evil. I could understand if Slack kept, say, the last 20k or 50k and only showed the most recent 10k. For them to store all the messages indefinitely for all free servers means that they are incurring the same storage costs whether the server is free or paid. Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?


They might be shunted to a disk somewhere and removed from search indices while on the free plan, reducing their costs but allowing them to recover things after.

> 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.


I doubt it's a bandwidth issue. It's probably that they have to keep more servers/servers with more ram up to index all the messages. Keeping something on a disk that never gets read is far less expensive than keeping it in RAM and indexed so that it can be quickly and easily searched.


"evil"

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.


It's not evil nor is it about the bandwidth costs, it's just business. It's how they get you to spend money on a freemium product after you reach a certain cap. They've determined that you should pay if you're hitting the 10k messages limit.


No, they hold your data hostage because they can. Welcome to capitalism.


!? Except hostages don't know they're being kidnapped. Slack's pricing is no secret.


I assume you mean "hostages don't agree to be kidnapped"


yes, I suppose Slack not existing at all is a more preferable option /s


Actually yes


Third choice: Slack exists, but doesn't hold your data hostage until you pay. I mean, on my list of things I care about ideologically, this is lower than my concern for warm gin and my dislike of sweatpants. It's legal and totally within their right, but it's a crappy way to behave.


Forums. I don't know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.


> Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.

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.


> How is it even remotely sane to provide a user interface instead of an API/protocol?

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?


Why not both? Something like DFeed[1] which is used as the D programming language's forum[2].

[1] https://github.com/CyberShadow/DFeed

[2] https://forum.dlang.org/


Yeah, sure, provide as many user interfaces as you like, just not instead of an API/protocol. The whole point is that everyone can choose the UI they prefer, or build their own if they like.


The forums I visited all died, but none replaced them (and I kinda miss forums). There are still some active forums that I know of, like Factorio's (a modern game, not one from 2001 when forums were still hot). They have a subreddit which is active as well (though less), but the forum format still works fine for them.

New services replaced many things that forums were used for, but not all.


there are also bay12games forums, but yeah, reddit seems to have eaten the forum format mostly


Reddit and Facebook ate forums. Reddit in particular fills that interest-niche conversation role to a degree that it strangles forums.


Reddit IS a forum platform. Anyone who wants to create a subreddit can do exactly that. Reddit did not replace forums, just the software that they run on.


Reddit is distinctly different from a typical forum due to how heavily it weighs time and popularity. A normal forum can have multiple threads of thought active at the same time without interference, and sometimes a thread can live for a long, long time. There's no need for a thread to be super popular to survive, a thread can literally live off of two users.

On reddit, if the time is not right, the discussion will not be had and ends up in oblivion.


BUMP!

Doesn't work with reddit.


They're generally fucking terrible in terms of UI. I much prefer Google Groups over older forums. Discourse is even better but there's no easy way to setup a forum for free. The last time I looked into it it would be roughly $10 a month for a DigitalOcean droplet to run a small forum, but that was more than I wanted to spend myself. And accepting money is a non-zero amount of work too.

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.


> I much prefer Google Groups over older forums.

Interestingly enough, most people I know found the Google groups interface significantly worse compared to their Usenet client.


It's such a disappointment that social networks killed forums! The experience is so much poorer now. There's insane amount of fragmentation (everybody wants to run their own thing because likes), no search, no discoverability, no ways to conveniently track the discussions.

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.


Forums. I don't know why the internet got tired of them

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.


> the [forum] 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.

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).


Probably because you would need to remember what the addresses were, what your credentials were (for each forum you joined) in order to participate. Also, administrators could disrupt discussions any time they wanted or restrict people from posting in the same vein.

Usenet, on the other hand, didn't have these problems, though it pretty much ended up the same way.


A lot of meaningful discussion for Rust happens on the /r/rust subreddit.


I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments.

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.


> I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments.

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?


If you're communicating with someone from a dicferent continent offline, get ready for a bill from your landline.

We're gravitating towards better products. Sorry, but having used IRC a lot, Slack is just better.


> 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?

your point fails to address this point; similarly 'better' has varying metrics.


> Seeing the same people in the member list every day, exchanging little inside jokes

...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, ...


How can you generally prevent a subgroup "deciding the content that should be written on the main channel for the benefit of outsiders asleep in other time zones" even in an 'asynchronous' communication channel? There's nothing stopping them from responding to each other quickly enough to effectively communicate 'synchronously'.

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.


Stallman only really cares about free software and not really OSS. But I get what you're saying.


Free software and open source software are synonyms. Even Stallman agrees on this. He cares about the use of the terms because of their other implications.


Ok, that's interesting. My impression from watching his talks is that he does not consider the two ideas as synonymous, in that a software can technically be closed-source but have licensing that is libre-free so that it can be used by whomever however. But perhaps I got it wrong.


It is the other way around: just because the source is available free of charge does not make the software free as in freedom. For example, there are licenses that prohibit you from running the software for commercial use even though you have access to the source. This would not fit the FSF's definition of free software because the user should have the right to use the software as they wish.


Those licenses also aren't open source. 'Open source' doesn't mean 'you can view the source', it means you can view, run, compile, modify and distribute the source, and distribute modified copies.


I am the lead developer of Zulip (zulip.org), an open source Slack alternative built around a better threading model.

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).


The threading model in Zulip is genius. It's the perfect marriage between instant messaging and email.

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!)


It might be more useful to speak in general terms than call out Slack in particular. The concerns expressed here aren't limited to Slack (despite the link-baity title), but any form of communication that:

(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.


Are there any open source projects that coordinate development or provide support primarily through in-person discussions at conferences?


I don't know about "primarily", but it's certainly an important aspect overall for many projects.


Except with both Slack and Gitter (not sure about others) you can link to specific messages. Sure you still need membership to view the content (a serious downside), but saying you can't link at all is disingenuous.


With Slack, at least, channel history is truncated for free accounts; so it's quite possible that a specific conversation could become practically inaccessible after a while.


You are able to export your entire public history, regardless of the status of your account. I was able to do this to rescue the chat history for Hyperledger[0][1] before we moved to Rocket.Chat.

[0] https://github.com/hyperledger/slack-archive

[1] http://slack-archive.hyperledger.org/html/index.html


Slack is technically inept as well. Earlier today I was modifying a robot design in Fusion 360. Huge beast of a model with too many parts to bother counting. Fusion was consuming nearly 900MB of memory (and I am rounding up here). Which is unsurprising for a CAD package editing a large model.

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.


It seems to me that Slack could position itself to provide free and open access to certain types of communities like open source projects, charities, etc. Enable the "pro" features so long as the community follows the rules.

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.


But if your entire infrastructure is centrally managed and can disappear at a company's whim, you're setting your community up for problems.


This applies to Freenode as much as it applies to Slack. If freenode disappears, people using its channels for foss will have similar issues and inconvenience as if Slack/Discord disappear and in both cases, it's recoverable.


If freenode disappears, it's less than a day to pick a new network and connect.

Nobody changes clients, tooling, etc. That's the difference between a closed walled garden like slack and an open protocol.


Nobody changes clients if Slack disappears and is replaced by another webapp. It's all in browser.

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.


> Nobody changes clients if Slack disappears and is replaced by another webapp. It's all in browser.

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 Freenode disappears, people will join Debian over on OFTC. I'm not sure if Mozilla and GNU/FSF use Freenode or run their own infrastructure but if the former, then they may set up their own network(s).

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?


SSL is not required and it's certainly not default in most clients.

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.


Mozilla has its own server, irc.mozilla.org, distinct from freenode.


>The UI might change

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.


That's why you use Matrix instead.


This is the point that I can't get anyone to see. So what if they provide history? They can take it away at any point too. So what have you accomplished?!


This is certainly true for github as well.


Git is decentralized so being dependent on a central repo is the users' fault not the organization.

But that said, I don't put anything on Github if I can avoid it. Disgusting organization with awful management.


There is a lot of vendor lock in for git these days, everything from CI integration to git clients hard coded for github. We spent most of the 90's and 00's breaking vendor lock in and then forgot it was a thing.


I believe the Cloud Native Computing Foundation qualified for discounted pricing for the Kubernetes slack channel under this program https://get.slack.help/hc/en-us/articles/204368833


This is true: https://www.cncf.io/blog/2017/03/01/slack-gives-back-k8s-cnc...

Slack extended their not profit pricing to 501(c)(6) not profit organizations which covers CNCF projects like Kubernetes.


I feel like more and more people are coming around to seeing the relevancy of distributed federated chat and breaking out of the walled gardens. My person money is on Matrix[0] taking off but I think the general theme of people pulling away from interesting their communication to corporations is a positive. [0] matrix.org


Everyone should be using Matrix. Not just open source developers.

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.


The ease of bridging is great. We've got a minecraft server bridge of all things; being liberated to actually have universal chat is the future for sure.


Yes, Matrix has great momentum. It is somewhat sad that XMPP is falling behind. There is no technical reason, why Matrix should be superior, but they are winning.


Similarly, the huge buzz over the past few weeks about Mastodon as a distributed/decentralized micro-blogging service has been positive. People starting to learn more about federation and decentralization. Good to see.


Tangentially, I don't get how developers on the one hand strive for private offices and no (physical) interruptions, but on the other want to communicate through chat channels. Maybe these are different people altogether, and I'm just getting the wrong impression. But personally I prefer a little personal interaction over a long chat.


I don't have to drop (as much of) my mental state in order to communicate via chat. It's asynchronous, so I can finish typing out whatever I'm thinking about, or looking for whatever I'm trying to find, kick off a build, etc., and then turn my attention to the chat window and bang out whatever comes next in the conversation. Once written, I can switch right back to whatever I was doing - I type quickly, so it's usually only a few seconds of interruption. I can easily carry on a couple of extended chat conversations while simultaneously continuing to get my actual work done.

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.


> It's asynchronous

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.


> I don't get how developers on the one hand strive for private offices and no (physical) interruptions, but on the other want to communicate through chat channels.

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.


Thanks for the reply. I'm glad it works for you.

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.


Easier to compose an eloquent and effective reply in chat than in person. Time to think over the messages etc before responding. Can pick my nose while talking to you etc.


As someone who works remotely, I really appreciate things happening more on chat channels, because then I'm included in part of them.

> 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.


I'm with you on the personal interaction but I think people like slack/email/IM because it allows them to be in control of their communication. If someone drops by your office/cube, it snaps you out of your flow and you have to work to pick it up again. With the online forms of communication, you can turn them off and be guaranteed some distraction free coding time.


For me it's probably selfishness. I'm an infinite inboxer, who prefers synchronous communication (if any). If I need something, I'm going to walk up or call, and yet my door stays closed. So the two preferences aren't mutually exclusive, but in my experience these generally ARE different people altogether.


Mattermost is an excellent open-source Slack clone. It would be interesting if someone could add a feature to publicly host chat logs for indexing by public search engines.


I've been testing mattermost for a while but recently came across rocketchat and on the surface it seems much better. But I haven't tested it yet.

It remains to be seen if it has proper AD integration for example.


Many of these complaints are just as valid for any business or organization trying to function as a modern software-based org in this day and age.

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...


I'm not sure about others, but I very much dislike the idea of multiple channels (the way Slack, Discord, etc. do it) on one server/chat. It feels messy and half the time conversation doesn't fit neatly into any of the choices. Honestly, I can't think of something I'd rather use over Telegram here -- if I need multiple discussions it's just like IRC: I make a different chat for each one, rather than having to awkwardly subdivide my main chat. It also has the advantage (even more so than IRC) that all users exist on the same server, so you never have to deal with the awkward per-group account system (Slack) or server-only messaging (Discord) or having to switch rizon->freenode->mozilla IRC. WhatsApp would probably be just as good if not for publicly identifying users by phone number, what it really comes down to for me is just having a normal chat app. Maybe even plain old Skype would be nice if it wasn't proprietary. I don't need you to innovate the way my chat system works with fancy new methods of grouping users. I don't mind the bells and whistles (voice/video chat, bots, stickers/emoji, ...) as long as it doesn't get in the way of me having a conversation. But for fuck's sake don't try to cut off every group from everyone else like Discord/Slack.


Mattermost is an open source alternative to Slack btw.

And Discourse is pretty great, though much more like a forum.


We have been using http://rocket.chat at work and it works beautifully. Slack was never an option for it was not self-hostable


Also a good choice.


Forums work better.

Using IRC/Slack in place of forums is like using a wiki in place of real documentation.


It's much worse. A wiki still consists of pages of documents, even if they're kind of improvisational and perhaps incomplete. A chat log is just a log of people chatting, with all the free-wheeling and meandering conversational style that entails.


Forums fall apart when you're trying to do things like realtime debugging. With a chat client, I can leave a window open in a corner and keep an eye on it while doing other things. With a forum, that becomes a game of hitting refresh every thirty seconds waiting for new messages.


I personally prefer Gitter & other tools over Slack for open source communications. The Slack signup process can be a road block as it takes to many steps. To often I run into open source communities that require you to join their Slack channel for posting any questions (that may or may not be bugs in their software).

I really like Slack for a lot of things, but it's often a tool used incorrectly due to its popularity.


It's frustrating that the choice seems to be between modern closed tools like Slack and Hangouts and antiquated open tools like IRC and mailing lists.


Question for you:

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?


To have all the features you get for free out of slack, you have to do a lot of work and maintenance to get out of IRC and mailing lists.

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.


Slack gets a lot worse once you want to start dealing with two teams using it. With most IRC clients, I can have connections to multiple servers running, and able to see at a glance everywhere that there's activity. With Slack/Discord/etc, that involves a frenzy of clicking as you look through each group of chats individually. I can lay things out how I want, move things around, etc. Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients instead of having to keep another web page open to another javascript-laden nightmare.


> Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients

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/


I think slack calls them gateways, not bridges. And if you compare to matrix bridges, gateway seems like a suitable name.


> 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.

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.


> 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.

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.


> 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.


> On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages

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).


The problems with mailing lists?

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.


> Quoting is still a problem. Most answer above. Some below. Many nitpick in between.

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.


The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.

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.


> The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.

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.


Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.

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!


> Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.

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.


Orrr there's "modern" open tools like Matrix+Riot, too, which would fit most open-source communities wonderfully.


What really needs to die is the view that old tools are bad tools. In my experience, the most useful tools I use (standard unix utilities, vim, emacs, lisp, etc) are the oldest ones while the newer ones are the ones I could most easily replace.


Hmm.. Matrix? XMPP?


> between modern closed tools like Slack and Hangouts

and Telegram and Wire and Riot and Semaphor and Tox and... Plenty of non-closed tools.


> Slack, et al, are based on synchronous communication, which discriminate against those who do not or can not take part of the conversation in real time. For example, real time chat discriminates against those who aren’t in the same time zone–you can’t participate fully in an open source project if all the discussion happens while you’re asleep. Even if you are in the same time zone, real time chat assumes a privilege that you have the spare time–or an employer who doesn’t mind you being constantly distracted–to be virtually present in a chat room. Online chat clients are resource hogs, and presume the availability of a fast computer and ample, always on, internet connection, again raising the bar for participation.

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.


There's no talk of 'oppression' anywhere in the article.

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?


Here's combined forum + chat + question & answers software that you might want to use instead of Slack:

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.)


I can't believe that in 2017 we're still discussing what's wrong with our chat software. I have to wonder when we will finally see chat as a solved problem.


The OP isn't actually discussing chat as an unsolved problem. OP is arguing that chat is the wrong choice of solution to the problem of open source software project communication, because it's synchronous.

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.


OP is arguing we should use boats for everything, including sending something across town. Realtime chat works a lot better for certain things, like troubleshooting, where having to wait around for a forum/email response may not be the best way of doing things.


Well this was not directed at the article as much as the other comments in this thread, some of which I wholeheartedly agree with.


A different take on solving the problem of asynchronous communication: JayPad is a simple web app which works like a tiny mix of Slack/Group Chat and Post-Its. Offering synchronous discussion via chat and the possibility to store results of these discussions into a container of Notes for asynchronous consumption.

In its early stages, but working beautifully.

[1] https://jaypad.de

[2] https://hackernoon.com/how-jaypads-help-us-build-jaypads-c66...

[3] https://hackernoon.com/how-planning-a-weekend-trip-with-our-...

[4] https://www.youtube.com/watch?v=0g2Hecd-Ujo&


Discourse offers free hosting for big Open Source projects, and you can self-host it on a $5 VPS too.

Full Disclosure: I work at Discourse.


I doubt Discourse will run on a $5 VPS. The last time I checked its crashes on 512MB RAM, needs at least 1GB just to start. Have the minimum requirements changed? 1GB minimum and 2GB is recommended by Discourse itself.

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.


I believe Linode and Vultr already have $5 1GB VPS offers.

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...


I did just run across a cloud provider with $5 VMs with 1 GB of RAM (somewhere), but the last time I checked it's at least $10 per month to host Discourse on DigitalOcean or similar.


To be fair, you don't actually need to know Docker beyond being able to follow a tutorial.


As I posted on twitter[1], Slack is linkable. Not public, but if you can chat you see them. Gitter: public AND linkable. Async is a good argument; linkability is not.

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.


Slack doesn't have public links and an archive of posts, it's a stream behind a login, which might go away at any time on an active project. It's a terrible idea for anything other than ephemeral communications which don't need to be logged or kept. Re the UI, for a chat app it's fine, most conversations around an open-source project should not be held in a chat format however, but in a format that respects participants not being in the same time zone or having the same time pressures (that means an async format, not a linear chat).

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.


'Async' isn't even that good of an argument.

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'.


> [2] I've been on IRC on and off since 1993. It's much worse.

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.


The argument about why slack doesn't work well is a bit of a stretch. I understand all the points on closed system etc. But the author states that slack doesn't work because it's synchronous and it excludes others from participating in the conversation. Then mentions that even with history recorded, the person in a different time zone can't participate. Then the argument is to use email threads instead. email suffers the same problem of slack, where those who didn't check their email while a discussion was happening now feel missed out on. However, they can reply 8-20 hours later or even days later. Well, you could do the same thing with slack. The problem with slack is the lack of relevant threads. Everything is one giant thread. But that is how most email mailing groups become anyways.

Now, I am not a proponent of slack, I think it has its own problems, but I don't think email is any better.


I think there are good points there about offline participation and archival. I would expect that 99.9% of those on HN have at one time or another found an answer via a direct forum/message list archive or off a google search result returning the same. That will not happen as discussions move to Slack like systems and even if it were, threading would not likely exist.

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?


Sounds like a great new splash screen for them.

"Slack is inappropriate for open source communications" - Your friends at Slack.


I've been making this exact case since it came to popularity.

There's tons of FOSS alternatives! No excuses!


The article, at the end (spoilers) states that async communication should be preferred for open source work. And I agree that async is important. But there are times where you do need that synchronous, let's talk now communication. And for that, Slack is great.


My HN feed right now:

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.


Can we just go back to aim? I really hate having one damn view for channels, so if I'm talking to two people I have to constantly switch back and forth. I still don't get how these kinds of tools get such a big following.


I think that's the biggest flaw with a lot of web-based chats. There's no flexibility in layout. With a chat app like pidgin, I can choose how things are laid out, set up notifications a lot easier, etc. Webapps tend to be a lot more limited in such areas -- not able to choose notification sounds, set various things to notify in different ways, etc.


Yeah but no one seems to be making anything but web apps. I guess I come from a time just before this but I honestly can't understand how people think these things are better than their native counterparts.


How did AIM do that? I've never used it. (In my geographical region MSN was the thing.)


For a long time it opened a new window for each conversation so you could have a few going at once and see them all side-by-side. At some point tabbed windows became standard, but I'm pretty sure most clients like Pidgin will still give you the option of separate windows.


I think many opensource communities do not want to dogfood on other opensource projects anymore. They want the best product out there for other things and more often than not these products are closed source SaaS products.


> This means that the content inside those systems is closed. I cannot link to a discussion in a Slack channel in a tweet.

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.


> Mailing lists suck. They're hard to read, hard to follow,

I find them quite easy to read using a mail/news reader and connecting via a NNTP gateway like gmane.


Just yesterday I was looking for a way to present all the messages in a given Slack channel as an RSS feed, and I was surprised to come up empty. (I found lots of ways to go the other way though, from RSS into Slack.) The best I found was this, but it looks like you need a Heroku Dyno and must be the account owner---oh and it only exports links, not full messages:

https://gozman.github.io/slack-rss/

So that is one drawback to a closed system.


Please, stop advertising slack. Any time when i read hackernews, i see 2-3 'news' about this chat program. It was big mistake to use slack in our company.


Curious why: as a specific tool, or, would IRC / Skype / whatever have been equally as bad (e.g. because they suck productivity and encourage factionalism or...)?

(My org uses it having replaced Skype for team chat, and so far it's been an improvement for us.)


Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad.


"Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad."

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.


Well, not emailing me a password in the clear once a month would be a start. Needing yet another username and password for a site they already has its own some sort user login system is another wart that is easy enough to solve, but for some reason or another, hasn't been fixed on any sites in recent memory.

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.


> Mailing lists really are preferable for a number of reasons

What reasons?


The biggest reason is that it's asynchronous. Not everything needs an answer right now this instant, and in order for there to be an instant reply, someone has to be on the other end of the keyboard and continual interruption is a way to get nothing done real fast.


I have had good experience communication with the Aurelia.js community using Gitter. I strongly recommend it.


Does Slack's terms of use forbidden creating an off platform archive?

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.


Yes, but chat logs are logs of ... chat. By nature, it's disorganised, free-wheeling, contains lots of casual meandering (as any conversation would). Not very useful to a third party.

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.


I did find some gems on irc logs, but I agree, they should be treated as snooping on conversations


The problem isn't creating an archive, it is a) synchronizing the archive properly to account for your feeds connectivity issues, and b) providing the archive usefully once it gets large and/or popular

(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



Is an example of a third-party archiving chat, though doesn't appear to be open source; possible it is though, but if it I'm unable to find the code.


  forbid creating an off platform archive
I'm not sure that's a substantively enforceable idea.

Just try and stop me?


Break the terms of service, and you'll be booted off. Be a large enough problem, as they see it, and you'll get the entire project booted off.

Probably they don't care enough to enforce, but surely you see it's part of the problem that they could?


Right, but they do still permit the capacity to read accessible history, which is open to scraping and archiving. They can't completely kill the concept of doing that, realistically.

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.


what do people think about zulip.org?


I know most people hate meetings, but chats are worse. Maybe you want a Bulletin board system ?


I was [breifly] part of a project that used slack as the primary communication medium. I can second all the points in the article. IRC is a terrible format for open source collaboration. Flame wars can get out of control really quickly via text.


Feel like this argument happened 5 months ago and 5 months before that too


It's been going one since the first companies tried to monopolize Internet chat by centralizing it on their infrastructure in the 90ies.

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.


Well, this one was supposed to be a little different, as instead of open vs closed, it was sync vs async. But when the topic of OS projects and closed tools comes up...


and it needs to continue to happen until OSS communities ditch Slack.


You're never going to move large groups of people by just yelling "xxx is terrible!" You have to make something better that people want to use to get them to switch. Unfortunately, Slack is better than IRC in many ways that matter to a lot of people. Ignoring all of those things doesn't make IRC better, and it's not going to make people want to use IRC over Slack.


Because the things that are driving people to use Slack are the same as existed five months ago, and arguments like this do nothing to prevent people moving.


For open source projects: offer Github issues, IRC for chat and a proper forum like phpbb or a more modern forum like discourse (or one of the clones) and/or a mailing list.


> offer Github issues

Why a proprietary issue tracker that requires that people make an account with them in order to communicate with you?


Replace Github with your favorite modern bug tracker. Some very old software Bugzilla/Trac/Confluence are not modern, have a bad UX and kind of off-putting.


No, really, replace github with nothing at all, they are all equally off-putting, because the concept of offering (only) a user interface and in particular accounts to external parties is stupid in the first place.

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 don't quite understand what everyone has against email. Just get a good client and server with imap IDLE support and you should be good to go.


I must've missed the memo which says any conversation around the globe is waiting for my input before it proceeds.


Well put.

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 a group has the choice between realtime and asynchronous channels there needs to be a guideline for this.

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 completely agree. Unfortunately, what I've seen more than once is that mgmt (or even someone from the rank-and-file) sees / experiences a new tool like Slack (or Campfire, or Hangouts, or...) and says "hey, great new tool we should use!" and that's the 'decision'. No thought given to how async comms biases development when developers are spread world-wide.

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.


I feel ya, it's frustrating. Although I did not yet have a problem with time zones, I experienced being left out simply by joining the chat later in the evening.


I agree, but it's not a shortcoming of the tool (no tool can fix it, anyway) as much as a shortcoming of the process.


I like IRCCloud, it lets me use an open platform, but pay for archival of the channels I care about.


Honestly wondering what benefit for business chat that Slack has over IRC for software devs?


Free and unlimited 'Slack' is Bitrix24. Smart people switched years ago.


Switched from Slack to Telegram. The desktop client is so much faster.


Just discovered Gitter this week. That may be a suitable alternative.


IRC (and Slack) are not real-time. Why do people think this?


I don't know why didn't just evolve irc. Feature wise slack doesn't really bring much new. It just has a good interface. If someone made an irc client as easy to use as slack then we'd have our answer.


> It just has a good interface

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.


It really is. Slack's interface is good enough and easy enough to understand that even the least technical people can pick it up in a few minutes after you show it to them and explain the difference between public and private channels. A week or two of use is enough to master everyday Slack use. Slack may not bring much to the table in terms of new functionality, but it does make it insanely easy for the average person to easily use the system and be involved, which really cannot be overstated when working at a company with a varying level of technical abilities.


irssi is a significantly better interface than any slack application.


The technically illiterate people I know would have a much harder time using irssi than slack


Slack's users would disagree.


From my understanding, this is what XMPP was suppose to be. Problem is the going to be the same evolving IRC: widespread adoption.


"Feature wise slack doesn't really bring much new. It just has a good interface."

That's a pretty huge feature. Never underestimate how making something more usable increases it's popularity.


Really - what is sooo unusable about IRC?

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...


Can you easily share multi-line code, formatted in a proportional font and syntax highlighted, in any IRC client? That's something I want to do almost every hour I'm working.


Some clients will intercept multi-line messages and let you POST the content to a pastebin. That way, supported clients show pretty-printed code and unsupported client just see a URL.

Ex: https://blog.irccloud.com/pastebins/


And how do I know that everyone in the room is using such a client? I know that everyone using Slack will see the message as I intended it to be seen.


Because adding a feature to a standard means you have to get everyone on board. Slack as an IRC client would basically be Slack as it is now, and the server protocol would be an implementation detail.


Except, we got everyone on board. Every major client and server dev, every major bot dev and every major network.

Check out ircv3.net


I massively disagree with #2. Unless your project has very little activity, synchronous or pseudosynchronous communication is a lot more efficient than async through email/discourse. It's also a lot more friendly to your contributors, it makes things less formal and more human.

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.


The biggest problem I have with discord is that the client is complete and absolute balls if you want to be in more than one group at once and keep up with notifications and the like. With IRC, my one client shows the activity of all of the networks I'm in, with discord, the only notification I get is that there's "something" going on in another group, without telling the channel, etc. It's much more interrupting and frustrating.


Some people only go to church on holidays...


It seems kind of funny that an open source project can't find an open source form of communication.


Matrix is distributed chat system that is free software and people really should be switching to rather than everyone moving to Slack.


IRC and mailing lists have worked for 20? 30? years and continue to work today.


Well, then we can all turn off our computers and go home, because something that "works" is obviously good enough and the entire software industry doesn't need to exist anymore. Most things we have today "work" but we're still improving on them because "good enough" isn't good enough.


The question you're not asking is whether your replacement is better than the existing solutions. Slack isn't. It's closed source, proprietary, and tied to a third party's servers. I'm not going to tie my projects or company to that kind of anchor.


Absolutely. I completely agree that Slack brings too many problems to the table to be a replacement for IRC+Mailing lists.

I'm just saying that IRC+Mailing lists aren't good enough.


Exactly, that’s why we evolve them (see ircv3.net), or try to reinvent them (see matrix.org), and don’t try to make a proprietary clone and sell it.


I might be wrong in saying this, but I suppose that most open source projects use IRC, and the larger, important ones use mailing lists.


Was hoping for something original but nope:

> these services are not open




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: