Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

311–320 of 536 posts

Re: Why Slack is inappropriate for open source communications

#311
post #262
post #236

Earlier quoted context omitted.

Well we are moving to a web first world, and passing the terminal days of IRC. Trying to avoid web technologies isn't going to do anyone good. Best we can do is try to make them better are secure. Light weight clients can be written in C if you want. There's nothing that needs a web browser Here's the spec if you're interested[1]. There's also a weechat script if you want a command line client[2] [1]: https://matrix.…

> Well we are moving to a web first world, Too bad much of the web stinks, with terrible responsiveness and usability and impose those results through bloated protocols and spaghetti architecture on anything that tries to interface with them. Multiple times on caltrain I've had people ask me how I'm on the internet as I have meetings on IRC without even noticing the connectivity has gone poor -- while their webchat s…

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.

Re: Why Slack is inappropriate for open source communications

#312
post #310

Earlier quoted context omitted.

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

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

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

Re: Why Slack is inappropriate for open source communications

#313

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 an…

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

Re: Why Slack is inappropriate for open source communications

#314
post #293

Earlier quoted context omitted.

Matrix is an extremely heavy protocol, not suitable for business use imo. Riot is really obnoxious to use and get set up, and is also extremely resource hungry. I don't think you're very familiar with chat protocols if you think it's even remotely suitable as a replacement for IRC.

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 no…

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

Re: Why Slack is inappropriate for open source communications

#315
post #201
post #160

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.

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

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

Re: Why Slack is inappropriate for open source communications

#316
post #262

Earlier quoted context omitted.

> Well we are moving to a web first world, Too bad much of the web stinks, with terrible responsiveness and usability and impose those results through bloated protocols and spaghetti architecture on anything that tries to interface with them. Multiple times on caltrain I've had people ask me how I'm on the internet as I have meetings on IRC without even noticing the connectivity has gone poor -- while their webchat s…

There's nothing inherently 'web' or 'slow' or 'ajaxy' about Gzipped-JSON-over-HTTP2. I agree that the web is slow and crap a lot of the time, but chat using gzipped JSON over HTTP/2 would be just as fast as IRC as long as it's only sending the same level of info as IRC.

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

Re: Why Slack is inappropriate for open source communications

#317

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 an…

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

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

Re: Why Slack is inappropriate for open source communications

#318

Earlier quoted context omitted.

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

A few comments that I hope are constructive. Looking at your page, I'm not confident you're avoiding the issue by which these tools proliferate: https://xkcd.com/927/ Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into. You write: > Schedule your time spent and group distracting reminders and notifications in one place If this "one pl…

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

Re: Why Slack is inappropriate for open source communications

#319

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…

A Cloud machine look like https://cloudron.io. It's distributed and they have the button you seek. Many github pages have this button already: https://github.com/RocketChat/Rocket.Chat#cloudronio, https://docs.nodebb.org/en/latest/installing/cloud/cloudron...., https://kanboard.net/documentation/cloudron, https://github.com/wekan/wekan#supported-platforms to name a few.
Post reply on HN