Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

491–500 of 536 posts

Re: Why Slack is inappropriate for open source communications

#491

Earlier quoted context omitted.

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…

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

This works with a 20 user room.

Try it again with 1000+ user rooms, or even 8000+ user rooms.

The worst case I'm currently trying to support is a bridge for a game's chat system with 18'000 users in one channel (and users still expect the client to connect in 4 seconds on mobile, and be stable).

And without a custom binary protocol and lazy sync, Matrix will not support that. True, it's also at the upper limits of the Quassel protocol for now, but Matrix is even further off for now.

That said, as I mentioned above, if Matrix someday gets full support for a good binary protocol and real clients, it might truly replace IRC.

Re: Why Slack is inappropriate for open source communications

#492

Earlier quoted context omitted.

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

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

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

What is large, you might ask? 18'000 users in a channel.

And still it should feel and be as easily usable as a channel with 10 users, even via dialup.

That's the point where every byte that isn't used optimally becomes a problem. And where HTTP2 eith gzip or even brotli just isn't enough.

Where Java's IO is too slow, and you need to use the new native noncopying IO subsystem.

But I'll also be happy if, someday, we'll have a truly universal protocol for this.

Re: Why Slack is inappropriate for open source communications

#493
post #465
post #213

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

You have completely misunderstood the post.

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

This is in no way a disagreement with the author.

Re: Why Slack is inappropriate for open source communications

#494
post #358

Earlier quoted context omitted.

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, st…

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

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.

Re: Why Slack is inappropriate for open source communications

#495
post #416

Earlier quoted context omitted.

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

Some clients will intercept multi-line messages and let you POST the content to a pastebin. That way, supported clients show pretty-printed code and unsupported client just see a URL. Ex: https://blog.irccloud.com/pastebins/

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

Re: Why Slack is inappropriate for open source communications

#496

Earlier quoted context omitted.

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

This works with a 20 user room. Try it again with 1000+ user rooms, or even 8000+ user rooms. The worst case I'm currently trying to support is a bridge for a game's chat system with 18'000 users in one channel (and users still expect the client to connect in 4 seconds on mobile, and be stable). And without a custom binary protocol and lazy sync, Matrix will not support that. True, it's also at the upper limits of th…

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!

Re: Why Slack is inappropriate for open source communications

#497
post #430

Earlier quoted context omitted.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> This is 100% purely a user interface feature

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

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

Re: Why Slack is inappropriate for open source communications

#499

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

Re: Why Slack is inappropriate for open source communications

#500
post #356

Earlier quoted context omitted.

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.

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

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

Post reply on HN