Hacker News new | comments | show | ask | jobs | submit login
Why Slack is inappropriate for open source communications (cheney.net)
847 points by im_dario 246 days ago | 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 ...

More

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

Search: