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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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...).
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.
> No standard identity services. NickServ is a common bolt-on, but it's a total hack. (It works by pretending it's another IRC server!)
You mean it works by pretending that it is another user. The reason for it is an optional component. Some networks (especially the largest one) are running successfully without such services. I kind of like this approach because it leaves the server protocol simple (networks often provide multiple services NickServ, ChanServ, MemoServ etc) and makes the component optional.
> Bold, colors, and emotes (/me) are all client-side hacks.
If you think about it, does it have to be server side? Server is just to relay messages, what they mean is up to a client. In fact pretty much any chat network that allows multiple clients has different looking emoticons. So making it part of the network doesn't help at all with unification.
> DCC file transfer is a complete and utter mess. It's like TFTP, but poorly implemented, over a TCP transport.
HTTP is also over TCP so not sure what you are trying to say here (BTW: TFTP works over UDP).
But ignoring the TCP part, yes DCC feels like it has problem, but that's mainly because of NAT becoming popular. Hopefully as IPv6 is adopted we get back to previous times where ach user had own IP address.
Anyway, comparing DCC to slack etc. Is a bit unfair, because their service is nothing like DCC (Direct-Client-to-Client i.e. P2P) when you upload a file to slack you upload it to their server, but with DCC you're sending it directly to the user without any 3rd party involvement.
Looking at the issues you listed, it feels to me that the problem is not as much with IRC servers, but with IRC clients, in particularly lack of standardization. You could solve most of the issue by defining client protocol on top of IRC, for example:
- handling encoding
- abstracting communication with services
- colors/emoticons
- file transfer (instead of using DCC which sucks with NAT) a client could upload file to a server and provide link to others, emulating behavior of other chat networks
The nice thing about it is that most of this could be implemented in a way that standard clients would still be usable, but if a standard would be created and other IRC clients would respect it, IRC could easily compete with existing solutions.
> Well, doesn't that mean the limit is 510 characters including the command?
No. The limit is on what the server sends to other clients when a message is delivered. For instance, if you send:
PRIVMSG #channel :some long message
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
(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)
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 :)
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]
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.
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.
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 :)
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 :)
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.
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 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.
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.
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.
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.
Well. I'm interested to see what you think is a suitable protocol for business.
I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things.
So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.
I'm not very familiar with all of the chat protocols, but I'm familiar with the possibilities of communication today. It's riddled with proprietary protocols and chromium based applications. And that's why I see Matrix as the next step.
> So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.
That’s why IRCv3 is a thing, slowly replacing the hacks with proper specs. No more NickServ, but instead SASL and account-notify. No more guessing where some batch of messages ends, but a batch message type.
> It's riddled with […] chromium based applications.
So is Matrix.
I’m not saying Matrix is bad, Matrix has some awesome properties (especially regarding encryption). And maybe someday it can become awesome, once it gains a proper binary transport system, which is more efficient and keeps a single socket open. And maybe then, we can finally replace IRC, XMPP, etc.
But until then, I’ll keep working on improving IRC.
>I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things.
Let's take those each at a time, shall we?
>Emojis
This has nothing to do with the protocol. If you can send arbitrary UTF-8 messages (which you should be able to do, obviously, and can with modern IRC clients) then you can send emojis to your heart's content.
>Search
I've never personally found search particularly useful, but there's nothing about IRC that makes it any harder or easier to search messages. The way all chat search works and will always work is that you log chat messages somewhere and provide a way to search them. That has nothing to do with the protocol and everything to do with the server logging messages.
You can then extend your chat protocol with a command that you send to the server that asks it to search the current channel (or all channels, or all channels I'm in, or all channels I've been in, or all messages sent in all channels that I was in at the time, that's up to the server though - corporate probably want the former, public you'd want the last one) for a particular string/regexp/whatever.
There's nothing particularly complex here from the perspective of the chat protocol and in fact it would be simple to extend the IRC protocol with a command for doing this at the protocol level. It's just much easier to write bots to log messages and web interfaces to search those logs with.
>Session persistence
No, nobody wants this. What people want are to see messages sent while they weren't there and to be able to receive messages while away. The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.
>Web client
There are lots of IRC web clients, and all you need for this is a simple protocol.
>So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today.
IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.
Are you serious? I think lots of people do. I think it's one of the draws of Slack.
> The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.
Is that what Slack does? Whatever they do, I think it's what people want. Indeed it is not an experience offered by IRC, perhaps because "most IRC servers don't want" to, sure.
>Are you serious? I think lots of people do. I think it's one of the draws of Slack.
No it isn't. What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc.
>Is that what Slack does? Whatever they do, I think it's what people want. Indeed it is not an experience offered by IRC, perhaps because "most IRC servers don't want" to, sure.
Slack has a much higher barrier to entry than IRC and most people using it are private companies.
IRC servers are publicly accessible and publicly accessed. They have existed for much longer. If Freenode stored every message ever sent on Freenode that would be a nightmare.
Also, 'only if you're a nerd' is very silly. We're talking about this in the context of open source software. Everyone that is capable of non-trivially contributing to open source software is more than capable of operating an IRC client.
In fact, if you can't work out IRC then you're almost certainly too silly to be a programmer.
>Only if you're a nerd. Took me 5 minutes to get started with Slack for our company and managing it is a piece of cake.
Slack requires you to make an account on their website, a new account for every Slack group. IRC you can just join - pick a nickname and type the server's address and you're in.
IRC is completely trivially easy to use, Slack is not.
Setting up an e-mail address and a password is not an incredibly complex task. I have 3 seperate slack groups that are set up just for friends to chat.
Besides which, on most IRC servers, you're going to be using NickServ anyway, which is more complex a flow than setting up a user on Slack.
> What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc.
Okay, to me that is the same thing as 'persistent sessions', but without belaboring the point... can IRC do those things? Right, it depends on the server and client. What servers and clients can? I think it's pretty rare, if it exists.
If your answer is "well, IRC _could_ do that, if only more reosurces were invested in it to make it so", okay, but so what?
You're missing the point. This subthread is not about what IRC does do, it's about whether a chat protocol with support for persistent sessions, search, etc. can still be simple.
Maybe actually read the thread next time? So don't "so what?" me. This isn't about whether IRC can do those things.
Okay, good luck convincing people not to use slack because some hypothetical thing that doesn't exist could have the features they want, while being simpler than Slack and open source. That's your point?
Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2].
>>Search
You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features.
>>Session persistence
>No, nobody wants this.
Really? Are you sure?
> The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.
Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features.
>>> Web Client
IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about.
>IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.
Honestly, I might sound ignorant, but I've never ever heard of DCC file transfer. And matrix has implemented E2E encryption in some of their clients(all the major ones), and implementing them in the rest is a priority. I don't ever thing IRC will have this. I'd be glad if I was wrong.
Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about.
One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to?
Or do you want to ignore them so that they continue using a closed messenger and wonder why they're dominating the mindshare today?
Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.
>Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2].
What a load of crap. Emojis are simply sequences of Unicode code points. IRC supports UTF-8. A client with a button that brings up a big list of emoji is trivial to build.
>You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features.
That's irrelevant. You claimed that the simplicity of the IRC protocol was something unobtainable with those features. That's what I am disputing.
>Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features.
It's precisely about whether it's possible. You claimed that simple protocols for chat were not compatible with the features you listed.
>IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about.
I agree that IRC was never intended to be run in a browser and doesn't run in a browser well. But that is irrelevant.
>Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about.
Nobody is fucking boasting about anything. The point is that all of what you mention is easily possible with a simple protocol. "We should all use slack because simple standardised protocols can't do X, Y and Z" is FUD.
IRC has really complicated features like file transfer. So I don't think that IRC is being held back by an inability to implement things that require a complex protocol anyway. But even if it were, what you mention does not require one.
>One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to?
What are you talking about? I haven't said anything of the sort.
>Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.
Very, very few OSS projects have moved to slack. The vast, vast majority use mailing lists, forums, IRC if they use anything other than GitHub. Most people just use GitHub issues and email, not even mailing lists but plain email.
>I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.
The vast majority of this thread, as I see it, is the opposite: bashing IRC, a protocol that has been successful for a long time, is open, is inherently distributed and which there are many clients on many platforms for, while going 'look at how awesome [thing nobody uses] is!!'
Also the majority of IRC users aren't using freenode and the use of IRC by OSS is a tiny portion of the total use of IRC.
The point was it isn't built, where as there's auto completion support for emojis which wouldn't even need that "trivial" software. That's in the matrix's sdk. If it's so trivial, please, build for the IRC community. I use hexchat on my desktop and weechat on the server. Would you mind building me one if it is trivial?
> That's irrelevant. You claimed that the simplicity of the IRC protocol was something unobtainable with those features. That's what I am disputing.
Fine, I concede. But I'm surprised you're still going for this. I tried out a bunch of different IRC applications and couldn't find search in any. Oh well.
> It's precisely about whether it's possible. You claimed that simple protocols for chat were not compatible with the features you listed.
My argument was about the ecosystem and the applications and the contributors worked on those applications. You can extend any protocol to worked with other servers and your own extensions to work with your own version of the server code.
If IRC protocol is so amazing, then do you have a reason why it is constantly changed? I've seen it adopted to XMPP, Jabber and others. No sane person today will use the default IRC protocol in an application they intend to keep proprietary.
Discussing what's possible is a waste of time because any feature can be built given time and effort. The point is how easy and how maintainable/stable. More importantly, is it available now?
>I agree that IRC was never intended to be run in a browser and doesn't run in a browser well. But that is irrelevant.
I don't understand your logic. Why isn't something running well in a browser irrelevant? Do you expect everyone to use the command line or native applications all the time?
> "We should all use slack because simple standardised protocols can't do X, Y and Z" is FUD.
Huh. Well I wonder why there are sizable OSS communities moving to Slack. What's your take on this?
> So I don't think that IRC is being held back by an inability to implement things
Then why aren't we seeing the features that are in Slack in any IRC client? It's obvious people want the features in slack. Session persistence is an important feature for people in most OSS projects I've seen using slack.
> What are you talking about? I haven't said anything of the sort.
Oh come on. Your response to many of my points was basically 'it's possible', but not about if it is available today. If I were a non-technical user, what should I do if I want those features? I would just move to slack if there's nothing better than IRC out there.
>Very, very few OSS projects have moved to slack
It's true that many OSS projects didn't move to slack, but that's just because of inertia. Maybe we just look at different OSS projects, but many of what I see use slack, and the numbers aren't going down. Slack itself talked about how there are lots of OSS projects choosing slack and it's straining them .
Here's an article about OSS usage of slack[1]. Note how OSS projects are trying to mimic slack, not IRC. There's a reason for that, and you're conveniently ignoring that. Here's a discussion where you can see many people talking about the shortcomings of slack and why how IRC is failing them.[2]
There are bunch which I personally use, like Monero and Golem project. The problem is that the total number is rapidly increasing.
>a protocol that has been successful for a long time, is open, is inherently distributed and which there are many clients on many platforms for, while going 'look at how awesome [thing nobody uses] is!!'
No one is arguing about it's openness or success in the past. Just that it's time to move on.
>Also the majority of IRC users aren't using freenode and the use of IRC by OSS is a tiny portion of the total use of IRC.
IRC is in use for a very, very long time. No doubt. But you must be joking if you compare that you use of slack. There are so many people and companies (who could've used IRC by hosting it themselves) that it eclipses the use of IRC.
Slack is a widely used product, but its use is tiny compared to IRC. IRC isn't just tech people, it's very widely used by a really huge, diverse range of people.
Your original comment said 'the days of simplistic IRC protocols are gone' and then you gave a bunch of features with the implication that simple protocols can't handle those features.
I simply explained why those features are absolutely implementable over simple protocols, and also why IRC isn't actually a simple protocol - DCC is an example of something not at all simple in IRC.
I didn't say that IRC itself, in its current incarnation, solves those problems.
Ultimately you're basically saying 'I want a couple of features and because slack provides them, I'm going to justify my use of slack by comparing slack to the least featureful chat thing out there: IRC'. IRC's strengths aren't its features, it's its openness, familiarity, hackability, conceptual simplicity and community control. In fact, the things people that like IRC dislike most about it are the few parts that aren't open, hackable, simple or controlled by the community.
I don't particularly like IRC as a protocol. Maybe its time has come, maybe the replacement will be called 'IRCv3' or 'IRCv4' or called something else. Whether that replacement is called 'IRC' is not important. What is important is that it remains open (in spirit and in practice), hackable, simple and controlled by the community. Slack replaces a distributed, network-failure-proof system (IRC) with a centralised, corporate-controlled, paid, closed, proprietary solution. That's the worst possible collection of properties. Yeah you can search messages, yes it has a nice user interface, but that's about it.
>The point was it isn't built, where as there's auto completion support for emojis which wouldn't even need that "trivial" software. That's in the matrix's sdk. If it's so trivial, please, build for the IRC community. I use hexchat on my desktop and weechat on the server. Would you mind building me one if it is trivial?
I can't tell if this is a joke. This is literally:
1. map names to emojis
2. autocompleting input field on those names
3. append a couple of bytes to a string
This is 100% purely a user interface feature, it has nothing at all to do with the server or the protocol. You could implement this for literally any chat client that supported UTF-8 quite easily.
> it's very widely used by a really huge, diverse range of people.
Well you must be around cooler people than I am. Today, if someone wants to start a group chat with persistence (I'm surprised you seem to think this is useless), without having to bother with setting up their own server, IRC will not be on that list. But there is a large group that wants this, and its increasing, because people don't want to bother with a bouncer.
> Your original comment said 'the days of simplistic IRC protocols are gone' and then you gave a bunch of features with the implication that simple protocols can't handle those features.
This is a bit similar to FORTRAN's situation. FORTRAN can still do the things C++ can still do, but you don't see people using FORTRAN. IRC is a simple protocol and is simple, until it has it be used for increasingly complex features and also being adopted for the web requires all sorts of proxies and workarounds.
> I didn't say that IRC itself, in its current incarnation, solves those problems.
What are you saying then? You said people can use IRC now for all the features I talked about, but then now you changed your stance.
Then what solves those problems? I think Matrix solves those problems, so what do you think is a better alternative? Does it have a community comparable to matrix? Say so and I will switch right now. The guys working being matrix know what they're doing. HTTP transport isn't the fastest, but it is simple to implement for a web developer. And with more and more people preferring in-browser clients, I saw HTTP as a good choice.
> Ultimately you're basically saying 'I want a couple of features and because slack provides them, I'm going to justify my use of slack by comparing slack to the least featureful chat thing out there: IRC'. IRC's strengths aren't its features, it's its openness, familiarity, hackability, conceptual simplicity and community control. In fact, the things people that like IRC dislike most about it are the few parts that aren't open, hackable, simple or controlled by the community.
Are you aware of what my first comment you replied to was about? I was replying to someone talking about how Matrix is a 'bad protocol for business', further saying:
>I don't think you're very familiar with chat protocols if you think it's even remotely suitable as a replacement for IRC.
I never recommended slack. Completely against that actually, and I'm rooting for matrix.
> I don't particularly like IRC as a protocol. Maybe its time has come, maybe the replacement will be called 'IRCv3' or 'IRCv4' or called something else. Whether that replacement is called 'IRC' is not important. What is important is that it remains open (in spirit and in practice), hackable, simple and controlled by the community. Slack replaces a distributed, network-failure-proof system (IRC) with a centralised, corporate-controlled, paid, closed, proprietary solution. That's the worst possible collection of properties. Yeah you can search messages, yes it has a nice user interface, but that's about it.
Holy cow. I've been linking to matrix and Riot links, how did you still think I'm talking about slack? I was talking about how slack is getting the mindshare of OSS communities and that's not good.
>I can't tell if this is a joke.
No I assure you it's not. You linked to a single web client. That's not the same support for emoji's as matrix's.Those are emocodes, and on the big list of supporting clients here[1], I see only IRCCloud (which is the same web client you linked me to) implementing it. No other IRC clients does this.
> This is 100% purely a user interface feature
That's why I listed the clients I use - Hexchat and weechat. Please share the easy code that can add those features to them. While you're at it, licensing it with a FSF approved license would be much appreciated.
>Well you must be around cooler people than I am. Today, if someone wants to start a group chat with persistence (I'm surprised you seem to think this is useless), without having to bother with setting up their own server, IRC will not be on that list. But there is a large group that wants this, and its increasing, because people don't want to bother with a bouncer.
I don't care what you use personally. The reality is that many hundreds of thousands of people use IRC frequently. Communities all over the world use IRC. Most of them are non-technical. Most have never heard of Matrix, or Riot, and certainly have no interest in using Slack.
>This is a bit similar to FORTRAN's situation. FORTRAN can still do the things C++ can still do, but you don't see people using FORTRAN. IRC is a simple protocol and is simple, until it has it be used for increasingly complex features and also being adopted for the web requires all sorts of proxies and workarounds.
No, it's nothing at all like Fortran. That's a silly comparison.
>What are you saying then? You said people can use IRC now for all the features I talked about, but then now you changed your stance.
No I didn't. I never said that IRC could do all those things today. Are you even reading my comments?
>Then what solves those problems? I think Matrix solves those problems, so what do you think is a better alternative? Does it have a community comparable to matrix? Say so and I will switch right now. The guys working being matrix know what they're doing. HTTP transport isn't the fastest, but it is simple to implement for a web developer. And with more and more people preferring in-browser clients, I saw HTTP as a good choice.
Again, you're missing my point by a country mile. If you had said "IRC doesn't currently support this" I would agree with you. But you didn't. You said that simple protocols could never support these features. You said that the days of simple chat protocols are over. And quite frankly, that's rubbish. That's all I am saying, all I have ever said. Stop pretending that I'm saying IRC has all the features you are asking for. I am saying that you can implement those features in a simple way on top of a simple protocol. That is all.
>Holy cow. I've been linking to matrix and Riot links, how did you still think I'm talking about slack? I was talking about how slack is getting the mindshare of OSS communities and that's not good.
No you've just asked me repeatedly and for no good reason to show you how IRC does all the things that I've repeatedly said it does not do. I don't know why you're incapable of understanding the difference between "IRC has features X, Y and Z" and "it is possible to implement features X, Y and Z on top of simple protocols, so no the days of simple protocols are not over". But you do seem to be incapable of understanding that, as it's about the fifth time I've said it.
>No I assure you it's not. You linked to a single web client. That's not the same support for emoji's as matrix's.Those are emocodes, and on the big list of supporting clients here[1], I see only IRCCloud (which is the same web client you linked me to) implementing it. No other IRC clients does this.
You can use shorthand emocodes (with autocomplete!) to send them and they’ll be converted to unicode so anyone using another IRC client that supports emoji can enjoy your graphical exuberances.
You could at least read the link. You type them as emocodes, which are mapped to the actual Unicode emoji. All that is sent over the wire is normal Unicode emoji. That is why I'm saying that this is a purely UI issue.
This is what emoji are. They are Unicode grapheme clusters formed from a group of Unicode code points. That's the implementation, and the interface is, on both Slack and IRCcloud and everywhere else I've seen them, either a giant grid of emoji to pick from, or emocodes :simple_smile:, usually both.
>That's why I listed the clients I use - Hexchat and weechat. Please share the easy code that can add those features to them. While you're at it, licensing it with a FSF approved license would be much appreciated.
>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 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.
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 :)
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.
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.
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.
- 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.)
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.
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.
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?
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.
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 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...
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.
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.
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.
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).
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.
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.
"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.
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.)
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:
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.
> 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...
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.
> 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?
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.
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.
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.
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.
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?
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.
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).
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)
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.
Issue #2, that slack is based on synchronous communication, is something that is always ignored. Sometimes I log in to slack and see a conversation that I want to add something to, but it is 4 hours old with 50+ new messages on varying topics. Even with Slack's new threaded messages it is hard to evolve the conversation after all the synchronous folks have moved on to other topics.
> Chatting is having to write the same thing a million times.
If you find yourself repeating the same thing a lot in chat, it would be a good idea to document it somewhere and just paste a link. With a link to the relevant documentation, a lot of people will just do the rest of the legwork on their own, and will now be able to quickly reference it going forward, and hopefully bug you less in chat (you can always be explicit and refuse to answer people, asking them to read the docs instead).
If you find you're pasting too many links too frequently, then it's time to make an FAQ with those links, and start linking to that.
Fix your group's culture. Document things. If people refuse to document things, then do it for them and shove your docs in their face. Do it until they write the documentation themselves.
It's also the most important thing. If your culture is bad, changing what tool you use isn't going to fix everything. You're just going to have a new tool everyone uses poorly.
What you're looking for is email. Multi-user chat simulates a real life conversation, and in real conversations it's also awkward to say "hey so going back to what we were talking about 15 minutes ago..." after the conversation has moved on.
No, email is terrible. There's no history. You can't "scroll up" to see what people were talking about. You can't link to another specific email to reference it (yes, there's archive services, but then you have to go dig through an archive to try to find a horridly formatted email to link to, which is completely separate from the normal consumption platform).
I actually argued here recently that email was hard to switch away from because of the history. You can keep your emails forever. I have emails from 2007 sitting in my inbox. And if I want to keep them, I can download them with IMAP or POP. If I send an email to five people and they remember to hit "reply all", well that's a conversation, isn't it? And if I need to show someone an email they weren't party to originally, I can forward it to them.
That puts the onus on every single person to maintain the history of the project. Lots of people delete mail (not me, but lots of people). Also, you can't retain history of what was sent before you joined. Also, emailing individual documents means people can't research by themselves.
I mean, email isn't meant to be a document repository. Slack (or other chat) is great for immediate conversations with many people. Email is great for slower conversations with a more limited number of people. A wiki is great for a very slow conversation. An actual document repository is great to be able to link to when using any of the other conversation methods.
Just because Slack isn't good at slow conversations doesn't mean it's bad. Just because email is bad at including people who joined after the fact doesn't mean it's bad. Those aren't their strengths, and that's fine. They still serve their own purpose just fine.
I never used Slack, but in IRC I'd quote what the user said (a format like "<user> message", optionally with a time) if it's really relevant; and in Telegram it's a simple matter to rightclick and reply (which allows people to click/tap it to jump back to context) which I feel much less bad about.
If I really wanted to bring up a topic that had passed, I would break out to a separate channel and invite the relevant people and drop a note in the main channel with a "bringing things back up about $conversation in #newchannel". This works better than writing to threads in my experience.
This may be a shortcoming of the UI, more than anything else. There's definitely room for improvement here as I often miss updates to threaded conversations even as I'm looking for them.
I think they could make threads work with some simple changes:
* Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread.
* Allow the user to collapse a thread so they no longer see it in-line.
* Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan).
* Allow the user to navigate between threads using only their keyboard.
As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).
Chats (of whatever type) have never been a good solution for this, that's why mailing lists exist. Improvements there would be nice, sure, but are unlikely to come from a chat service. They just solve different problems.
This is more of a usage problem that anything else. If your organization makes decisions based on synchronous communications, without stopping to notice who wasn't included and get their input before final decisions are made, that is a cultural problem, not a tooling problem.
Good points but the bigger problem for me is the lack of an archive.
You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.
If you have a nonprofit for your project, you can also get on their nonprofit plan. At https://hackclub.com we get unlimited archival without paying for this reason.
I completely agree with this. I'm part of a group that's trying to help people in the local community learn programming and we're using Slack to chat outside of any scheduled sessions. We're at over 1000 members in Slack now and are seeing messages disappear before the two-week mark. We don't collect any money from our members and Slack's pricing model makes it unfeasible for us. At this point, Slack's search feature is hit or miss when searching for anything over a week old.
With respect - you are reading something that wasn't necessarily there, the person you were responding to said nothing about expecting Slack to change their business model.
That still doesn't make Slack an appropriate choice for open source. Even if the project didn't mind paying, Slack's business model is wholly incompatible with the traffic that an open source project would expect (lots and lots of not very active users)
Just a note: if you go from free to paid, you can recover those lost messages. They're never actually deleted, you just can't view messages after the 10k limit in the free version.
Wow, that is kind of evil. I could understand if Slack kept, say, the last 20k or 50k and only showed the most recent 10k. For them to store all the messages indefinitely for all free servers means that they are incurring the same storage costs whether the server is free or paid. Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?
They might be shunted to a disk somewhere and removed from search indices while on the free plan, reducing their costs but allowing them to recover things after.
> Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?
Given that the cost to you is 0, what cost to them is required for it to be justified to you?
It seems odd that providing a free but limited service is evil, based only on it being slightly more expensive to give you an even better service for free.
I doubt it's a bandwidth issue. It's probably that they have to keep more servers/servers with more ram up to index all the messages. Keeping something on a disk that never gets read is far less expensive than keeping it in RAM and indexed so that it can be quickly and easily searched.
Ok, well the alternative is no free version. Yeesh, people are so entitled. They're trying to give you a mostly full featured version of their software in hopes that you'll pay them someday.
It's not evil nor is it about the bandwidth costs, it's just business. It's how they get you to spend money on a freemium product after you reach a certain cap. They've determined that you should pay if you're hitting the 10k messages limit.
Third choice: Slack exists, but doesn't hold your data hostage until you pay. I mean, on my list of things I care about ideologically, this is lower than my concern for warm gin and my dislike of sweatpants. It's legal and totally within their right, but it's a crappy way to behave.
Forums. I don't know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.
> Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.
WTF?
How is it even remotely sane to provide a user interface instead of an API/protocol?
I don't care to learn your forum's user interface, and I don't care to poll your forum for new content. I have a mail user agent that's configured to fit my needs and that I know well how to operate, and that's where all the mailing lists that I am subscribed to push their new content into this one unified interface for me to interact with them. Web forums for the most part are just a pile of broken usability.
> How is it even remotely sane to provide a user interface instead of an API/protocol?
It's the way of the world. 20 years ago we had NNTP, POP, and IMAP, and you could read them all with Gnus, customized with finely-tuned filtering and killfiles. But it's hard to "unlock value" from these things, so then there were ad-strewn forums, and now SaaS abominations, because how dare you not change your mail client when its developer thinks you should?
Yeah, sure, provide as many user interfaces as you like, just not instead of an API/protocol. The whole point is that everyone can choose the UI they prefer, or build their own if they like.
The forums I visited all died, but none replaced them (and I kinda miss forums). There are still some active forums that I know of, like Factorio's (a modern game, not one from 2001 when forums were still hot). They have a subreddit which is active as well (though less), but the forum format still works fine for them.
New services replaced many things that forums were used for, but not all.
Reddit IS a forum platform. Anyone who wants to create a subreddit can do exactly that. Reddit did not replace forums, just the software that they run on.
Reddit is distinctly different from a typical forum due to how heavily it weighs time and popularity. A normal forum can have multiple threads of thought active at the same time without interference, and sometimes a thread can live for a long, long time. There's no need for a thread to be super popular to survive, a thread can literally live off of two users.
On reddit, if the time is not right, the discussion will not be had and ends up in oblivion.
They're generally fucking terrible in terms of UI. I much prefer Google Groups over older forums. Discourse is even better but there's no easy way to setup a forum for free. The last time I looked into it it would be roughly $10 a month for a DigitalOcean droplet to run a small forum, but that was more than I wanted to spend myself. And accepting money is a non-zero amount of work too.
Probably the main reason why Slack – and Gitter, and IRC too still – are widely used by open source projects is that they're free, financially, and mostly free in terms of maintenance.
It's such a disappointment that social networks killed forums! The experience is so much poorer now. There's insane amount of fragmentation (everybody wants to run their own thing because likes), no search, no discoverability, no ways to conveniently track the discussions.
But the main huge drawback, from my point of view, is that non-anonymous model of conversation means people more inclined to judge you from looking at your profile and not from the specific local reputation, which was a thing with forums.
Forums. I don't know why the internet got tired of them
I have recently been participating on Reddit and I still like HN, but I am spending less time of late on another forum I still belong to. For me, part of the answer is that forums are heavily influenced by moderators and most of them are not anywhere near as good as what you see on HN. So, if you have personal friction with the mods, good luck with that!
The internet is this awesome opportunity to rub elbows with people around the world. Then the admin structure very often gets you stuck in "I shot the sheriff" * hell, where no matter what you fucking do, some asshole who doesn't like you and is in charge rides your goddamn case and deletes your shit for bs reasons and so on.
I don't know how to solve this problem. Most forums don't seem to be able to get it right.
* This is an old song where the plot is that the sheriff was making his life unbearable and there was no other way out, so he finally shoots him.
> the [forum] admin structure very often gets you stuck in "I shot the sheriff" * hell, where no matter what you fucking do, some asshole who doesn't like you and is in charge rides your goddamn case and deletes your shit for bs reasons and so on.
That's why I preferred Usenet over forums. All filtering is done by the client and is under your sole control (outside of moderated groups).
Probably because you would need to remember what the addresses were, what your credentials were (for each forum you joined) in order to participate. Also, administrators could disrupt discussions any time they wanted or restrict people from posting in the same vein.
Usenet, on the other hand, didn't have these problems, though it pretty much ended up the same way.
I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments.
Synchronous communication, indeed, is bad for the main communication channel. However, as a secondary communication channel, it can serve important needs.
When people are looking not to just get a single issue resolved, but to form a community, this community is often based on informal communication and emotions. Seeing the same people in the member list every day, exchanging little inside jokes, getting to know individual members of the community on a personal basis — this is something completely irrelevant for the user of the open-source product, but can be an important emotional component that motivates people to stay in the community and continue to put in effort into the project.
And, of course, a synchronous channel, where you can get more lax on moderation, is a much more suitable tool for this purpose.
> I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments.
Is this a problem?
Ostensibly one should hope to be able to communicate online in the same
manner that one does offline: without paying an intermediary
Further, if the 'natural trend' of economics is towards commoditization
of products, why then are we abandoning those things which facillitated decentralization in order to support another entities profit motives?
> Further, if the 'natural trend' of economics is towards commoditization of products, why then are we abandoning those things which facillitated decentralization in order to support another entities profit motives?
your point fails to address this point; similarly 'better' has varying metrics.
> Seeing the same people in the member list every day, exchanging little inside jokes
...about what other people are writing in the main communication channel, creating precedents about what should be discussed with "individual members of the community on a personal basis" and deciding the content that should be written on the main channel for the benefit of outsiders asleep in other time zones, ...
How can you generally prevent a subgroup "deciding the content that should be written on the main channel for the benefit of outsiders asleep in other time zones" even in an 'asynchronous' communication channel? There's nothing stopping them from responding to each other quickly enough to effectively communicate 'synchronously'.
I've intended to reply to communications before only to discover that someone else replied first while I was asleep in my other time zone.
Free software and open source software are synonyms. Even Stallman agrees on this. He cares about the use of the terms because of their other implications.
Ok, that's interesting. My impression from watching his talks is that he does not consider the two ideas as synonymous, in that a software can technically be closed-source but have licensing that is libre-free so that it can be used by whomever however. But perhaps I got it wrong.
It is the other way around: just because the source is available free of charge does not make the software free as in freedom. For example, there are licenses that prohibit you from running the software for commercial use even though you have access to the source. This would not fit the FSF's definition of free software because the user should have the right to use the software as they wish.
Those licenses also aren't open source. 'Open source' doesn't mean 'you can view the source', it means you can view, run, compile, modify and distribute the source, and distribute modified copies.
I am the lead developer of Zulip (zulip.org), an open source Slack alternative built around a better threading model.
I strongly agree with both criticisms of using Slack for open source, and I am impressed that Dave wrote this post, given that some of those criticisms apply to his own product.
However, I think the proposed solution of relying on mailing lists, issue trackers, and forums is the wrong solution.
Support for synchronous communication is not the problem with using Slack/IRC/etc. for having discussions in open source organizations. After all, even with "asynchronous" media like email, bug trackers, or forums, often people reply basically immediately (within minutes or maybe hours), just like you can in chat, and it might be hours or days before everyone has a chance to see the conversation and respond.
The problem is that the messages have no organizational structure beyond the channel. In Slack and friends, there's no easy way to see what _actual conversations_ happened while you were away, and it's really hard for a channel to discuss multiple things, so conversations either die or become hard to read when someone starts talking about something else. Combined, this means you have to (1) read _everything_ in order to know what happened and (2) be continuously online in order to participate effectively. This may not matter if your community is super low-traffic, but if you have hundreds or thousands of messages being sent daily, this effectively excludes everyone who doesn't have a LOT of time to spend on the chat community.
It doesn't have to be this way. Nothing prevents creating group chat software that handles both synchronous and asynchronous communication well. In particular, Zulip is built around a simple threading model that solves both of these problems. In our own chat.zulip.org community, people constantly contribute valuable commentary or feedback to a thread that started a few days and hundreds of messages ago. And I can come back from a week's vacation, and skim the 5000 messages that might have happened while I was gone, and easily reply to all the threads where I have something to add.
(As a sidenote, it's easy to post permanent links to conversations in Zulip, which we use regularly in the Zulip issue tracker to point to the original discussion that led to a given proposal. But the important problem isn’t the link part, it’s separating the conversations from each other: without something like Zulip's threading, reading chat logs can be a slog).
It might be more useful to speak in general terms than call out Slack in particular. The concerns expressed here aren't limited to Slack (despite the link-baity title), but any form of communication that:
(a) Can't be referenced or linked from the Web, and
(b) Is a form of synchronous communication
The same factors, BTW, apply equally to in-person discussions held at open source conferences. I wonder what the author thinks of the value of those insofar as "open source communications" are concerned.
Except with both Slack and Gitter (not sure about others) you can link to specific messages. Sure you still need membership to view the content (a serious downside), but saying you can't link at all is disingenuous.
With Slack, at least, channel history is truncated for free accounts; so it's quite possible that a specific conversation could become practically inaccessible after a while.
You are able to export your entire public history, regardless of the status of your account. I was able to do this to rescue the chat history for Hyperledger[0][1] before we moved to Rocket.Chat.
Slack is technically inept as well. Earlier today I was modifying a robot design in Fusion 360. Huge beast of a model with too many parts to bother counting. Fusion was consuming nearly 900MB of memory (and I am rounding up here). Which is unsurprising for a CAD package editing a large model.
Meanwhile my mostly idle Slack with perhaps a couple hundred users across four teams was consuming 1.3GB of memory.
Not to put too fine a point on it: it is a piece of shit software.
It seems to me that Slack could position itself to provide free and open access to certain types of communities like open source projects, charities, etc. Enable the "pro" features so long as the community follows the rules.
The value of synchronous communication is very real and it should not be precluded, but the points are totally valid. Slack is a closed-garden and it does not contribute to the global conversation if the access and historical record is controlled from within.
This applies to Freenode as much as it applies to Slack. If freenode disappears, people using its channels for foss will have similar issues and inconvenience as if Slack/Discord disappear and in both cases, it's recoverable.
Nobody changes clients if Slack disappears and is replaced by another webapp. It's all in browser.
The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.
I say this as someone who's used IRC a crapton and is a strong advocate for open protocols (and for more than just ideological reasons): Realistically, if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions, which is happening today anyway. A protocol needs users.
The only thing IRC has got going for it is federation and openness. It's not easily extensible, it's not secure, it can't benefit from most of the advances we've made in comms and protocols since the 90s, and there isn't even a common format for your messaging history - most clients just use text logs!
If you want to advance the state of comms and ensure humans are using open protocols to communicate rather than walled gardens, you first have to acknowledge these flaws and needs. Propping up IRC as something it's not doesn't do anyone any favours.
> Nobody changes clients if Slack disappears and is replaced by another webapp. It's all in browser.
You aren't serious, are you? Because the new client runs on the same virtual machine, you are not changing clients? That does not really make sense to you, does it?
> The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.
(1) I haven't ever heard of a computer changing its operating system from MacOS to Windows because anyone but the owner of that computer decided to make that switch. How would that happen?
If Freenode disappears, people will join Debian over on OFTC. I'm not sure if Mozilla and GNU/FSF use Freenode or run their own infrastructure but if the former, then they may set up their own network(s).
Other IRC networks than Freenode and OFTC exist too.
As far as security goes, SSL is an option for client<->server connections. I hope that at this point it is default for server<->server connections. What else are you expecting for security?
SSL is not required and it's certainly not default in most clients.
IRC won't survive the loss of Freenode. With Quakenet dying off (its userbase went from ~65k in 2013 to 23k today), Freenode is the last central bastion that keeps the protocol in people's minds.
FOSS projects today are migrating off IRC, onto Slack and Discord instead. This is why you have an article here talking about it and it's not the first one. If Freenode disappeared, this would accelerate massively. The projects won't bother going to another network because the topic of "Where do we go now?" is going to be asked and in most cases is going to be answered with "Well, we wanted to move to Slack/Discord anyway...".
There will be a few projects left on OFTC, certainly. But they'll give up and go elsewhere eventually as well when they'll see their userbase shrinking 5-10x due to other projects migrating elsewhere and taking their users with them. They'll probably end up on Matrix.
If the UI changes, the client has effectively changed for the user. Otherwise you might as well argue that clients are all equivalent if they are running on the same OS.
>but the UI also changes when you go from a Mac IRC client to a Windows one
Only if you use clients that don't look the same.
> if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions
No supporting evidence that they would drop IRC if this happened. You must have missed the part about a network switch being literally a config change. Compare that to dropping irc which is all of your tooling.
>most clients just use text logs!
There is nothing wrong with a text log. Also, which common format is your browser storing your slack messages in?
Most of your complaints apply just as equally to chat inside of a web browser (other than the security issues).
>Propping up IRC as something it's not doesn't do anyone any favours
Tell me how my comment is incorrect. You literally change a config to change networks, that's it.
This is the point that I can't get anyone to see. So what if they provide history? They can take it away at any point too. So what have you accomplished?!
There is a lot of vendor lock in for git these days, everything from CI integration to git clients hard coded for github. We spent most of the 90's and 00's breaking vendor lock in and then forgot it was a thing.
I feel like more and more people are coming around to seeing the relevancy of distributed federated chat and breaking out of the walled gardens. My person money is on Matrix[0] taking off but I think the general theme of people pulling away from interesting their communication to corporations is a positive.
[0] matrix.org
Everyone should be using Matrix. Not just open source developers.
It's near feature parity with Slack and it's also one of the best IRC clients around. I used to run ERC in a tmux session just so I could stay connected and not lose messages. No more.
The ease of bridging is great. We've got a minecraft server bridge of all things; being liberated to actually have universal chat is the future for sure.
Yes, Matrix has great momentum. It is somewhat sad that XMPP is falling behind. There is no technical reason, why Matrix should be superior, but they are winning.
Similarly, the huge buzz over the past few weeks about Mastodon as a distributed/decentralized micro-blogging service has been positive. People starting to learn more about federation and decentralization. Good to see.
Tangentially, I don't get how developers on the one hand strive for private offices and no (physical) interruptions, but on the other want to communicate through chat channels.
Maybe these are different people altogether, and I'm just getting the wrong impression. But personally I prefer a little personal interaction over a long chat.
I don't have to drop (as much of) my mental state in order to communicate via chat. It's asynchronous, so I can finish typing out whatever I'm thinking about, or looking for whatever I'm trying to find, kick off a build, etc., and then turn my attention to the chat window and bang out whatever comes next in the conversation. Once written, I can switch right back to whatever I was doing - I type quickly, so it's usually only a few seconds of interruption. I can easily carry on a couple of extended chat conversations while simultaneously continuing to get my actual work done.
If someone wants to talk in person or via voice instead, my heart always sinks a little, because it means I have to drop whatever I was doing and give the conversation my full attention instead. Once we're done, I have to try to remember what I was thinking about before the distraction happened, get myself back up to speed...
This doesn't come up so frequently anymore, but it was very noticeable when I used to work remote. Some coworkers were happy with chat, and it was easy to communicate with them; with others, it'd be like twenty seconds of productive conversation, then "can we please just have a call about this" and, oh god, that's it for getting anything done for the next 40 minutes.
I find the same to be true on (small) Slack (or similar) channels. Which is funny given that Slack being synchronous is one of the two main points of the link.
> I don't get how developers on the one hand strive for private offices and no (physical) interruptions, but on the other want to communicate through chat channels.
Chats are much less interrupting. When someone walks in, you have to look at them (it's rude to keep typing and look at your screen), your brain starts to assess who it is and their mood and pulls into an appropriate facial expression, and you have to start listening because your audio buffer is much more volatile than your chat client's message log. Even if you're just finishing the "hope to hear from you soon" of an email, you typically have to acknowledge someone's presence and already detect who it is (someone two levels above your paygrade, you'd not want to keep waiting, while you would let a peer wait for that email to get sent out). I don't know how much of that subconscious activity really interrupts flow, but I notice it's annoying.
For chat, group messages don't trigger notifications and they just get looked at when I have a second. If someone needs me specifically, they'll mention me or send a private message. In those cases, I will notice the notification but will (depending on how concentrated I am) either not process it beyond "there's something" or not beyond judging whether it's urgent (based on the first five words, or whatever makes it into the notification). I catch myself thinking "wait, someone sent me something, I totally forgot" and it turns out there are no unread chats. What must have happened is that I alt-tabbed back and forth to make the unread-message counter go away (and give them the double tickmark to indicate I saw it) because what they sent did not need further processing (something like a final "okay"). That did not interrupt flow.
---
On top of that, what others have said: external people (at clients', at home, whatever) can follow chats along; you can do stuff in between messages; you can pick your nose during conversations; and you can have an 80 second meeting between five people.
I think an uninterrupted private office and "instant" messaging are not mutually exclusive things.
Personally I've noticed people tend to take a longer time saying something in chat than they would in person. And if I have to wait for a reply I'll probably start doing something else, potentially making the chat conversation go even slower.
I have little experience with group chats, in my limited exposure to them they tended to be more focussed on fun than productivity.
I also seem to be one of the few people that can quickly context switch between a conversation and actual work.
Easier to compose an eloquent and effective reply in chat than in person. Time to think over the messages etc before responding. Can pick my nose while talking to you etc.
I'm with you on the personal interaction but I think people like slack/email/IM because it allows them to be in control of their communication. If someone drops by your office/cube, it snaps you out of your flow and you have to work to pick it up again. With the online forms of communication, you can turn them off and be guaranteed some distraction free coding time.
For me it's probably selfishness. I'm an infinite inboxer, who prefers synchronous communication (if any). If I need something, I'm going to walk up or call, and yet my door stays closed. So the two preferences aren't mutually exclusive, but in my experience these generally ARE different people altogether.
Mattermost is an excellent open-source Slack clone. It would be interesting if someone could add a feature to publicly host chat logs for indexing by public search engines.
Many of these complaints are just as valid for any business or organization trying to function as a modern software-based org in this day and age.
You have remote workers, flexible schedules, people traveling everywhere, all doing knowledge work that depends upon sustained focus and reaching a flow state. All of which Slack and synchronous chat detract from.
Slack just happens to be easy and convenient, so orgs end up using it by default.
I'm not sure about others, but I very much dislike the idea of multiple channels (the way Slack, Discord, etc. do it) on one server/chat. It feels messy and half the time conversation doesn't fit neatly into any of the choices. Honestly, I can't think of something I'd rather use over Telegram here -- if I need multiple discussions it's just like IRC: I make a different chat for each one, rather than having to awkwardly subdivide my main chat. It also has the advantage (even more so than IRC) that all users exist on the same server, so you never have to deal with the awkward per-group account system (Slack) or server-only messaging (Discord) or having to switch rizon->freenode->mozilla IRC. WhatsApp would probably be just as good if not for publicly identifying users by phone number, what it really comes down to for me is just having a normal chat app. Maybe even plain old Skype would be nice if it wasn't proprietary. I don't need you to innovate the way my chat system works with fancy new methods of grouping users. I don't mind the bells and whistles (voice/video chat, bots, stickers/emoji, ...) as long as it doesn't get in the way of me having a conversation. But for fuck's sake don't try to cut off every group from everyone else like Discord/Slack.
It's much worse. A wiki still consists of pages of documents, even if they're kind of improvisational and perhaps incomplete. A chat log is just a log of people chatting, with all the free-wheeling and meandering conversational style that entails.
Forums fall apart when you're trying to do things like realtime debugging. With a chat client, I can leave a window open in a corner and keep an eye on it while doing other things. With a forum, that becomes a game of hitting refresh every thirty seconds waiting for new messages.
I hear this a lot, in terms of older tools being considered obsolete.
Other than the natural human tendency towards novelty and the network effects, what, exactly, is obsolete about mailing lists or IRC?
What features are missing in IRC that Slack has for synchronous discussion? (I'll start: animated dancing pigs out of the box and the need to write/plug in your own archiver.)
What limitations do mailing lists impose on open source development that are not present in other tools?
To have all the features you get for free out of slack, you have to do a lot of work and maintenance to get out of IRC and mailing lists.
Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX. Google groups mostly fixes this because they're really just a forum that supports emails.
IRC is terrible because everyone has their own client, so you never actually know what someone will see when you post something. Post a link, - will it get auto-expanded? How will it look? Will it get auto-linked? If you @ someone, will they get notified? if so, how visibly?
IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.
Slack has mindshare, which leads to having a ton of integrations with other platforms, which just multiplies its effectiveness.
I 100% agree that I wish they offered a publicly visible option, so anyone can view without logging in. I also wish they natively supported self-registration.
I have to echo another commenter on here. If you want the best of all worlds, a forum is what you're looking for. Publicly visible, easily linkable, long form, asychronous communication. Whether that's google groups or something else is up to you.
Slack gets a lot worse once you want to start dealing with two teams using it. With most IRC clients, I can have connections to multiple servers running, and able to see at a glance everywhere that there's activity. With Slack/Discord/etc, that involves a frenzy of clicking as you look through each group of chats individually. I can lay things out how I want, move things around, etc. Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients instead of having to keep another web page open to another javascript-laden nightmare.
> Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients
Unfortunately, the Slack gateway implementation is subpar. In my experience, it will send me the last message I sent before I disconnected when I reconnect, but it won't send any of the other messages that were sent in the meantime. The other problem is that group chat only works over the IRC gateway, not the XMPP one (at least I could join it from my XMPP client, but I couldn't send any messages to it).
In contrast, the old XMPP server we used would just replay messages in group chat when you reconnected, so at least you wouldn't miss anything when you weren't connected.
> IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.
This part I really do find annoying about IRC. I use IRC by far the most but this still gets me. Even if you run it in a screen somewhere it's a hassle from a mobile device. There's solutions for all of it, but you have to string a series of things together to get to something just about every other option offers you out of the box. Unless you have a particular need for IRC or have used it for a while and know how to deal with it, the other options are more appealing to newcomers. Depending on how young your project or community is that can make all the difference.
> Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX.
Gmane actually works really well at addressing the problems you describe in terms history. Their NNTP gateway allowed me to download and search the git mailing list messages since 2009 in my email/news client.
> What limitations do mailing lists impose on open source development that are not present in other tools?
None, in my opinion. On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages — that is coherent enough to be highly useful when searching archives later.
> On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages
Newsgroups also have this structure and they have the advantage of easily doing an archive search (by being able to download part of or the entire message archive of a given group and using the search features of your mail/news client).
> Quoting is still a problem. Most answer above. Some below. Many nitpick in between.
One thing I've noticed on Hacker News, Slashdot, and even reddit is that if someone quotes the post they're responding to, they'll invariably post their response below it. And if they quote multiple parts of the parent post, they'll interleave their responses. I don't recall ever seeing a response where the quoted text is below it.
I've really never understood the rationale behind top-posting. It makes it much more difficult to understand the context of the response without having to jump between the original message and the response.
> Threading is easily broken. Especially if Outlook users are involved.
That's because Outlook does not follow the relevant RFCs in terms of maintaining a message through through the In-Reply-To and References headers.
> Formatting is an issue. There is no markdown or whatever for links.
Most GUI clients will make links clickable. There are also conventions such as using astericks, _underscores_, or /slashes/ for bolding, underlining, or italicizing text, but a lot of clients don't render them consistently, IME.
> Some people insist on line lengths and other stuff.
There is an RFC that adds format=flowed to the Content-Type header. Then every line that ends in a single whitespace character will be joined with the next line and wrapped at screen width instead of at the position of the CRLF characters. Clients that don't support it will still see the wrapped text.
The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.
Sure, there's lots of freely available alternatives, but even tiny (but non-zero) costs in time and money are the difference between widespread usage and relative non-use.
I setup Gitter on a GitHub repo for a project by clicking a button and accepting a pull request that Gitter auto-generated for me to add a link to the repo's Gitter channel in my project's README. That's the competition that every older tool is failing miserably to meet, let alone exceed.
> The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.
You are ignoring the costs that come from lock-in (inflated prices, lack of innovation) and migration in case the proprietary solution shuts down. That's the psychological tendency of humans that these companies exploit.
Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.
Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.
A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.
> Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.
That's not lock-in. Lock-in is when you are dependent on a (quasi-)monopoly, not just any potential migration cost.
> Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.
No, actually, they don't. The point, as above, is that it's not the sole decision of another party when a 'shut down' happens, that is, again, there is no monopoly. First of all, if you have free software running on your own machine, there is noone but you who can decide to just shut it down today, but also, in the long run, you can just take over maintenance of the software yourself, or you can buy/hire a software developer to do it for you, or you can get together with other users of the software to hire a developer.
Also, more generally, with regards to open interfaces/protocols rather than necessarily free software: No, email cannot be "shut down" because "the unpaid developers burn out". And changing my email client or server or hosting service does not necessitate everyone else I want to communicate with to do the same.
None of that guarantees that you can keep using things indefinitely at an arbitrarily low price, but that's besides the point: The price is determined by a market, and not by a (quasi-)monopoly.
> A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.
Well, yeah, those people are just clueless, if only because they confuse freedom with not paying for something. If you want to have something maintained, how about you pay for it? How does it make any sense to say that you prefer being forced to pay for something because you otherwise fear that it's not being maintained if you don't pay for it?
Also, none of this has anything to do with open protocols (which was the primary topic of this thread, kindof): Microsoft is being paid very well for maintaining Outlook and Exchange, which is both proprietary software. They still speak SMTP with the rest of the world, instead of forcing everyone to buy Outlook and Exchange to be able to communicate with their users.
What really needs to die is the view that old tools are bad tools. In my experience, the most useful tools I use (standard unix utilities, vim, emacs, lisp, etc) are the oldest ones while the newer ones are the ones I could most easily replace.
I personally prefer Gitter & other tools over Slack for open source communications. The Slack signup process can be a road block as it takes to many steps. To often I run into open source communities that require you to join their Slack channel for posting any questions (that may or may not be bugs in their software).
I really like Slack for a lot of things, but it's often a tool used incorrectly due to its popularity.
> Slack, et al, are based on synchronous communication, which discriminate against those who do not or can not take part of the conversation in real time. For example, real time chat discriminates against those who aren’t in the same time zone–you can’t participate fully in an open source project if all the discussion happens while you’re asleep.
Even if you are in the same time zone, real time chat assumes a privilege that you have the spare time–or an employer who doesn’t mind you being constantly distracted–to be virtually present in a chat room. Online chat clients are resource hogs, and presume the availability of a fast computer and ample, always on, internet connection, again raising the bar for participation.
It's quite amusing that the author takes his (valid) argument about the problems of closed, synchronous communication straight to the language of privilege, discrimination, and oppression.
There's no talk of 'oppression' anywhere in the article.
You understand that 'discriminate' and 'privilege' are regular words with regular definitions that were used by regular people for hundreds of years before you came along with your chip on your shoulder, right?
I can't believe that in 2017 we're still discussing what's wrong with our chat software. I have to wonder when we will finally see chat as a solved problem.
The OP isn't actually discussing chat as an unsolved problem. OP is arguing that chat is the wrong choice of solution to the problem of open source software project communication, because it's synchronous.
Or to abuse a metaphor, OP is arguing we need to use boats instead of cars to ship heavy things overseas, not that cars are an unsolved problem.
OP is arguing we should use boats for everything, including sending something across town. Realtime chat works a lot better for certain things, like troubleshooting, where having to wait around for a forum/email response may not be the best way of doing things.
I doubt Discourse will run on a $5 VPS. The last time I checked its crashes on 512MB RAM, needs at least 1GB just to start. Have the minimum requirements changed? 1GB minimum and 2GB is recommended by Discourse itself.
Discourse is also not easy to setup, its quite involved and complex and you need some Ruby and systems expertise. Infact I think Discourse only supports Docker installs. So you need to know Docker too.
Given the complexity you should be pretty comfortable with Ruby to run it with any amount of confidence. The hosted option seems much better than trying to run it yourself.
I did just run across a cloud provider with $5 VMs with 1 GB of RAM (somewhere), but the last time I checked it's at least $10 per month to host Discourse on DigitalOcean or similar.
As I posted on twitter[1], Slack is linkable. Not public, but if you can chat you see them. Gitter: public AND linkable. Async is a good argument; linkability is not.
Slack's UI is good. Not perfect, but it's quite usable compared to all the alternatives[2]. People always underestimate the value of good UI.
Slack doesn't have public links and an archive of posts, it's a stream behind a login, which might go away at any time on an active project. It's a terrible idea for anything other than ephemeral communications which don't need to be logged or kept. Re the UI, for a chat app it's fine, most conversations around an open-source project should not be held in a chat format however, but in a format that respects participants not being in the same time zone or having the same time pressures (that means an async format, not a linear chat).
If you want to have an open process (for discussions around proposals, bugs etc), you need an open, linkable, archivable format, ideally hosted somewhere you control. That means mailing lists or a public html server, not a private chat service which may or may not be around, which may delete data or change policies at any time. For this reason Github isn't great either, but at least it has public links and you could scrape the data if required.
Have you never replied to an old forum post and been accused of 'necromancy'?
Have you never been late to reply to an email chain or a thread on a mailing list or forum?
There's no clear line dividing asynchronous versus synchronous communication. Even phone calls can be (partially) asynchronous – "hold on, let me check" let alone "let me call you back in <some amount of time>".
And similarly, if a group of people are responding to each other quick enough, even using an 'asynchronous' medium, then they're basically communicating 'synchronously'.
> [2] I've been on IRC on and off since 1993. It's much worse.
So? There are services offering that, too. Linkability is easy to add to IRC as soon as you are using logging systems and modern bouncers such as IRCCloud or Quassel.
It's open source. It seems to solve the problems mentioned in the article (I mean, openly accessible — can link to a discussion & (soon) to a post in a chat channel. Both sync & async communication (both chat and traditional forum topics).
I'm actually just about to a-little-bit start promoting it. ... Ok so let me try to make you more interested in ED:
- Often, organizations setup a chat (e.g. Slack), a forum (e.g. Discourse) + use e.g. StackOverflow — but then they've split their community into three. However with EffectiveDiscussions (ED) you can gather everyone at one place.
- ED is looking to improve the quality of the discussions. For example, there's a novel voting system that solves (I hope) problems related to people downvoting-because-they-disagree, + a novel algorithm for finding the "best" comments (in threaded HN style topics). Plus some other improvements over HN & Reddit, see https://www.effectivediscussions.org/-32/how-hacker-news-can...
(As you might have guessed, I'm the one developing ED.)
A different take on solving the problem of asynchronous communication: JayPad is a simple web app which works like a tiny mix of Slack/Group Chat and Post-Its. Offering synchronous discussion via chat and the possibility to store results of these discussions into a container of Notes for asynchronous consumption.
The argument about why slack doesn't work well is a bit of a stretch. I understand all the points on closed system etc. But the author states that slack doesn't work because it's synchronous and it excludes others from participating in the conversation. Then mentions that even with history recorded, the person in a different time zone can't participate. Then the argument is to use email threads instead. email suffers the same problem of slack, where those who didn't check their email while a discussion was happening now feel missed out on. However, they can reply 8-20 hours later or even days later. Well, you could do the same thing with slack. The problem with slack is the lack of relevant threads. Everything is one giant thread. But that is how most email mailing groups become anyways.
Now, I am not a proponent of slack, I think it has its own problems, but I don't think email is any better.
I think there are good points there about offline participation and archival. I would expect that 99.9% of those on HN have at one time or another found an answer via a direct forum/message list archive or off a google search result returning the same. That will not happen as discussions move to Slack like systems and even if it were, threading would not likely exist.
Addressing another point, and though I do use a Slack imitator for a small non-work/non-programming group - an advantage of IRC is that it can be part of many chat clients which handle multiple protocols. Thus I have IRC open with multiple Jabber chats and mucs. Slack et al, at least on the desktop, are space hogs (from those I have seen) and when I am working, space is a premium commodity even with two large displays. The last I checked, IRC integration into Slack is cumbersome and lacking, is this still so?
Can we just go back to aim? I really hate having one damn view for channels, so if I'm talking to two people I have to constantly switch back and forth. I still don't get how these kinds of tools get such a big following.
I think that's the biggest flaw with a lot of web-based chats. There's no flexibility in layout. With a chat app like pidgin, I can choose how things are laid out, set up notifications a lot easier, etc. Webapps tend to be a lot more limited in such areas -- not able to choose notification sounds, set various things to notify in different ways, etc.
Yeah but no one seems to be making anything but web apps. I guess I come from a time just before this but I honestly can't understand how people think these things are better than their native counterparts.
For a long time it opened a new window for each conversation so you could have a few going at once and see them all side-by-side. At some point tabbed windows became standard, but I'm pretty sure most clients like Pidgin will still give you the option of separate windows.
I think many opensource communities do not want to dogfood on other opensource projects anymore. They want the best product out there for other things and more often than not these products are closed source SaaS products.
Just yesterday I was looking for a way to present all the messages in a given Slack channel as an RSS feed, and I was surprised to come up empty. (I found lots of ways to go the other way though, from RSS into Slack.) The best I found was this, but it looks like you need a Heroku Dyno and must be the account owner---oh and it only exports links, not full messages:
Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad.
"Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad."
How in the world would you improve mailman ?
Not enough js for you ? Not enough on-hover events ? Too much plain text and obvious links ?
Please, please - to everyone reading this today and into the future - do not fix mailman. Go "fix" something else.
Well, not emailing me a password in the clear once a month would be a start. Needing yet another username and password for a site they already has its own some sort user login system is another wart that is easy enough to solve, but for some reason or another, hasn't been fixed on any sites in recent memory.
My email address was already validated with main site sign up, I shouldn't need to repeat that for every mailing list I want to subscribe to on top of that.
If you're reading this from the future, please let me know if any open federated systems managed to come into being, or if spammers finally managed to kill off email so important business is conducted via Snapchat.
The biggest reason is that it's asynchronous. Not everything needs an answer right now this instant, and in order for there to be an instant reply, someone has to be on the other end of the keyboard and continual interruption is a way to get nothing done real fast.
Does Slack's terms of use forbidden creating an off platform archive?
If not, given that searchable archives are one of the ways Slack makes money, makes me wonder why there's not an open source way to pull the chats and archive them in a way that's cheaper and independent of Slack.
Yes, but chat logs are logs of ... chat. By nature, it's disorganised, free-wheeling, contains lots of casual meandering (as any conversation would). Not very useful to a third party.
How often do you find solutions in public archived mailing list posts when Googling problems? I imagine often. While some e-mails are more terse than others, fundamentally e-mail list posts demand a certain structure. Can you imagine having to pour through a 25-page chat log instead?
And with that, the entire idea of "search the archives before asking a question" would go to pot.
The problem isn't creating an archive, it is
a) synchronizing the archive properly to account for your feeds connectivity issues, and
b) providing the archive usefully once it gets large and/or popular
(a) is fiddly and a bit technical but has been solved-ish for ages before slack existed
(b) is fundamental though. If it's a big archive, it costs real money to provide access & search to. If you break it up, search-ability tends to suffer.
None of this is new, slack is just the latest flavor
Right, but they do still permit the capacity to read accessible history, which is open to scraping and archiving. They can't completely kill the concept of doing that, realistically.
They can't stop someone from creating an archive that's inaccessible to them, if they don't know of its existense. Anyone can create an archive of something they can read and hide it, and selectively share it.
Such an agreement on curtails specific forms of automated crawling and public-facing archives.
I was [breifly] part of a project that used slack as the primary communication medium. I can second all the points in the article. IRC is a terrible format for open source collaboration. Flame wars can get out of control really quickly via text.
It's been going one since the first companies tried to monopolize Internet chat by centralizing it on their infrastructure in the 90ies.
The argument for AOL/MSN etc back when the Internet was new openness for the unwashed masses just a dream is exactly the same being made by slack i.e. that by making it locked and taking away the complexity introduced by the existence of cross vendor compatibility new users face less confusion.
Well, this one was supposed to be a little different, as instead of open vs closed, it was sync vs async. But when the topic of OS projects and closed tools comes up...
You're never going to move large groups of people by just yelling "xxx is terrible!" You have to make something better that people want to use to get them to switch. Unfortunately, Slack is better than IRC in many ways that matter to a lot of people. Ignoring all of those things doesn't make IRC better, and it's not going to make people want to use IRC over Slack.
Because the things that are driving people to use Slack are the same as existed five months ago, and arguments like this do nothing to prevent people moving.
But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time.
This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have input from stakeholders around the globe).
If a group has the choice between realtime and asynchronous channels there needs to be a guideline for this.
If my org takes pride in consensus for everybody, everybody needs to have the time to submit input. It's not uncommon that some active users in a chat go for an ad-hoc decision just because they are more than one and want to work _now_. In the long term this damages the culture, splits the participants and is difficult for newcomers.
I completely agree. Unfortunately, what I've seen more than once is that mgmt (or even someone from the rank-and-file) sees / experiences a new tool like Slack (or Campfire, or Hangouts, or...) and says "hey, great new tool we should use!" and that's the 'decision'. No thought given to how async comms biases development when developers are spread world-wide.
I gripe because I am a US left-coaster who works with a team that is increasingly based in Western Europe. By simply deciding to rely on Slack, they have essentially cut me from development conversations other than the weekly live session.
I feel ya, it's frustrating. Although I did not yet have a problem with time zones, I experienced being left out simply by joining the chat later in the evening.
I don't know why didn't just evolve irc. Feature wise slack doesn't really bring much new. It just has a good interface. If someone made an irc client as easy to use as slack then we'd have our answer.
It really is. Slack's interface is good enough and easy enough to understand that even the least technical people can pick it up in a few minutes after you show it to them and explain the difference between public and private channels. A week or two of use is enough to master everyday Slack use. Slack may not bring much to the table in terms of new functionality, but it does make it insanely easy for the average person to easily use the system and be involved, which really cannot be overstated when working at a company with a varying level of technical abilities.
Get a good GUI client, enter some parameters into a text bar, click 'ok', then chat. exactly the same process as a web browser..
The real problem is the 'endless summer' of tablet-era people who confuse the 'interweb' with the 'internet'. There used to be much more general community advocacy and understanding of promoting open communications 'baked in' to the internet culture which has been eroded by crass commercialization - this is the real problem that needs to be attacked...
Can you easily share multi-line code, formatted in a proportional font and syntax highlighted, in any IRC client? That's something I want to do almost every hour I'm working.
Some clients will intercept multi-line messages and let you POST the content to a pastebin. That way, supported clients show pretty-printed code and unsupported client just see a URL.
Because adding a feature to a standard means you have to get everyone on board. Slack as an IRC client would basically be Slack as it is now, and the server protocol would be an implementation detail.
I massively disagree with #2. Unless your project has very little activity, synchronous or pseudosynchronous communication is a lot more efficient than async through email/discourse. It's also a lot more friendly to your contributors, it makes things less formal and more human.
Async shines when you have a lot of users, but only if it's very accessible (searchable). Otherwise it's just people repeating themselves constantly.
Also, longer rant on the IRC thing. For the past decade I've been using IRC as my central mode of group communication for all open source work. Last year and as part of my (open source) company, I've completed the switch to Discord.
I'm an open source die-hard and it bugs me that Discord isn't open source yet, but I believe this has a fairly high chance of changing (MUCH higher than Slack has at any rate). I would heartily recommend Discord for open-minded open source communities.
I'm now using Discord for everything. It has given me a unified interface for all my personal and group communications, easily searchable, with voice chat too (and video chat very soon, I cannot wait to never open Hangouts again). Needless to say, I'm a huge, huge fan.
Slack has none of that. The #1 thing that bugs me with Slack is the forced separate accounts for every single Slack instance. And you can't delete any of those accounts, you can only "deactivate" them.
Our open source community uses it. It works really well for us because we're a gamer-oriented open source community, so Discord is already pretty well known in that circle. On an ideological level, its API gives enough control over everything that goes in in it that I'm satisfied I could move to another service, should I need to. If anything, it's harder to move off IRC because there's no public logs, easy point of contact for the regular users, etc.
Also, I'm using Matterbridge to mirror our public channel to IRC: https://github.com/42wim/matterbridge/ (highly recommend everybody here checks it out; it supports a lot of protocols)
IRC has really disappointed me the past few years. I had a lot of hope that irccloud.com would offer a solution to IRC becoming irrelevant in the face of Slack and Discord, but it just hasn't happened. They're understaffed and don't have enough money coming in.
There's also a lot of ideological purity in recommending against SaaS "centralization" for comms but the truth is, it's not better. Last year my HDD crashed and I lost the logs for my organization's original channel going back to its creation... I'm very, very sad about that. Had I been using IRCCloud (or Discord) at the time, I wouldn't have lost all that. Granted, those companies could have, but the chances are lower than me fucking up.
This is the same reasoning why email is usually better off handled by companies whose livelihood depends on offering you the service, than by yourself.
Also like I said elsewhere in this thread, for a project using a Freenode channel and another using a Discord/Slack server, there is no difference between Freenode disappearing and Discord/Slack disappearing. Your host disappears, you have to find a new one, update tons of references and contact lots of users to let them know. On IRC, that's even harder. You can run your own IRC server, but very few do that, and those that do get less mindshare because connecting to yet another server is very annoying on IRC. It also costs you more, both in money and maintenance.
The biggest problem I have with discord is that the client is complete and absolute balls if you want to be in more than one group at once and keep up with notifications and the like. With IRC, my one client shows the activity of all of the networks I'm in, with discord, the only notification I get is that there's "something" going on in another group, without telling the channel, etc. It's much more interrupting and frustrating.
The article, at the end (spoilers) states that async communication should be preferred for open source work. And I agree that async is important. But there are times where you do need that synchronous, let's talk now communication. And for that, Slack is great.
> This means that the content inside those systems is closed. I cannot link to a discussion in a Slack channel in a tweet.
Such a shame that you can't make a link in one closed system to another closed system.
> The tools that fit this requirement best are; mailing list, issue trackers, and forums.
Mailing lists suck. They're hard to read, hard to follow, and create an endless supply of unresolved issues that everyone forgets about. Big projects using mailing lists seem to do so out of inertia rather than choice.
Please, stop advertising slack. Any time when i read hackernews, i see 2-3 'news' about this chat program. It was big mistake to use slack in our company.
Curious why: as a specific tool, or, would IRC / Skype / whatever have been equally as bad (e.g. because they suck productivity and encourage factionalism or...)?
(My org uses it having replaced Skype for team chat, and so far it's been an improvement for us.)
For open source projects: offer Github issues, IRC for chat and a proper forum like phpbb or a more modern forum like discourse (or one of the clones) and/or a mailing list.
Replace Github with your favorite modern bug tracker. Some very old software Bugzilla/Trac/Confluence are not modern, have a bad UX and kind of off-putting.
No, really, replace github with nothing at all, they are all equally off-putting, because the concept of offering (only) a user interface and in particular accounts to external parties is stupid in the first place.
Offer an email address for bug submissions.
Of course, feel free to use a bug tracker internally if you like, and possibly even with a public user interface for people who want to use it, but a user reporting a bug to your project should normally not need more than a working email client.
I have an email client that's configured to fit my needs and that allows me to efficiently process lots of emails and to write and manage outgoing messages in a single unified interface, and that's all that's really needed for most bug reports, so don't try to waste my time by forcing me to learn your user interface of choice that's not going to have the features that I want to have anyway.
Well, then we can all turn off our computers and go home, because something that "works" is obviously good enough and the entire software industry doesn't need to exist anymore. Most things we have today "work" but we're still improving on them because "good enough" isn't good enough.
The question you're not asking is whether your replacement is better than the existing solutions. Slack isn't. It's closed source, proprietary, and tied to a third party's servers. I'm not going to tie my projects or company to that kind of anchor.
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