Hacker News new | past | comments | ask | show | jobs | submit login
Tell HN: Slack decides to close down IRC and XMPP gateways
1148 points by elektron on March 7, 2018 | hide | past | favorite | 600 comments
11:14 -!- Message of the day

Hello! We have news to share — we've decided it's time to close down the IRC and XMPP gateways to Slack.

After years of evolving, Slack is at the point where the gateways can no longer handle all of our features or security needs.

If you've been using the gateways for accessibility reasons, we're glad to let you know that it's now possible to navigate Slack by keyboard and with a screen reader — and we're making more improvements on a continual basis.

Still, we know this is a disruptive change, and we want to help with this transition in any way we can. Please follow this link to learn more about the upcoming changes:

slack.com/account/gateways

11:14 -!- End of MOTD command




I'm very disappointed to see that Slack has decided to go the way of every other messaging service and move away from decentralized and standardized protocols towards those that are walled and proprietary.

> We are focused on making Slack accessible to all people. Over the past year, we've made great progress in improving both the keyboard and screen reading experiences in Slack. We know many users have been relying on IRC and XMPP clients for a more accessible experience — but our goal is to build all of the accessibility features you need directly into Slack.

Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team.


> Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team.

Not just that, but it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days. So yeah, I take this promise with some skepticism.

So either this is a lack of priority and disrespect to a part of their users or some level of incompetence.

I might sound harsh about this, but imagine being a blind software dev that's supposed to work with Slack to participate in teams. Every day you sign on to your team it's possible that the Slack devs break something and you can't function. And now they closed the escape hatch.


So much this! I happen to be a blind software developer who has had just this sort of experience in years gone by. Web apps mean that you are at the mercy of the developers. Something can work one day and break the next. This is even more true for blind people than it is for the general public. Even if there is accessibility testing, I doubt that it covers my particular toolstack. I'm on Linux. So I'm doubly a niche user.

The web (and web apps) are all about providing an experience. I don't want an experience, I want a reliable tool.


Oh man, makes me so happy to see the accessibility concerns at the top of this thread. I hate Slack so much. Nothing has made me say "is 10 AM too early for a beer?" quite so much as that absolute pile of uselessness. I thought they'd actually improved their accessibility story when my screen reader read various elements as buttons. Later I discovered that, while they'd likely added the correct ARIA role to a <div/>, they didn't bother adding expected keyboard behaviors. I'm fortunate enough to work with co-ops, and the company I'm founding hosts its own tools specifically because those I can control, and I can pick the more accessible open source chat solution. But I can't count how many times I've had to be some company's special snowflake because I can't use Slack, can't use Toggl, can only use parts of Basecamp, and as such can't participate in a bunch of their processes. Now I'll encourage companies further away from Slack than I already do. Forget not touching it with a 10-foot pole. The 100-footer is coming out for this one. I'm sorry to post such an unproductive comment, but if you're working for a silicon valley company and not doing accessibility then you're doing it wrong, and you can pay me or any number of other talented blind developers with some of that investor capital if you want us to show you how to do it right. There is no excuse for being so exclusionary.


As a developer who should probably pay more attention to this than I do, can you recommend some reading material about how to make an app accessible, and how to make sure it stays accessible (i.e. is there a good way to CI test this?).


The only way I'm aware of today is to learn to use assistive technologies and use them on the right combinations of browser/OS/version. These are recommendations for common combinations. [0]

I've given the CI deal a good amount of thought. You'd have to go through the trouble of:

- Provisioning a Windows VM with specific versions of browsers (e.g. IE11) and AT (e.g. JAWS 17, the versions differ quite significantly)

- Writing an automation suite that is capable of controlling the browser and AT (Selenium probably does fine), but crucially interpreting the feedback from the assistive tool to check for correctness. This is tremendously hard. Either using some debugging APIs if any exist in the various assistive tools, or reading memory / reverse engineering using IDA, or capturing the audio output to the sound card and running it through speech recognition to figure out if what was said by the screen reader is what you'd expect. With something like Dragon Dictate you'd have to figure out how to trigger voice commands.

- Expose the VM using an API that you can call from your test suite

- `expect(jawsOutput).toBe("Type in two or more characters for results.")`

That's a potentially tremendously profitable SaaS offering (to the right companies), if someone can build it.

[0]: https://accessibility.blog.gov.uk/2016/11/01/results-of-the-...


I wouldn't recommend using JAWS and IE for CI. For this purpose, I think it would be much better to use NVDA (https://www.nvaccess.org/) with any browser that can be controlled by a test framework like Selenium. (NVDA supports all the major browsers now.) Then, to feed the text-to-speech output back into your test framework, you can write a simple TTS driver for NVDA, in Python.


That would be a lot easier. I've assumed that NVDA would be the easiest to plug into for obvious reasons but have not looked into it specifically.

I used JAWS and Windows IE11 as a specific example because that's a popular combination with screen reader users. If something works well in NVDA and FireFox on Linux it does not follow that it will work in other combinations, at least in my own testing with things I've worked on in the past. Though targeting the low hanging fruit to begin with is how I'd also start if I was building something for this in earnest, ideally I'd want to automate testing with all the popular combinations that I expect users to have.


For guidelines on making an app accessible, check out the W3C's WAI-ARIA Authoring Practices: https://www.w3.org/TR/wai-aria-practices-1.1/


I also dislike Slack. Slack is just IRC, but reinvented with one centralized provider of everything and clunky, inaccessible UIs that they can change around however they want whenever they want.

(My accessibility issue is much smaller: I merely avoid using the mouse cursor, because the keyboard is much lighter on my wrists and hands than the mouse, trackpad, or trackball.)


>"I hate Slack so much. Nothing has made me say "is 10 AM too early for a beer?"

Thank you for this, this made me laugh. You are not alone in this reaction.


Go host your own messaging tool: Relay is an alternative to slack. Relay is open source, built on top of Mattermost. This means you can host Relay yourself. https://relay-chat.com/


i see the comparison to slack, but how does it compare to mattermost ?


Mattermost is open core. So I guess that means mattermost has lots of paid features thay relay will have to reimplement. And I wonder if those will be available in the selfhosted version. https://about.mattermost.com/pricing/


Relay is built on Mattermost team edition so it has all the team edition features. It plans to add new features as per user feedback which will be contributed upstream to Mattermost.


Relay is actually hosted mattermost. You'll get the benefits of mattermost, except with us taking care of the hosting :).


> I can pick the more accessible open source chat solution.

I'd love to hear more about this (the good/Bad/ugly). My guess would be irc is head and shoulders above anything else, due to established standard + myriad of solid clients.

But what have you found so far?


I couldn't agree more!


Oh man, makes me so happy to see the accessibility concerns at the top of this thread

Being “able-bodied” is only temporary, for everyone. Any dev that doesn’t realize this will eventually come to regret it as they age.


Besides building accessibility into frontend/React component toolkits, how do we automate testing for accessibility? I've turned on text dictation and tested apps with a blindfold, but that doesn't scale and I'm not even sure if it's how people really use an app without sight.


After years of trying, I've still not found a reliable way to automate accessibility testing. The only really workable way to manage it currently is: bake it into your entire dev process.

When designing an application, forget the visuals: design the flow of information, and the interactions. This is a surprisingly good facsimile for mobile-first thinking, as it follows similar principles: in both cases, you have a restricted amount of information to display, and have to design to deal with that.

Once you've got the information flow, step from there to visual elements, and ensure that as you build, you're baking in ARIA support and your testers are interacting with it using VoiceOver/JAWS.

At the end, the fact is you won't have anything perfect, but you'll have something better than the majority of sites out there. The reality is that perfection is impossible, but if you bake inclusive thinking into your app from the get-go, it's pretty straightforward, and you usually end up with an application that is less confusing and overloaded with information for your visual users too.

If you leave it as something to slap on at the end, it's almost always impossible.


All good points there, and agreed about automated testing, I think the most you can hope for in that department is linting level testing (color contrast, valid html, associated labels and form controls, etc.)

The hard things like focus control require manual testing, ideally by a skilled user of AT.


Tangent:

I think you should really have someone who hasn't seen the app test with the blindfold.

Is that double blind, or just single blind plus literally blind?


In a medical context, double blind means neither the patient or the doctor knows if the patient is receiving the drug being tested or a placebo.

I'm not sure how that would work for software, but it sounds like a much larger experiment than is currently customary.


> how do we automate testing for accessibility

Have you looked into pa11y and its CI integration [1]? It's a good start but it cannot replace properly testing your UI with accessibility in mind.

[1] https://github.com/pa11y/pa11y-ci


I’d think regression testing is easier than with a GUI. Just interpose between the app and the screen reader, and check for expected strings in the output.


Just curious — how do you effectively program blind? Seems to me like a really difficult problem because coding is about jumping around so quickly and needing to be able to scroll and grok at high speeds. You also have the issue of all kinds of specialized characters that are difficult for any kind of text-to-speech. Are there specialized Braille displays for this kind of stuff? How do you go back and forth between keyboard and such a thing effortlessly?


Not the OP and not blind, but I've worked with a blind programmer before. You move your cursor in the code and it reads you the line. The screen readers can be adjusted so that the speed of reading is really fast. To someone who is not used to it, it sounds like gibberish. But it's pretty amazing how fast the speech can be. After that, it depends on the editor. My colleague used vi (this is a long time ago -- before there was a vim) and was at least as productive as me. The main thing is that you have to remember the code.

I've occasionally tried to set up a workable system so that I could program blind. I have vision problems where I get ocular migraines unless I have my system set up with a huge font and very high contrast anyway, so I often think that it would be nice to program without looking at the screen. However, I have yet to get my system set up in any way that works. Accessibility has a long way to go. Every time I've tried to set things up I wonder how a blind person can possibly get to the point where they can even start. It's so frustrating.

Actually if anyone in the know is reading this, I'd appreciate a pointer to the easiest to set up Linux system. I wouldn't mind giving it a try again.


> You move your cursor in the code and it reads you the line.

That's somewhat similar to how ed works. You choose a line number or range and print those lines to the screen.


Since you mentioned ed, I know of a blind programmer who actually likes and uses ed (or did last time I heard from him). In fact, he wrote his own version of ed that also includes a web browser, and called it edbrowse. To be sure, he's in the minority even among blind programmers. But for what it's worth, you can find an article that he wrote about his approach here: http://www.eklhad.net/philosophy.html


I am not blind but edbrowse is far and away the best non-GUI web browser I've ever used (better than elinks, lynx, etc). I highly recommend that sighted folk crack open the user manual and give it a try.


I love edbrowse! I keep a copy handy; it's the only web browser I know of that is distributed as a single statically-linked executable. Great for getting through wifi login portals before installing packages.

http://edbrowse.org/


But how does it sanely pronounce things with abbreviations or even something like:

NSDictionary *myCompoundedWord = @{@“key: [NSNumber numberWithInt: 7] };

And know that it’s missing the terminal “ in the string and has an extra space after the ]?

Seems very difficult. Would be great if it could understand the language enough to verbalize it at a higher level.


With the punctuation level set to all, the NVDA screen reader for Windows reads your code snippet like this:

n s dictionary star my compounded word equals at left brace at left quote key colon [pause] left bracket n s number number with int colon [pause] 7 right brace right bracket semi

It's a lot to absorb, but people do program productively this way. For example, the NVDA screen reader is itself developed primarily by blind people.


I think it would be much better if the screen reader could use sounds for punctuation, like the sound of a typewriter typing to indicate a dot, and some meep-like sound with the frequency goes up for an opening parenthesis, and down for a closing parenthesis.


I liked Urbit's mapping from symbols to syllables: https://github.com/urbit/docs/blob/master/docs/hoon/syntax.m...


That idea is as old as Victor Borge...


Interesting, how do blind developers feel about minimalist languages like lisp? On one hand it seems like it would read very well in some circumstances (+ 1 2), but the scoping could be a real pain. Cobol seems like another language that might be well suited to them.


I'm not aware of any correlation between blindness and programming language preference, even when blind programmers work on their own projects. I used to think blind programmers wouldn't like Python because it has significant indentation. (Note: I'm visually impaired, but I program visually, not with a screen reader.) But as it turns out, I know blind programmers who love Python and can deal with the indentation just fine. The NVDA screen reader is written in Python, and that project was started by a blind programmer who could choose any language he pleased.

Some projects developed exclusively or primarily by blind programmers do make odd indentation choices. A couple of my blind programmer friends prefer single-space indentation, or at least they did the last time I worked with them (using Python). NVDA uses tabs for indentation, which breaks with the Python convention of four spaces per indentation level. But blind programmers are perfectly capable of following the usual indentation conventions when working with sighted programmers.

Finally, I don't know of any blind programmers who like COBOL. I'm sure there are some, probably working at banks like their sighted counterparts; I just don't happen to know them.


Emacspeak[0] is one of the more popular voice oriented IDEs. I have yet to get it working, but I think you can do things like get it to read visual regions and sections between matching parens, etc. Ideally this is what I want to use, but it has resisted my efforts so far. Maybe I'll give it another try this weekend.

[0] - http://emacspeak.sourceforge.net/


"parens parens parens parens parens parens parens some code here parens parens parens"


The regularity of Lisp's syntax suggests an interesting way to render it in speech, at least for blind people who happen to have a good ear for music. Set the TTS engine to monotone (i.e. no attempt at natural intonation), and increase the pitch for each level of parenthesis nesting. So it would basically be singing the code, going up a note or two for each level of nesting. It would sound weird, but I think it could work for some people, myself included.


I like that direction, but it also sounds like it might be hard to know the reference points. I wonder if it'd be easier to separate if you used musical notes in conjunction, where the octave/note/chord/scale is mapped to the indentation?

Even better would be tools that are aware of indentation, that you can't see the indentation, and help you debug problems without having to make it so explicit all the time. It could get really weird / grinding to have to listen to monotone speech that's constantly changing pitch.


What if instead of just the pitch it said "do ra mi fa so la ti do" every time you went up/down a level? If I ever lost my sight I doubt my tone deafness would would go away.


Ugh, that won't do. I need my: brace bracket paren asterisk some code paren bracket brace semicolon.


Screenreaders usually break it down into chunks it can pronounce or spell it out character by character, with added cues to indicate punctuation and some other things. It's not as slow as it sounds though, most blind people have their screenreaders set to read at a speed that is totally incomprehensible if you're not used to it. It requires a very good memory to manage something like programming, but blind people get really (almost unbelievably) good at that sort of thing simply because they practice a lot by necessity.


I imagine, if you can comprehend at a very fast speed, it gets easier to keep the line in your head. As you can store and revall the characters from the very short term memory. I don't know if this phenomenon exists, but if I,'ve heard the entire line in for example 0.5 seconds, I think I'll be able to construct a mental image of it and code.

Another point is that I imagine it takes your complete focus to listen and comprehend single characters at such speeds, so you will be super-focused on the task when you're writing code.

We, as the programmers with sight, can read code without getting anything out of it, if we're not focused.


Here's an example:

https://youtu.be/iWXebEeGwn0


> coding is about jumping around so quickly and needing to be able to scroll and grok at high speeds

I mean that might just be how you code, and GP does not code that way...


If you work on a large production code base, I don’t see how you can’t end up having to search and grok lots of code written by other people...


Since you mentioned braille displays, some blind programmers do use those. They're expensive though ($1000 or more). Computer braille has 8 dots per cell rather than 6. That's a good fit for ASCII.


depending on how our punctuation is set up with any screen reader, the characters in code are read off nicely. And no special Braille Display is needed for this; any normal one will do, then again, Braille displays are a rather wide selection. With the keyboard, we can move back and forth nearly as fast as, if not sometimes faster, than our sighted counterparts.


Out of curiosity, what is your toolstack?


I use emacs with emacspeak for programming and a good many other things. For pure terminal interaction outside of emacs I use a console-based screen reader called Speakup. For graphical applications, I use a screenreader called Orca. I don't use a whole lot of graphical applications, but I need Firefox for most of the "modern" web. I've also used Chrome with Chromevox over the years.

Honestly I prefer text-mode browsers when I can use them, but that ship has mostly sailed. I've been involved with the development of edbrowse; the author is a friend of mine.


Do you need a ridiculously good memory and visualization skills for that? I can't imagine writing code without looking at it.


I do have a very good memory, but I cannot really visualize. I've never had any sight. I'm so bad at visualization that I'm baffled by the concept of a picture. How do people manage to cram three dimensions of reality into two? It must be very lossy. Anyway I do have a knack for understanding how all the pieces fit together and keeping it in my head.


> it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days

A userscript hammered out in a few days is not really that comparable to incorporating accessibility in a flexible and sound way across a codebase.

Where one is dependent on the current representation and types of features in the app, the other touches pretty much everywhere in a code base that might be split across different people or teams that have other business goals to accomplish.

The scale of work is not really as comparable as they may seem at first glance.

So, contrary to what you said about lack of priority and disrespect, I think it's admirable that they take the time to add these necessary accommodations in a way that ensures that they'll be appropriately maintained and present with future iterations.


The scale of work would be a lot, lot, lot smaller if they had made native apps to start, and could use the built in accessibility stuff instead of having to reinvent the wheel.


Is there a reason Electron apps can't take advantage of the accessibility features built into Chromium? Having separate platform apps runs into the issue of the user settings page being accessible in the Windows app, but unusable with a screen-reader in the Mac app because of a bug, etc etc.


assuming this claim is valid, that it took "few days" to implement what took them "months", then they could rewrite the entire user script from scratch every time a change is made, and this could be repeated dozens of times, which, assuming major UI changes are made once every few months, would take several years.


But, but, but, then I'd have to touch the same code twice... /s

There is definitely a poison in our profession, I definitely have to fight the urge to make sure no future changes will break something, instead of just budgeting time to fix breaking changes later. Especially since no one seems to remember when we all agree something doesn't need to be bullet proof. Just today there was an expression of disbelief when I reminded people I'd built a tempermental UI for some internal tool. Never mind that it was a conscious decision to prioritize a better UI later if we found the tool useful and found the UI was causing problems.


These are not unrelated observations! The same people who expressed disbelief that your UI is temperamental will react the same way if Slack releases a temperamental UI.

The difference is that they don't work in the same office as Slack. They'll never hear about all the important, completely justified reasons Slack decided to release a bad UI. They'll just notice it happened, and conclude that Slack must hire incompetent UI developers who didn't realize it was bad. Any product with a large customer base has to be pathologically averse to things like this.


What is a temperamental UI? It must have something with UX to do I am sure but can’t find anything on the first page of Google about it aside from one page that mention avoiding UIs to be temperamental but firstly that was all that was said it seems and secondly the forum is was posted on was, ironically, completely broken on mobile such that the text could not be seen. The page had a mobile navigation bar and the zoom set to mobil unchangeable but the content is wide like on a regular monitor and cannot be scrolled into view and additionally there is a sidebar so only the first few letters are visible of each line of text. It was about the worst thing I have ever seen on mobile. Obviously they have wrapped a forum solution in their own templates and their templates are responsive but the forum content is not. So I guess the people that run that site don’t browse their own forum in a mobile browser. Anyway I digress.


Here it's not a named concept, it's just "temperamental" + "UI". In this case, temperamental means "something that does not behave or work reliably."


PS: Here is the link https://www.lean.org/FuseTalk/Forum/messageview.cfm?catid=49...


Any extra engineering time spent on something beyond that required to make sure it fulfils its purpose is wasted. It's like the old quote about Formula 1 cars: The perfect Formula 1 car crosses the finish line in first place, then falls apart. If it doesn't cross the finish line in first place, it's too light. If it doesn't fall apart the moment it crosses the finish line, it's too heavy.

(Note that 'purpose' might be 'allow us to process this one batch of files' or it might be 'provide a stable, maintainable infrastructure for our product for the next 20 years'. It's just important not to lose sight of that purpose either way!)


Not to mention that Chromium takes a performance hit when accessibility is on – that's why it's off by default. But both Safari and native Mac apps are always accessible.


Well, in this case I was quite glad that they have targeted the web platform. At least that allows me to code my own stopgap solution using userscripts and stuff. That's harder for native.


With native apps, you don't need to. Good accessibility solutions are the default.


As a developer community, we need to get to the point where accessibility is not an afterthought, not even something that has to be considered at all; that just is. I'm stating this from experience; I'm blind myself, so I know exactly what is being referred to. My group used to use Slack, and we stopped using it for this very reason. It's not hard to fill out the accessible label field. If it's present in the framework, then it should be taught and enforced.


What do you use instead of Slack? I'm a blind developer and find it usable enough, but I'm also on a fairly small team with out a tun of slack traffic.


We use Microsoft Teams, and for our public interface, Discord. Though I just set up a team on Keybase as well. Look for OpenCAD on Discord and StormlightTech on Keybase if interested.


I hear you.

I worked with two blind systems people for close to 5 years - we were all working remote, so initially I had no idea they were blind - and subsequently learned from them about their struggles and frustrations dealing with shitty or nonexistent accessibility features.

And with assistive devices’ drivers that were broken, or not updated since Windows State of the Ark version, or not available on Linux or Mac, and so on.

These two people dramatically improved the accessibility features of the smartphone product that the company sells, by reporting the issues they found while dogfooding it. They raised the awareness of many people, including me, of the challenges of the blind, particularly in technology settings.

As a result, I learned ‘dot’ (graphviz) pretty well, and became much more text-centric in other ways (e.g. using markdown, avoiding images when possible, adding alt text).

Slack has done the community a disservice by dropping support for open protocols like IRC and XMPP, which support text-based interfaces that work well with screen readers.


It might be only tangentially related to your point, but there are Slack API-based clients for [emacs][1] and [weechat][2].

So screen-reader usability is still a thing. The fact it's not using a proper standard open protocol is a problem.

[1]: https://github.com/yuya373/emacs-slack

[2]: https://github.com/wee-slack/wee-slack


As someone who doesn't use slack, why did we ever move away from chat programs and protocols that worked fine? I don't know why I need to use slack, hangouts, discord, etc, that are just reinventing irc and/or the garden variety instant messaging platforms that already exist.


  I don't know why I need to use slack [...] just
  reinventing irc
Features Slack has that IRC doesn't include:

* User authentication

* Support for multiple concurrent logins by one user

* Persistent, searchable history

* (Ad-free) file and image sharing built in

* Simple integrations, like webhooks, built in.

In other words, Slack is like IRC+NickServ+Irssi+Screen+Imgur, except easier to use, in the sense that you don't need to know key combos like Ctrl+A+D or Ctrl+Alt+2, you don't have to figure out how to send such combos from your phone's terminal emulator, and you don't need access to an always-on server to run your screen session.

Of course, it's not all good; Slack has a bunch of opinionated design choices, like a channel it's impossible to leave, no ability to block users, no off-the-record option, and suchlike.


You are trying to try people what they should prefer. This is about openness and choice. If I've been using screen and irssi/xchat/etc for decades I don't want to learn anything new. I don't want a huge app shoved down my throat that's not nearly as customizable and integratable into my workflow as all those tools I already know. The slack app is just a horrible tool designed to get into your way and interrupt your work. Thank god we didn't jump that shittrain on my current job.


Not to mention the webhooks. It's trivial to implement pushing data into slack.

They even give you a hello world sample curl when you opt to add the webhook. At the simplest you can just replace the hello world text and bam -- you're sending to slack. Just takes a very simple json input.


Discord is amazing, there really isn't a good replacement right now. Before that it was a mess/mix of IRC/Skype/Teamspeak/Whatsapp, now you can combine all that in one great client from a company that actually seems to care about its users. It's my favorite monthly Paypal charge!


not self-hostable. also, why is it a problem to use different tools for different use cases?

chances it will be around in 10 years? I would say 25%.


I replaced Discord with Mumble [0][1] / Murmur. (Self hosted). It scales really well. On a tiny VM I could handle thousands of people. That said, it isn't quite as happy-clicky-frictionless as Discord. They are working on that aspect of it.

[0] - https://github.com/mumble-voip/mumble

[1] - https://wiki.mumble.info/wiki/Main_Page


When I combine the feature set of IRC/Skype/Teamspeak/WhatsApp, I come up with text chat + voice/video conferencing, which e.g. Skype already provides. Is the difference that the client is great?


Yeah, a feature set doesn't matter if the features are bad. I would never want to use Skype as a platform for an ongoing text chat. (Does Skype even have persistent channels?)

Also now that Discord exists, I would never do a voice chat in Skype either. A substantial portion of every Skype call I've ever been on was people apologizing to each other for the bad audio. Discord apparently just has better signal processing.


> Does Skype even have persistent channels?

Skype for Business does. But... not the Azure/Cloud version; you have to host it on-site, and MS are rapidly replacing Skype with the less feature rich (if that's even possible!) 'MS Teams'.


Ever try to get Skype for business (née lync) working on Linux? With video/voice?


Discord's inability to separate identities is the deal breaker. I don't want to be logged into work and play at the same time. I'd also like to be able to engage in some communities pseudonymously and others not.

None of the chat apps ticks all boxes, which is why we need a universal client that puts the user back in control like in the Trillian/Adium days. And no, matrix+bridges is not that solution.


What's the problem with matrix plus bridges? I am uniformed, so don't take this question to imply there are no problems


As someone also relatively uninformed, when my team moved to Slack I was hoping to get a Matrix integration going. But I don't have admin rights to install the needed integrations on the slack side (and I think we're at max integrations anyway, somehow, why is that a thing...). Though recently I found a different type of slack-matrix bridge that works via user-puppeting, https://github.com/matrix-hacks/matrix-puppet-slack so no action needed on the slack end. Unfortunately it requires you to setup your own homeserver... One day I'd like to have a one-client solution to all these things again like I used to with Trillain/Pidgin. Matrix gets me a lot of the way there and with a little more effort (like my own homeserver) possibly all the way there.


One solution is for matrix.org to provide a hosted instance of matrix-puppet-slack - although we (matrix.org) are not very comfortable doing so because we'd start gathering everyone's slack credentials, which is quite a lot of responsibility. It'd be much better if everyone could run their own and have responsibility for their own bridges. In practice we haven't had much bandwidth for bridge work over the last year but hopefully this will change soon.


can slack plausibly cause ADA compliance problems re: visually impaired people? or would it end up as "use the browser client with a screen reader and be glad you can do that"


The ADA only applies to certain types of "public" private businesses. Like grocery stores and bakeries, hotels, etc. I have never heard of it applying to any private software (that isn't government related). You can always use some other chat software or none at all.

However, I would imagine that as a company, if you require employees to use specific software as a condition of employment and no accommodation can be made, you might run into trouble as an employer.


Moxie Marlinspike has a blog post about why protocols like XMPP aren't good enough to support modern messaging apps. https://signal.org/blog/the-ecosystem-is-moving/

XMPP is an example of a federated protocol that advertises itself as a “living standard.” Despite its capacity for protocol “extensions,” however, it’s undeniable that XMPP still largely resembles a synchronous protocol with limited support for rich media, which can’t realistically be deployed on mobile devices. If XMPP is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world?

Like any federated protocol, extensions don’t mean much unless everyone applies them, and that’s an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren’t consistently applied anywhere. The implications of that are severe, because someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them. It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience.


Tangentially related, I have to take issue with this:

> addressing with user-owned identifiers like phone numbers

Phone numbers are owned by telecoms, not users. Sometimes they're transferable between telecoms, but not always. I, in particular travel internationally often and do not maintain phone service in the same country continuously. I've had to change phone numbers with Signal and Whatsapp a couple times now and have not found it to be a particularly friendly experience.

I got a free Google Voice number and might use that in the future, but I had to tie that to another US-based phone number. What will happen if someone else starts using that number, especially if they also connect a Google Voice account to it?

I don't know that I have a better design in mind, but using a phone number as an identity has some nasty edge cases.


> addressing with user-owned identifiers like phone numbers

Don't take things like that too seriously. That's just the result of the reality distortion field that comes with sitting on top a huge database of phone numbers.


> I don't know that I have a better design in mind

Simple: usernames. Humans are not phone numbers. Phone numbers are the IP addresses of legacy phone networks.


Obligatory plug for Tox.

http://tox.chat

A lot of countries require require registering the phone number to your name.

Relying on phone numbers as uniqie identifiers especially in "crypto" hipster apps (Signal) is stupid bordering on malicious


The reason people use Signal over WhatsApp is partly because of a perception it is more likely to be good against malicious state-like actors: tyrannical regimes etc.

If said malicious actors pwn the phone of the person you were talking to, suddenly they have a pretty good way of mapping a contact called "My Best Friend" to a human through billing records.

Or even easier, they type the phone number into Google and find that the Syrian dissident they've just arrested has been corresponding with the NYTimes or BBC.

If they know only that they are talking to anonymoushackzor@gmail.com they could, uh, get Google to release their IP address. Google are fairly unlikely to honour a legal demand for disclosure from Libya or North Korea or some other tyrannical/fucked-up hellhole.

I like Signal, but I'm not totally sure about the threat model.


Usernames do not solve the problems described in the link:

* They're not portable. My username here is Zak. It is on reddit as well, but I think that's the only other place. If I don't discover a service within it's first week of operation, I won't get that username, and many won't allow it because it's "too short".

* They don't tap into users' existing contact lists. I've discovered several people I know using Signal because I had their phone numbers stored in my phone's contacts.

But if a new communications protocol is to replace the legacy phone network, which I consider desirable, it probably shouldn't use identifiers tied to the legacy phone network.


Turn message forwarding off and nothing will happen, I've lent my cell # to broke friends afew times to make a Google Voice account, and have a Voice number myself for Craigslist exchanges, lapses between paying my carrier, etc


you seem to miss the point.

1) get US phone

2) register google voice to US phone

3) stop paying for US phone

4) you can't de-register you US phone, unless you register a new one

5a) if you never sign up for a US phone, anybody can get assigned that number and click "forgot password" on your google voice.

5b) you get a new US phone: go to 2.

that is true for every single service that ties you up to a phone number or that has phone number as recovery option.


Pay $20 and you get the number permanently. I've set up my kids' soccer club and my son's Cub Scout Pack with voicemail-only numbers. Callers leave a message and a recording and a transcription is forwarded to the appropriate person via email.

I've also read using Google Voice is highly recommended for things that require a voice or text number since it's very difficult to get hold of someone at Google that can be socially engineered. Much easier to scream at somebody at Verizon, etc.


Where can I get a permanent (US) number anywhere?

The cheapest I've seen slightly below $2/month, but all the super cheap carriers are very volatile businesses and you can't expect to keep them more than a few years.

Seeing as you don't really own phone numbers in the sense you own domain names, any permanence is limited by the life span of your service provider.


Google Voice will let you pay $20 to "buy" a phone number (either a GV number they assign, or another number you port in), which is then yours forever (subject to Google's arcane EULA, I'm sure).


...it's yours forever until it becomes Google's forever ;)


I currently have my google voice number only and not tied to a landline or cell number. When was the last time you tried #4, because it's been like this for me for a year or more.


Extension availability/usage will cluster around the tent-pole implementations.

A really popular mobile Jabber client will suddenly have the extensions it supports become popular with everyone else. Conversations looks nice.

As for why some set of extensions hasn't been brought up to modernity, that answer's simple: nobody cares about xmpp enough. Maybe just some users, but fuck those guys, they don't build anything.


>> A really popular mobile Jabber client will

> Will

Man, xmpp has been out for twenty years now.


Irony here is that WhatsApp, Google and Facebook all had xmpp working (in their own silos) for mobile. WhatsApp still do.


> A really popular mobile Jabber client will suddenly have the extensions it supports become popular with everyone else

Until you have two popular apps that implement two different extensions that accomplish the same thing. Now everyone is stuck implementing two, three, four extensions to display the same content. God forbid there's a new version of an extension that's backwards incompatible.


And yet, this is what you can get today with several IRC clients already: https://twitter.com/irccloud/status/971416931373854721?s=21

IRCCloud is using only standard IRC features to implement their Slack gateway that offers all features of slack - including reactions and threads.

Federated protocols can move extremely quickly, I've seen that myself recently.


And here is the response to that https://gultsch.de/objection.html


If it's not in the baseline spec it isn't going to happen.

It would at least have been nice if the 'extensions' had a required way to be opaquely handled and saved as files so that other tools could use them.


What did everyone expect?

Slack is a proprietary protocol created to make money on its proprietary service.

I am glad they are making it more closed as then maybe more people realise that centralising your communications on top a VC funded, for-profit company is not a good idea.


This is true of everything, not just centralizing communications. Any VC-funded free service will eventually be forced to find ways to monetize, and open access channels are usually one of the first things to be killed off. Twitter did the same thing with the firehose.


I suppose most companies use Slack for ephemeral communication. If it blows up, you can just move somewhere else. It was still probably worth it as it is dead simple to set up.


Why is it a bad idea?

And I doubt _any_ business has centralized their communications with Slack. I’m sure they are still using phones, and email and face to face communication.


> I’m sure they are still using phones, and email and face to face communication.

Slack's rise continues to baffle me. It's not good or widespread enough to replace email, Skype messenging, SMS or phone calls - so it's yet another thing I have to stay on top of at work. My life would honestly be easier without Slack.


It is better than E-mail for instant and group communication, it is better in everything except audio/video calling that Skype. SMS and phone calls are not even in the same ballpark in terms of solving group communication problems.

Disregarding the technical side of things, Slack is a great tool and it is quite understandable why it stuck: people like it.


Well, it replaces all those things when you want async messaging with a decent UX.

I'm not sure how serious to take you when you think Skype is better.


Especially when Skype in this context probably means "Skype for Business". Oh, that user just went offline and Skype wasn't aware? Well, you'll be informed, nicely, that the message couldn't be delivered. Will it be delivered? Oh, of course not, this is 2018, we don't do that.

Or you're signed into Skype for Business on multiple devices. You wouldn't expect to receive instant messages on all your devices at the same time, would you? Because that's really asking for a bit much in 2018. We're not wizards, you know.


And planes didn't replace boats, trains, or automobiles.

Baffling that so many people still use it as yet another mode of transportation.


You are in one mode of transport at a time, but your phone can receive multiple forms of communication at a time. All of them with their own notifications, badge icons, and alert sounds, and behind those, some person demanding your attention and only the most minimal cultural etiquette about when to use which and when, if any etiquette is present and pervasive enough through your social and business circles at all.


The ~600 person distributed company I work for doesn't use phone or email and obviously doesn't do anything face to face. We relied on IRC for years before switching to Slack so yes, all of our real-time communication is via Slack. We have internal blogs for threaded important async discussion though, but Slack is where our high bandwidth talk done.


How come you don't use Rocket.Chat or Mattermost or Matrix?


no care for privacy I guess.


Might it be because Slack is free and hosted for you?


Unfortunately, a lot of startups - including successful ones - do use slack to mitigate the need for email, phone, and in-person communication. It baffles the mind but I think it speaks to the relative naivete and inexperience many managers at startups have when it comes to communication in the workplace.

Every time I have seen Slack as the primary communication vessel, I have seen a company that fails to ship on time and has a hard time with knowledge sharing. The medium is the message!


Phones? It's been 10 years since I worked at a company that gave me a desk phone, and it was archaic and useless then. Email is mostly a dumpster fire because of inflexible clients like gmail or outlook with terrible filtering and clumsy rules engines.

At my current company, the main way to reach someone is Hipchat. We have a large percentage of remote workers, so face to face works for some people, but not everyone. You have to be on chat, and you have to be checking it regularly. We still use github, JIRA and confluence for work, but almost everything passes through chat.


> Email is mostly a dumpster fire because of inflexible clients like gmail or outlook with terrible filtering and clumsy rules engines.

Then why don't you switch to a good client? The reason email works so well is that you have that freedom!


Nothing is new man. People are not gonna learn.

Can't wait to use the term "AIMd" on "Slack" (what a stupid name BTW) in 10 years.


Relay is an alternative to slack.

Relay is open source, built on top of Mattermost. This means you can host Relay yourself. https://relay-chat.com/


Why would one want to use Relay instead of Mattermost?


Relay is actually hosted mattermost. Just a means to offload maintenance and uptime to someone working on it full time.

The part of software in Relay that makes mattermost SaSS is open source too.


Tell your team to stop spamming it around then please. Spam mattermost if you must.


They're not the team though.


> Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team.

You're joking, right?

Have you not noticed any of the pain that anybody trying to make cross-platform app goes through, and hence the huge popularity of cross-platform frameworks?


No. It's not hard to write a cross-platform app, but it _is_ more difficult and more expensive than writing an app using a cross-platform framework or web stack.

That's the tradeoff, and I wish companies would be more honest about it. But a company with as many engineers as Slack doesn't really have an excuse beyond "we want to spend less".


Also, I have a problem with the word "hard" in the context of software development.

Things are usually hard not because of some lofty technical goals, but because the sum of all the papercuts is hard. It's just developer hubris to look at the trade-offs someone makes and say (on HN of course) "meh, these other trade-offs aren't even that hard, c'mon!"


Just use Qt. It's harder, but not dramatically harder, than a web-based implementation.


The web-based implementation means you only have one codebase for both Slack in the browser and Slack in Electron. So adding Qt in addition to their browser client means they have two disparate clients instead of one client (plus Electron glue code).


And? I am absolutely tired of companies taking a giant dump on the experience of desktop applications. If you're going to make a desktop app make a damned desktop app, stop making everybody accept a terrible electron app because "oh no, I have to do extra work" - give me a break.

How many companies still maintain native iOS and Android apps? Lots. Qt even feels (mostly) native on GNOME desktops these days, if you can't afford to develop a 100% native app for Win, Linux and Mac then at least use a real toolkit that gets you 80% of the way there whereas Electron gets you 0%.


Honestly, I don't think you can point to any actual business reason for a native client. Slack makes majority of their revenue from large organisations buying thousands of seats in one go and a native desktop client is sadly not a huge selling point for the sales team.

At the end of the day Slack has to optimize for growth and there's a huge list of features that will bring more ROI than native clients which will require trebling the size of the code base.


Killing battery life of their users isnt a business reason?


All enterprise desktop software is trash. Everyone has to put up with terrible AV, terrible VPN clients, terrible VOIP/video conferencing, etc. There's no incentive to make good software for your users when your users don't have a choice.


If doesn't affect their bottomline, then why will they bother?


Customers are fickle beasts, they mutter and keep on using a product until they dont.


Sure, but it'll ultimately be because of a hot new UX or feature that Slack didn't think of, not battery life.


yet there's no slack competitor that has "better battery life" or "native apps" as one of its selling points.


Matrix has native clients[1], as well as a weechat plugin.

[1]: https://matrix.org/docs/projects/client/quaternion.html


So rewriting all their clients would be a more sensible approach to user retention compared to keeping the current Electron client that most users seem quite happy with?


Nokia had users who were happy with the solid phones they were building.


So rewriting all their clients would be a more sensible approach to user retention compared to keeping the current Electron client that most users seem quite happy with?


The profit from "large organisations buying thousands of seats in one go" can surely pay a couple of devs to write native apps.


Fine, if they don't have any business reason for a native client they should just can the slack desktop app because it provides 0 benefits over the web app then.

If you're going to do something do it right or don't do it at all.


The desktop app allows them to Mark the checkbox of having a "native" app when selling ... And in my environment quite a few folks prefer the election app over the browser. I don't know why, though.


I prefer a dedicate app because I can alt-tab through a relatively limited number of apps compared to the dozens of tabs I may have open.

For example, the desktop app will show notification count in the dock.

Imagine if all of your apps had a browser version and you could always pick between a tabbed version vs standalone version. To use the tabbed version of everything would be like using an AOL app back in those days where you alt-tab to the AOL virtual window and then find the app you want within it while wishing you could just use the OS' window manager system.


I simply have it in a browser window in a specific part on my desktop which I manage via i3wm. But, well, everybody has their preferences.


I keep hearing bad things about Electron, and have only now bothered to look it up. As a user of Slack, and whatever other applications I happen to use that are based on Electron, I don't care that the application isn't native. Electron is "good enough." I would imagine that 99% of users feel the same way.

Feel free to articulate your issues with such apps. So far, no one has really done that in the various comments online disparaging Electron.


> Feel free to articulate your issues with such apps. So far, no one has really done that in the various comments online disparaging Electron.

What? Every time Electron comes up, people bemoan its battery and RAM usage.


It's slow. It kills your battery. It disregards standard platform idioms.


So what? You're saying that like it's this terrible thing. It's not. Especially because, as has been shown, Electron apps are extremely sorely lacking in things like accessibility.


Yeah, but unfortunately businesses prefer to sacrifice user experience for developer convenience and expediency. I wish it weren't true.

There are a couple of cases where you can avoid that in the text editor and source control space: Sublime Text is cross-platform and native, and so is SourceTree (although it's become quite buggy). So just avoid GitKraken, GitHub Desktop, VS Code, Atom.


> You're saying that like it's this terrible thing.

I made no such claim. I was just providing a legitimate business reason for going the Electron route.


It's painful if you haven't thought it through or have very little money (or want to cheap out on hiring developers who know what they're doing), and it's painful for the developers if management has been BS'ed into believing that a "cross-platform" framework can magically make their bonuses bigger by cutting costs.


Most accessible users use JAWS on windows. I focus on accessibility a lot for my job. In fact, we have an entire department dedicated to accessibility design, implementation, and testing.

The reason why accessible users use JAWS is that it works across the entire OS and all the programs you have installed; start menu, PowerPoint, web browser, control panel, Google, etc. etc. The problem with the native accessibility tools is that it fragments the accessibility experience; you have one tool for OS operations, another tool for browser work, another tool for this, etc.

So that being said - it is a waste of time to target the native APIs for accessibility. Your target is JAWS and that's it. In fact, I'd argue that JAWS is better at reading HTML than native apps, so Slack is doing the right thing by moving all their apps to the cross-platform one.


I find it unbelievable that a software costing $1000 is the de facto standard. What is their moat, what exactly does it offer that it's impossible to replicate using existing libraries and APIs?


It has a very small but dedicated user-base. You could clone it, but you don't have a market to sell to. You can't just make a lot more blind people to grow the market. (You could, but please don't)


I work at an accessibility research centre in Toronto. When people consult Occupational Therapists for their a11y needs the government here will subsidize a percentage of the software (and hardware?) costs. As far as I know JAWS gets recommended, NVDA doesn't :/


What's the standard really depends on which slice of the world/market you're looking at. NVDA[0] is a very capable screenreader as well and does some things even better than JAWS. It's totally free and open source.

[0]: https://nvaccess.org/


That's great, but nobody uses it, so we don't target it.


For GOV.UK we came up with a screenreader breakdown of JAWS at 38.5%, VoiceOver at 21.2% and NVDA 12%. That’s not a lot, but it’s not nobody.

https://accessibility.blog.gov.uk/2016/11/01/results-of-the-...


Thanks so much for sharing your results!


I bought Jaws 15 years ago before NVDA was out. Because of this it doesn't cost me $1000 to keep using it, it costs me $200 every two years to keep up to date. IT's the only software I know of that offers good 3270 emulator support using third party scripts someone wrote. While it may be possible to make NVDA behave similarly with python scripting it would take more then $200 worth of my time since I'm not a Python programmer. Since I rely on it for my job it's also comforting to know I can call up someone and get help or open a support ticket if something is broken. I have not had to do this recently, but I remember calling up when I switched from office 2003 to 2007 at work because the UI was so different I wasn't sure if I was having accessibility issues or not. Support was helpful and had me working in under 10 minutes.


> I find it unbelievable that a software costing $1000 is the de facto standard.

my recollection from speaking to a blind acquaintance is that it is subsidized by some government agency for personal use, and businesses buying it for blind employees are just stuck with it as an ADA thing.


> I find it unbelievable that a software costing $1000 is the de facto standard.

Of course, there's always software that costs absurd amounts of money for seemingly simple things; IDA comes to mind. I'm not excusing it, but that isn't to say that it doesn't exist.


> What is their moat

Their moat is that the addressable market is too small for investors to bother investing in.


There are 36 million blind people in the world and other tens of millions with severe impairments. It seems more like the market is too small due to lack of investment and development.


By tools, what do you mean exactly? The only tool you require on the OS-level is a screen reader, and it talks to the native Windows APIs depending on what application you are using. If you are referring to the different accessibility API implementations like MSAA, UIA etc. that is not something that should at all impede a native app of any kind, so what exactly are you referring to here?


I am referring to the native screen readers and the extensions browsers provide. Accessible users don't give a shit about the APIs, they aren't programming screen readers for themselves...

The native screen reader built into windows doesn't work well with web pages, so you have to get your own tool (sorry, screen reader) specifically for reading webpages. The browsers all have some extensions for this. So yes, now you have two tools to use - the native screen reader and the browser. And they both are garbage (I've used both while my license for JAWS was pending).


JAWS is Windows-only, so your solution of just targeting JAWS is not a solution at all, since Slack runs on a lot more platforms.


Accessible users are primarily on windows because JAWS runs on windows. It is not a use case for us to test accessibility on anything other than JAWS on windows.


It’s worth pointing out here that that’s true for the desktop market, but as with sighted users a large portion of time for blind users is taken up with mobile or tablet computing and there iOS and VoiceOver is the dominant platform.


Tell that to the Linux guy with vision impairment complaining here in the comments about slack.

Making software accessible just on Windows is complete bullshit and should be downright illegal.


I run Slack in a browser tab . Their native apps are basically electron tabs. I wonder how many people used xmpp and irc gateways in relation to all of their active users ?


They're not basically electron apps. they _are_ electron apps.

And it's completely absurd that mine is currently using 1514MB of memory.

If I weren't required to use Slack on a day-to-day basis, I absolutely wouldn't solely on principle.


Indeed, the Windows app is horrid. One of our older workstations is a quad core i5 with 8GB, nothing special but no slouch either, and the Slack app completely chokes that machine. The employee has to run Slack on her iPhone to be able to get regular work done throughout the day. On our newer workstations it's not quite as bad but it's still noticeable. Our oldest in-service machine is a Core i7 laptop I use when I'm out in the warehouse; that one also chokes heavily with Slack.

It's still 100% an improvement over what we used for chat before (Skype), but I'd be much happier running IRC or XMPP hosted on one of our servers. The boss decided on Slack instead as it's less maintenance on my part. I don't mind the extra work involved with running something we control, but the company wants me on other projects.


Out of interest, what's your concern with Skype? After a hiatus of ten years, I'm using it currently for a customer, and, maybe apart from cheesy emoticons and space inefficiency, so far it has worked well. Am I the only one to like a native (Linux) desktop client with notification integration etc. more than a bloated web/Electron app?


I'm not the original poster, but assuming you're referring to Skype for Business, the main problem with it is that they don't have a Linux client.

The only solution on Linux that implements audio, video and screen sharing is Sky (http://tel.red/), and it's incredibly flaky.


Skype for business on Windows is very bad as well. Lots of scaling issues, incorrect status, freezing, etc.


As often as not, that's a result of shit infrastructure behind the Skype for Business deployment itself, rather than the client itself. There are a number of baffling restrictions baked into the server and protocol itself, and a real production-grade deployment is a byzantine mess that would give Cthulu nightmares.

It doesn't help that the client hasn't had much more than cosmetic changes in at least five years, and is largely abandoned for Microsoft's kludgey Slack competitor.


I use it daily and we never had issues with it.

When something bad happens, usually it is network infrastructure related or some IT experiment going on.


Not only is Sky shaky, but it's advertised as 'free as in beer', if you want to talk for more than 2 minutes you have to pay. Everybody wants to talk for more than 2 minutes.


Mainly, reliability was an issue. There were times when the app would show a user logged in when they weren't, or logged out when they were, making it difficult to decide whether to send a message at that moment.

Sometimes when trying to log in it would say that the (saved) password was incorrect, the user would go change it in their Microsoft account and it still wouldn't take it, then a few hours later it was working fine again.

Slack also has much better search, and their support for attachments is dead-simple. Sending a file on Skype was always a chore that felt like it was 1999 all over again, but on Slack it's literally drag, drop, and collaborate.

As I said before, Slack wasn't my first choice but it's a good platform for what it is. I don't like that our conversations and files are stored on their servers, but I doubt anyone at the company is sifting through our stuff looking for dirt or valuable info on a small business with 10 employees.


If you had tried Skype on windows you'd know.


The current iteration of Skype for Linux is a bloated web/Electron app. I really liked the bare-bones interface of the previous version and would have loved to opt out of animated emoji and the other UI changes, but not updating a program that's continuously connected to the internet didn't feel like a good idea.


ghetto-skype is a less bloated version of same, works well, uses way less resources

https://github.com/stanfieldr/ghetto-skype


I just use emacs-slack[0]; my entire emacs usage is currently a fraction of yours.

On X, this means emacs-slack displays images, emoji &c. just like the web or pseudo-native clients do.

[0] https://github.com/yuya373/emacs-slack


I guess this is about to break because of the current announcement?


I don't believe so. emacs-slack uses their official OAuth2 + Websocket integration https://github.com/yuya373/emacs-slack#how-to-get-token-the-...


This is, incidentally, an argument about how a well-designed system like emacs can make writing a truly-native app easy: so easy that some random guy was able to take the API and write a client for a text editor (granted, the greatest & best text editor the world has ever known …).

If it's so hard to write native macOS, Windows, gtk+ or Qt apps — maybe that's a fault of those development environments. Granted, 'display sequences of text, optionally with some images' is kinda in emacs's wheelhouse.


It isn't hard to write native apps, but if you already have a web app, wrapping it in Electron is a lot cheaper.


Correct. emacs-slack uses WebSockets and Slack's Real-Time Messaging API.


Oh great, now every lazy developer is going to write their app on top of emacs and distribute a crappy Emactron version that uses almost eight megs of RAM.

But seriously, how hard would it be for a sneaky dev to make emacs with emacs-slack into a normal person application with clicky buttons and no ugly gnu? Could be worth a lot of money, or at least github stars.


> But seriously, how hard would it be for a sneaky dev to make emacs with emacs-slack into a normal person application with clicky buttons and no ugly gnu?

Well, out of the box emacs has a clicky-button toolbar: https://i.stack.imgur.com/ml0UE.png

And using the keybindings folks expect from Windows is part of modern emacs: https://www.emacswiki.org/emacs/CuaMode

As an aside, I absolutely love the idea of every new app being written atop emacs, but I'm an incorrigible emacs user. I use emacs for email, for git, for slack and (often but not always) for web browsing. Oh, and also to edit text.


I was going to make a comment about using Slack from emacs but of course I'm not the only one. :)


I remember when Slack in a Chrome tab committed 3-4 GB. Sounds like they've made improvements.

Standalone client and its helpers are sitting on ~800MB committed on my install of High Sierra. Might be worth a shot.


For the love of Pete! It's a frigging IM client: 800MB is absolutely not a reasonable amount of memory for it to be consuming, and I don't care how long your message history is.

A big part of why this occurs is Electron. Same with any app that's basically a browser app: memory usage is out of control relative to what the application does.

Case in point: https://arcade.ly/games/starcastle/ (disclaimer: I wrote this). Uses 284MB, for a version of a vector arcade game from 1980. Same issue with my version of Asteroids too: https://arcade.ly/games/asteroids/. Some of this is down to the idiotic way the Web Audio API handles compressed audio, but with Asteroids I have to pre-render a lot of images because canvas 2D performance isn't that great with drawing primitives. Even excluding these issues, and allowing for several canvas layers at 1366 x 768 x 32 bits per pixel, double-buffered, and the thing still seems to consume quite a bit of RAM.

Welcome to the wonderful world of JS/CSS/HTML5 apps.


Preaching to the choir, man. I was just saying the Slack bleeding could potentially be lessened by wielding a slightly different model of chainsaw. I certainly want my gig back.


Use a machine with more RAM then. If your machine doesn't have at least 8GB of RAM then you're doing it wrong.


I can't tell if you are being serious.

RAM prices have plateaued due to production shortages in the past few years, and many (high-volume) $200 laptops/Chromebooks do not come with 8GB of RAM.


Regardless of how much RAM you have, 800MB for a chat app is ridiculous. If every common utility started using so much RAM, "[u]se a machine with more RAM" stops being viable - you can only cram so much RAM in current machines, and if you start peeling off a couple of GB because you need to run more than one chat client that's a huge loss.


That's absolutely gargantuan. How can any general purpose application justify 4G of memory, half of a factory macbook pro's memory.

To put this in perspective, I was talking this week to a developer who was essentially apologising to me for a new feature that was going to require insane amounts of memory. This is for a process to handle literally millions of users.

How much memory was it? 3G. Per "instance" of which we need 2... Again, for millions of people.


I know most of this thread has been about making fun of Slack, but I wanted to write a somewhat serious response to this.

I think "team software engineering" plays a big part of this, if not even the main reason. When one developer is working on a program, the person tends to be able to keep track of program flow, memory usage in their head and know when things are about to go out of bound, memory shoots up, etc. When you have a whole team working on a huge piece of software, each person is working on one part of it at a time. If your feature grows memory usage by 100mb, it's not a big deal. 20 people doing that, memory usage just grew by 2gb. And then in modern software dev shops, you typically put devs on different features on a weekly basis. (unlike traditional, slow, non-agile development where a person owns a certain module/component and is the expert and works on it for years) When you move to a new feature, you need to pick up on all the details of how it works previously, and you build your stuff on top of it. You don't have context of the really nitty gritty details someone who wrote the original framework thought about. You're going to do something less than ideally efficient. Unfortunately, this is just the way modern team software engineering goes.

Or of course, you can still just say it's a Javascript problem and mock JS; which also has merits.


> When you have a whole team working on a huge piece of software,

Then don't freaking do that. There's no reason to make one huge app with thousands of features that justifies teams of dozens of devs instead of tools that do just one thing (and can be used in a modular way) correctly and nothing more.

Actually, there's one terrible reason: the bigger the app, the higher the wall around the garden and that serves as a justification for the price tag. It's the wrong way of doing things because business. It's exactly the same evil principle as the one which is at work when the sugar or the tobacco industry do their slightly questionable stuff.


So when you say there's no reason, you mean that there are business reasons but you disagree with them?


Couldn’t agree more. I see this all the time and it was echoed in that recent popular post by the guy who left Google after failing to get a promotion. Besides the modern software engineering approach this type of work (optimization) is also often not valued by leads. It’s all about visibility. Add new features fast and it’s visible. Good! Fix something, make sure your new feature isn’t hogging memory but take a little longer to complete the work? Bad. Added together no ‘owner’ for any specific part of the app and it’s like the public commons, the person who picks up the litter won’t be acknowledged. The incentives are screwed up. Ultimately though it’s also the customer, if they don’t care (and most of them don’t since Slack is highly popular) then why bother. In a market and business sense that makes complete sense too.


> I think "team software engineering" plays a big part of this, if not even the main reason.

You're not wrong, but perhaps that's an indication that software companies should use language & environments which enable them to have fewer developers, and enable those developers to keep track of things like resource usage?


I think the point godot meant to convey is that modern software development practices disincentivize polishing and refactoring features for performance, as developers move around the application all the time; regardless of programming language.

Whereas traditionally you would have an engineer responsible for part of the application as time goes by, making sure that it works better while maintaining quality.


But then you end up with code sprints solely to optimize resource usage, handled by programmers that didn't code the original module(s). Inefficiencies get layered over inefficiencies.


It takes a lot of memory to slowly and jerkily send plain text over the internet, and not quite keep up with typing when autocomplete-ing usernames, you know. Stop expecting so much of your computers /s


Things like IRC don't support embedded images, so lets build our own protocol with blackjack and everything else! Oh wait, its a slow morass :(


Except; with IRC it's up to your client to do anything it wants.

Want inline pictures? Well, Textual has had that for a long time, irccloud's webUI too.


mIRC takes 24MB!


I wrote an MSNP (Windows/MSN Messenger) client and used it for many years, all the way until Microsoft turned the protocol into a horrible XML-ised mess and then dropped support completely (as in, turned off the servers.) One standalone Win32 binary less than 32KB, usable from Win95 up to Win10; and over all the years I used it and noticed its memory usage, it was never more than 2-3MB. Yes, it had emoji support (though not very large ones, obviously.)

The amounts of memory that users are reporting for Slack are all several times higher than the entire RAM of the first computer I started using my MSNP client on.


I feel like you post is missing:

I had to walk 10 miles to school in the snow! Barefoot! Uphill! Both ways!

or

GET OFF MY LAWN!


Classic version of Skype (with all the "improvements" ) takes about 200-250Mb on Windows XP after long use. Pre-Microsoft versions could take a half of this.


Animated images and emoji can be disabled in the Accessibility settings.

Spritesheets can be disabled under Advanced.

Maybe it helps, sorry I have no before/after but my Slack is sitting at 300MB right now and I deal with an high number of very active channels.


> but my Slack is sitting at 300MB right now

You must be overlooking all the helper processes.


Animated emojis can eat 100% CPU on my MacBook Pro if someone spams enough of them. It's insane how demanding and bloated the app is for what it does.


Yeah, I noticed that too. Except one animated emoji tagged on someone's message will do it for me on a new Macbook Pro.


That's absurd. How is it so high? Mine uses around 700MB pretty consistently.


Are you insinuating 700MB for a chat app is sane?


Implying more like. I see the word "insinuating" misused here often.


Animated custom emojis seem to be a common thread, animated images in general cause my CPU and memory to spike when using slack. Our network engineer loves this dancing parrot emoji but it basically pins a core on my machine and adds 20-30% of memory to slacks process.

I've switched over to using mattermost, it can be (and is) self hosted so I'm not as worried about slack getting hacked (again) and leaking our info/taking control of our systems with chatops.

The downside is; mattermost is not a strong replacement. I wrote a bot to basically do a large part of my job for me, and coding against mattermosts websocket protocol and dealing with authentication has been messy to say the least.

Slack is a joy to code against and use from a UI perspective when compared. (sadly, as I don't like it for ideological reasons)


Mattermost is also an example of how not to license software, including a promise not to enforce provisions of the license they have chosen. If one needs a promise, one has probably chosen the wrong licensing structure.

Here's a fun one: say I use the MIT binaries, then debug a problem by reading the AGPL source code. What legal position am I in? (If you have an answer for that rhetorical question, by the way, you haven't thought of the problem long enough.)

https://github.com/mattermost/mattermost-server/blob/master/...

They launched exclusively AGPL and then made MIT as a concession after discovering that a number of companies outright ban AGPL and won't pay for it unlike MongoDB, but licensing binaries differently than source code is not something you come across often.


I must be slow because I'm not seeing the issue. Can you explain it how reading the source code affects your relationship with a binary you didn't build?


For the curious, there's some history to that parrot emoji:

http://cultofthepartyparrot.com


Perhaps a better source for 'history'[0]

On a side note, Last Chance to See is a great book (Douglas Adams) and show (Stephen Fry), highly recommend both of them.

[0] http://knowyourmeme.com/memes/party-parrot


I wouldn't call that history. I only encountered a variant of this gif once, on a discord channel having the face of one of the two streamers. This site just shows me a lot of very similar gifs.


Towards the bottom it gives a little background, with links to more information.


Gifs, lot of gifs


GP said "basically electron tabs", as in the electron wrapper is functionally equivalent to a browser tab.


Weird, my slack app on windows is currently using 54MB.


Cheeky response w/o actually understanding isn't correct here. Slack's active window sits around that amount on my computer as well, but under the hood it's actually using closer to 670MB with all processes.


Maybe it's closed? ;p


Only Slack can answer that, but considering that Slack is commonly used at many technology companies I'd say that the number is probably reasonably high. I tend to find that software developers tend to have a much lower tolerance for non-native/poorly optimized/proprietary software than most people.


That may be true for greybeards, but I've found the opposite with people of the younger generations.


> I've found the opposite with people of the younger generations

You're talking to one


Well, I'd have to agree with them. My peers are generally happy using Slack, Discord, and other proprietary solutions.

Though I'm not convinced that greybeards are any different, just the ones you find caring about it on the internet.

My dad's a 68-year-old old school embedded hardware developer and he'll use whatever toolkit works. I reckon most people in the world are like him and not obsessing over tools, despite what HN makes you think.


It's not tolerance, it's just that they know who to blame. You're average user is just as likely to blame MS, a virus or their ISP instead of the company making their computer run like a dog.


I sure was using it. And it was actually nice because all of these so-called "features" that Slack has been adding are incredibly annoying and counter-productive. Not to mention that I could use my laptop without keeping the fan on maximum all the time.


I run it in a dedicated browser with one tab only (srware iron). Memory usage: 200mb. Electron crap memory usage is usually 2gb+.


We've built Relay chat (http://relay-chat.com)! And I believe it addresses some of these concerns.

Basically, it is hosted mattermost. We've written our story of how we created Relay by escaping slack: https://medium.com/@deobald/we-created-relay-by-escaping-sla....

There are bux fixes, and feature improvements pouring into mattermost from around the world, and we get them in. We're building integrations, bridging services and other slack features (which will also be open source) into it on high priority.

There's https://github.com/42wim/matterbridge, which provides bridges from mattermost/relay to practically all other messaging platforms out there including IRC, Telegram, Gitter, etc. We're building a SaSS for this too.

Disclaimer: I'm a part of the Relay team.


If they just extended existing standards they wouldn't have to write native apps. We could write them for them.


I'm working on a native client for Slack, Skype and others.

It's only ~100 KB(!)

It will be out of alpha this month.

https://eul.im


I was excited when this came out, but I'm ambivalent about it now. First of all, it doesn't actually solve the issue I mentioned, since it's not actually "native" in the sense I was talking about; it's just a cross-platform Go app. Second, it's not open source, and I'm not sure I'm comfortable trusting such an app with my login credentials.


Same. I'm down to one closed-source software package installed on my machine, zero in regular use. Adding to that number is a net negative. I'd be happy to pay to use it, but not having control over it is just not an option anymore.


> I was excited when this came out, but I'm ambivalent about it now. First of all, it doesn't actually solve the issue I mentioned, since it's not actually "native" in the sense I was talking about; it's just a cross-platform Go app.

"C. There's also some Objective-C for macOS UI."

> Second, it's not open source, and I'm not sure I'm comfortable trusting such an app with my login credentials.

"eul doesn't ask for your passwords and doesn't store them anywhere. Authentication is performed in a browser directly on the messenger's website."


I haven't actually looked at the binary but supposedly it's written in C.

> What language is eul written in?

> C. There's also some Objective-C for macOS UI.

https://eul.im/


> eul is a registered company, and all binaries are signed. Your data is safe.

I see a lot of companies drawing that conclusion from such premise (and you're using C, which really decreases the odds that my data is really safe).

Using that sentence on your main page makes it look shady. Specially if you're not a security company.

IMHO, if you remove "Your data is safe" it will look much more professional.


Skype protocol is proprietary and obfuscated, so I assume that you are going just to pack a browser inside an app.


There is no browser packed :) It's 100 KB.


This looks like something useful, but it doesn't work on MacOS 10.12. Any chance of that happening?


Ah, I guess I messed up with the info.plist file. I'll push a fix.

For now you can run it from Terminal.


Any plans to support Skype for Business?


Yes! It will be supported very soon.


So I've been working on a truly native macOS Slack client for a while, wondering if its time to revive it

https://twitter.com/harisamin/status/727634194814373889

I've posted about it before here on HN but wasn't sure if there's enough interest


For anyone who like me want to keep using slack via irc there's a solution using weechat. See my other comment for more info

https://news.ycombinator.com/item?id=16544045


Thx I was using [0] slack-term up until now when I was using slack from the terminal. Could make a nice addition to my weechat setup.

[0] https://github.com/erroneousboat/slack-term


>I'm very disappointed to see that Slack has decided to go the way of every other messaging service and move away from decentralized and standardized protocols

If every major messaging service eventually does this maybe those decentralized and standardized protocols are the problem.


I don't have any data to back this up, however, I suspect that standard protocols leaving little room for vendor lock in is the primary driver behind the closed systems we're seeing today rather than some inherent limitations open protocols.

(I'm not saying the current open protocols are perfect, or even close, however - 100s of closed chat protocols have been built and rebuilt - that effort would have been better spent in the open IMO. Obviously, investors and similar business functions see things differently though.)


We already know XMPP has issues, but these aren't enough to cause its continual addition to chat apps and then removal. More than likely, the "problem" with these protocols is that they don't help a company's bottom line, engagement, etc.


Everybody here is disappointed at Slack, and I like open protocols and open platforms just like everybody else, but I still have a contrarian view.

Instead of blaming Slack, why not accept that the open protocols indeed suck? IRC does not specify encoding, netsplits are a common issue, file sending sucks, etc. XMPP also has file sending problems, does not play nice with mobile, is fragmented (not every client implements desired extensions), etc.

Why not accept that there are legit technical reasons why existing open protocols are unacceptable?

We should not be blaming Slack so much. If we want to make a difference we must come up with a better open protocol that satisfies all the requirements. And it does not end there: there must also be an open client that normal people actually want to use, and there must be tons of marketing to promote it.

Stop complaining about companies not adopting open protocols and do something. Dominate the world using open protocols, then the walled garden companies will follow. It is not easy, it may even feel wrong, but it is the only way.


There are open protocols like Matrix which are superior to Slack in that they are decentralised, have support for full e2e encryption, entirely self-hostable, don't store your data outside of the home-servers used for communication, etc. Riot is a perfectly fine client (looks just like every other chat application), and there are weechat plugins as well as native applications as well. Open protocols exist, and people are using them, but that doesn't change that Slack dropping support for bridges is just typically disappointing. Matrix also has full Slack/IRC/whatever-else-you-want bridges (which you can stack to talk between IRC and Slack). So there's that.

However, this is simply untrue:

> Dominate the world using open protocols, then the walled garden companies will follow.

When you are Slack Inc and the only differentiator you have is that you are in control of how chat works, why on earth would you switch to a protocol that you don't have full control over?


Slack initially integrated with IRC and XMPP because they were more popular than Slack. Now that Slack is much bigger than all IRC and XMPP traffic combined, the integration is no longer worth its weight in code.

If Matrix were overwhelmingly more popular than Slack, they would integrate with Matrix. But Matrix isn't more popular than Slack. (Matrix isn't even as popular as IRC, despite being a better product than IRC, as far as I can see.)


> Slack initially integrated with IRC and XMPP because they were more popular than Slack.

Bait

> Now that Slack is much bigger than all IRC and XMPP traffic combined, the integration is no longer worth its weight in code.

Switch


sorry, but i don't agree. this is a classic EEE i.e. Embrace, Extend, Extinguish maneuver. which is what, afaik, the gp was trying to say.

edit-001: fmt changes.


I would agree that it is clearly EEE, but would argue that it is also a bait and switch. My intention was to rephrase the gp's comment, which I felt was unfairly positive toward this general practice.


> edit-001: ...

Are you planning very many edits?


Matrix has Slack bridges, so "integration with Slack" isn't a problem from the Matrix side. But more importantly, I wasn't suggesting that Slack should integrate with Matrix, it was that open protocols do exist and some are better than Slack in specific ways.


"There are open protocols like Matrix which are superior to Slack in that they are decentralised, have support for full e2e encryption, entirely self-hostable, don't store your data outside of the home-servers used for communication, etc."

How does that translate to superior communication between my coworkers and I? Most of that stuff does not matter to people.


My point was that the protocol is superior to Slack in general. Whether you have a use for those features is a different point -- those features are clearly already useful to quite a few people.

But to answer your question, self-hosting would be useful in making sure that internal communication isn't shared with a third-party. e2e could also be useful (depending on what you work on) if you want to just use the public servers.

Not to mention that you can use Matrix like bog-standard instant messaging (replacing the need for other messaging applications through bridges), where those sorts of features are also useful.


"My point was that the protocol is superior to Slack in general."

But that's not the point you made. For it to be better in general, it has to improve the way people communicate.


> But that's not the point you made.

I'm pretty sure it is the point I made when I said: "There are open protocols like Matrix which are superior to Slack". Maybe it was badly worded, but the original comment was talking about open protocols being not as good as Slack's protocol (which is why they have their own and aren't use open protocols). My response explained that there are open protocols that are better (in that they have more features), and that Slack not using them is not evidence that they aren't better (rather it's an indication that Slack won't give up the one thing it has full control over).

> For it to be better in general, it has to improve the way people communicate.

I'm not sure I agree that's the only requirement for something to be "better in general". You would probably agree with me that HTTPS is "better in general" than HTTP. Why? To users there is no practical difference other than it being more secure -- which you've ruled out as being something users care about.

Things can still be better while being transparent to most users, while the extra features are useful for a subset of users. Not every protocol improvement needs to revolutionise how people use a particular technology.


> Most of that stuff does not matter to people.

It does matter, you just haven't realized it yet.


I really wanted to like Matrix but it expects you to independently verify the keys for each device every person is using. If they get a new device, new keys to verify.

This is crazy. The keys should be per person, not per device.


Matrix has an identity key that is shared between devices (hence why you can link up the sub-devices). The reason for having per-device keys used for e2ee that you can verify is so that you don't automatically trust new devices if a users' account is compromised. Each new login creates new e2e keys that only persist with the session. In terms of UX this system is currently pretty ugly, but the actual concept makes sense. If you want to just trust that the other users' account hasn't been compromised (which is what having a system designed around a single per-user key would effectively mean) then you can just blindly accept all keys, because each device key is first registered with the identity service and signed (requiring access to the account's identity key).

To be clear, there are several hiccups with e2e at the moment, but they are being worked on (from what I can tell).


> In terms of UX this system is currently pretty ugly, but the actual concept makes sense.

This seems like a trivial gain for lousy UX, since it's possible the account and the device is compromised.


They are working on the UX side of things. I disagree that it's a trivial gain. Signal works in the same way, except that they only really support having a single device (that's where the safety number changing warning comes from).

Having per-device keys also means that the server cannot decrypt your messages (because the identity key is not used for communication, it's just used to register new keys that clients will encrypt their messages to). Having a global decryption key stored on the server would be a less secure design.


Totally agreed that it is crazy; we are working on automatically crosssigning keys between devices, but suffering from rising traffic levels on Matrix meaning that all our effort is getting diverted into fixing scaling issues to keep the bigger homeservers running. Recent funding means that we can increase the paid team to fix it, but we are waiting for folks to serve out notice periods elsewhere before they can start full time. So if you want to help improve our crypto UX please jobs@matrix.org O:-)


This is an example of the kind of business problem Slack is solving incredibly well relative to {chat client X}. Slack's not just a Slack client, it's user lifecycle management, tiered administration, a granular permission model for integrated applications, etc etc etc.

How you solve those problems impacts and is impacted by the messaging protocol. If Slack is going to keep moving fast on features that matter for businesses, they're likely to keep needing protocol features that wouldn't necessarily be the priority for an open standard.


This is an example of the kind of business problem Slack isn't solving at all. Or did they add e2e encryption recently?


The people who pay aren't asking for E2E. They're asking for auditable shared history. We're in a forums of tech nerds, outside of our bubble encryption is pretty low on the feature totem pole.


How do explain the rising usage of Telegram/WhatsApp/Signal, if encryption isn't important to people? I find that most people actually do care about their privacy, but they want it to be made easy for them as well.


I know plenty of people using Whatsapp and no people caring at all about its approach to privacy. I have not heard of those other two platforms outside of privacy-obsessed communities. Are real usage data disproving my anecdata?


AFAIK Telegram has a substantial user base in Russian speaking countries, Iran and cryptocurrrency related communities. Although I think that's mostly thanks to their successful marketing rather than offering any real privacy/security.


> When you are Slack Inc and the only differentiator you have is that you are in control of how chat works, why on earth would you switch to a protocol that you don't have full control over?

The GP is calling for a slack competitor to launch and gain popularity with the help of an open protocol. Once the pendulum swings back towards openness, Slack would be forced to adopt it to stay relevant.

If you value your freedom, use the open source RocketChat, instead of Slack.


The majority of my comment was talking about Matrix, which is an open protocol with free software server/client implementations.


Yeah, but they're not that different. They use their own protocol and their flagship client is a web/electron app.


When you put it like that, sure. But Matrix is federated (sort of like IRC but it's "open federation" in that any room can be shared between home-servers) and has e2e encryption. Rocketchat has neither of those features (though it is nice and simple if you just wanna throw up a chat server at a company -- which is the main purpose of the project as I understand). If you want to talk with other people then I would recommend Matrix.


Is there a weechat plugin for Matrix that currently supports e2e encryption? Last I checked, it was using an older version of the encryption that was not compatible with recent Matrix servers.

I would love to use weechat for Matrix, as I'm not a big fan of the Riot client.


Not yet. The older version hasn't been updated to the version which Matrix actually uses these days, sadly.


While i like folks from Matrix i actually tried to integrate my messaging platform with Matrix and failed. Matrix API is sooooo sophisticated, they are doing something to simplify this, but all this at alpha stage and too opinionated to use it universally. Even XMPP is better in terms easy of use without mentioning IRC (that is dumb simple).


Here's the fun part: eventually slack's going to have the same problems it complains about these protocols having. Some new platform can't run the same client as usual, so they write a new one that has a slightly different feature set. And/or some clients can't be upgraded.

"All of this has happened before and will happen again."

I'm completely unsurprised. The integrations were there to reduce customer risk in choosing slack. Now that slack is big enough, they don't need to do that anymore. Those integrations can only let 3rd parties into the party that slack wants all for themselves.

Shit like this is why IRC is still so popular.


> XMPP [...] is fragmented (not every client implements desired extensions), etc.

How much I hate this "X is fragmented" argument. When two pieces of software that speak a common set of core protocols and thus can achieve at least some level of interoperability, but there is no perfect feature parity, then OH HORROR, IT IS FRAGMENTED!!1111 The obvious solution? Use a product that does not interoperate with absolutely anything at all ...

Next people are going to claim that you should learn some random endangered language instead of English to avoid the "fragmentation" due to the numerous dialects, I guess.


"The obvious solution? Use a product that does not interoperate with absolutely anything at all ..."

You mean use a product with a baseline feature set where you can count on all the clients seeing things the same way and supporting the same thing.


Sorry, but that is just obvious flat-out bullshit.

Have you tried using Psi (an XMPP client) to communicate with a user using the Slack client (well, after this change, obviously ...)? Did you have any success with that? No, of course not. In other words: Slack is obviously not a product where you can "count on all the clients seeing things the same way and supporting the same thing.". Slack works with exactly one client at the other end, so it is bullshit to claim that it "works the same with all clients", when in fact it works with exactly one client, and that's it, with other clients you get exactly no interoperability at all.

And it is bullshit squared to pretend that that is somehow an advantage over other technologies: No single client using any protocol provides an inconsistent featureset or interface. It doesn't matter which single client and which protocol you use, you will always get a consistent featureset and interface. That has absolutely nothing to do with Slack, but only with the fact that you standardize on one client.


Most people using Slack are using the Slack client. Therefore, yes, I can count on there being a baseline.


OK ... and now, can you tell me about a Psi user who is not using Psi?


Yes, let's stop using Linux entirely. Everyone uses different versions, it's too fragmented and can not possibly be useful to anyone.

A proprietary platform where everyone the same product with identical feature set would easy out-compete it. It is apparent that the cloud is obviously betting on the wrong horse.


Netsplits apply to networks, not gateways. From Slack's perspective, supporting IRC is relatively simple: send messages in UTF-8 and "send" files by sending the URL that Slack's uploading service produces.

IRC does have a lot of deficiencies, but they're well-understood and the client environment has adapted to them.


> Why not accept that there are legit technical reasons why existing open protocols are unacceptable?

I can think of a few features, in a few open protocols that started out as "open" but proprietary - https://en.wikipedia.org/wiki/XMLHttpRequest being the most well known.

> Stop complaining about companies not adopting open protocols and do something. Dominate the world using open protocols, then the walled garden companies will follow. It is not easy, it may even feel wrong, but it is the only way.

This, this is sage advice, this is what needs to happen, and we need to just take the time to do it. I am at the point where I think I'm ready to become a Stallman like zealot in my almost golden years.


You want IRC to have a kitchen sink. But IRC is perfect for it's intended scope. You get to use whatever other service you want for sending files or sharing images. All you have to do is link to it.


The attitude of "you have a link, that's good enough" is a silly one. What about file metadata? Who uploaded it? What's their identity in the chat? Because there's no threading in IRC, you can't have a discussion about files/links that persists separate from the channel. Even if you make a HEAD request for every file, what if I want to see the page title of the link or a thumbnail of a linked video or image rather than downloading it?

If we keep the attitude of "IRC solves all the problems it intends to solve," then the number of users whose problems are addressed by IRC shrinks more and more over time.


In addition to sucking in technical ways, the current set of open protocols probably could stand to leave more room for innovation. Chat is a really hot area in the industry right now, and people are trying all kinds of different things with it. Team-oriented stuff, smart threading, different forms of addressing (find people by mobile phone number instead of account name), and plenty more I'm not even aware of. An open solution would have a better shot if it has a way to not only solve problems well but also evolve and incorporate new features and ideas.

Another issue is that social platforms serve as a unique kind of directory service. It turns out that how good a chat system is at allowing you to find contacts to chat with might be just as important as how good it is at actually chatting with them.


I don't think it matters that much. Open protocols are typically in for the long run, and will end up replicating the feature set of the most popular proprietary ones. And the best thing is that they are generally free to pick the best ideas from various places.

One issue is adoption, but this is something that can be dealt with eventually.


IRC is not at a standstill mind you. IIRC these days it specifies UTF-8 as encoding[1]

[1] as specified somewhere here https://ircv3.net/


Why not make your protocol open source so the world can benefit, integrate and improve upon it? If the current open standards suck, there is no reason we can't create new, better open standards.

But, I've never used Slack nor would use it as I'm biased towards it's prop nature, especially when it's used (and even promoted) within open source communities.


I'm fairly certain they're not Slack, so they couldn't do that.


Why don't you evolve slack into open protocols? Oh that's right, that's your IP. That is the reason you walk away from protocols and implement 'safer', 'reliable', 'augmented' closed source options..

Your time could be spent on open source, so don't claim that open source walked away from you, when you're the one doing it.


I don't think the person you're responding to is the one doing it.


Open Protocols usually come about either because the world needs something like that, so multiple companies work together on a standard; or because volunteers take on the work.

Volunteers don't have the marketing budget or, even the technical budget to compete with slack.

It's basically a non-starter unfortunately; and when they do come around (XMPP with push and decent extension is not bad) people are so hung up on the first implementation that they won't look passed previous shortcomings. It's easy to tar something when it doesn't have a marketing team behind it.


> come up with a better open protocol that satisfies all the requirements. [my emphasis]

Yeah, no. The email/xmpp approach of small core + extensions is probably the only viable way.

I've played with both rocket.chat and matrix - and while I don't really like the architecture of the former, it feel a lot more like a finished solution/product - with a sane api.

I hope Matrix will become more relevant, but I think the documentation and implementation suffers under the design ambitions.

In a certain sense smtp, imap and irc all use telnet for transport (and all can be augmented with ssl/tls). That's not a great choice today - but there seems to an odd resistance to combining "the good pieces we have". Maybe just demanding ssh as the (client/server) transport, for example. Use srv records for discovery. Use capnproto for serialization. I don't know, but there seems like there's and odd resistance to reusing great components that are easily tested and developed independently.

In that sense the slack/rocket mission is easier: be compatible with yourself.

(and using https+json for transport / rpc is perfectly valid re-use. But a promise for stable apis and a clear split between client and server (rather than client+server | bots (ie: non-Roman clients) would be nice. Allow people to bring their own server, or client or both.


Agreed. I have never had as good of an experience with IRC or XMPP as I have with slack. Open protocols are still great for open communities, internet discussion boards, etc. but when you're a multi-billion dollar messaging platform and companies are using you for critical communication I don't see any reason to continue supporting them. They've actually gone a step further and put the accessibility features in slack and upgraded their api to support things people used to do on the irc channels.


IRC is right now standardizing reactions and threads. As I linked elsewhere in this thread, IRCCloud now runs their own slack gateway for their users, with support for all of it: https://twitter.com/irccloud/status/971416931373854721?s=21

It's absolutely possible to provide all this in open protocols, and even in a reasonable timeframe.


> I have never had as good of an experience with IRC or XMPP as I have with slack.

Interestingly, I've felt the opposite way. Slack will often lose connection, fail to send messages, or fail to refresh and fetch new messages (ones I know exist, because I was sent a notification for them). IRC and XMPP don't seem to do this.


All valid points, but this makes me sad:

>and there must be tons of marketing to promote it.

It used to be “build it and they will come”. Open source projects don’t have millions to spend on marketing.


That is false. It has never been "build it and they will come". Open source projects do need to spend millions on marketing. They just aren't necessarily paid for in money or by a single party. The Linux hype of the late 1990s came from the effort of thousands, tens of thousands of advocates who devoted their free time (which costs money). And just look at any popular devops tools today -- the most popular projects have very slick-looking websites and organize tons of community events, all of which cost time and money to implement.

This is what I mean by "it may feel wrong". We developers like to buy into this fantasy of "build it and they will come" but it has never been true.


email is an open protocol and works great. you can add pgp on top of it if you want security


> you can add pgp on top of it if you want security

Nobody does, sadly.

Baking it into the protocol like Signal and WhatsApp did means nobody has to want it, they just get it included without having to bolt on any extras.


But what Signal and WhatsApp has is not PGP. Not even close. It turns out security isn't trivial.


It is a cheap substitute. But you should try the cheap substitute: its not half bad and lots of people seem to find it pretty tasty.


Email does many things, but "works great" isn't one of them. PGP even less.


I'm not sure why this is getting downvoted. I love email and I'm sure I'll be using it in the retirement home. But it is not very popular among the youth:

https://techcrunch.com/2016/03/24/email-is-dying-among-mobil...

And there's good reason for that. Email is basically the electronic equivalent of postal mail, a first pass at digital communication that aped the old medium. But the first email RFC was 35 years ago. MIME is more than 20 years old, and that's the last major capability improvement.

From the point of view of a teen who grew up on Facebook Messenger, Snapchat, Instagram, and Twitter, email is weird, old, and feature-deficient. They think of email in the way that I think of paper mail (mainly for formal and commercial use, not really for friends, somewhat quaint), or possibly how I think of a fax machine (quirky, obsolete, use only when forced).


E-mail is not preferred by the youth until they use it at work. Then it is a godsend that you can only ignore it and reply when you have time.

We have been chatting since we have had networks. Believe me, e-mail is here to stay.


Maybe we could do something about voicemail then?

ducks


What do you mean? Voicemail was never successful and the reason is simple: verba volant, scripta manent, spoken flies, written remains.


Voicemail was very popular in the US for an extended period. Email becoming popular helped reduce that; so, later, did texting, especially once we got past the T9 keyboard.


The only people who leave me voice messages in 2018 are unsolicited job ‘recruiters’ here in London. It’s guranteed when I have a voice mail it’s them, like it’s 1998.


I'm currently in a country where access to social network sites like facebook, instagramm & twitter is being blocked for two days due to political issues (Sri Lanka). One fellow travel (21yo) does not know how to reach out to any of his friends and family besides using facebook & whatsapp. Sadly, he didn't even think of using email to reach out, even though everyone has one. Can't blame him for not knowing about VPN and TOR. So, reality is that we're (still) living in times when a simple, reliable and independent service like email does have it's advantages and can be very useful from time to time, esp when travelling or when politics change.


What doesn't work great about email? easy to use, easy to set up, easy to modify, easy to switch which software handles your email both server-side and client-side....


Has a huge spam problem...


But people posting tonnes of GIFs, emojis, and tagging @all on #general isn't spam? I don't disagree that email has a spam problem (though spam filters have gotten quite good in the past 20-30 years), just that spam isn't an email problem.


You can easily choose to be not be a part of that. You do not have that luxury on email.


You know you can filter email based on the content, right?


It's trivial to ban someone from Slack. The problem with email is how there's no authentication for incoming mail, and it's trivial to spoof the sending address so you can't block them. Sure spam is a problem on most platforms, but unauthenticated ones have it orders of magnitude worse than authenticated ones.


> The problem with email is how there's no authentication for incoming mail

TYL: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail and https://en.wikipedia.org/wiki/Pretty_Good_Privacy


That's mostly a client problem than a protocol problem. Any mail client with a workflow for whitelisting contacts would stop spam immediately.


Every submission system has a spam problem. How is email any different?

I'd actually argue that email is one of the better systems, as I can manage and control my whitelist/blacklist myself. It makes things much more functional that way.


> netsplits are a common issue

This is a server software issue, not a protocol issue.


"Instead of blaming Slack, why not accept that the open protocols indeed suck?" said FooBarWidget to the world, via TCP/IP, DNS, HTTP, HTTPS...


Of course they do. This is exactly the path Google took. Once you achieve enough power in the market, you can throw open protocols overboard.

It's a symptom of the centralized world the internet has become.


Yeah, I don't want to be a downer, but this is pretty much the exact definition of Embrace, Extend, Extinguish: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...


Google is the new Microsoft. We all need to get comfortable with this idea, and fast.


i thought it was old news that google isn't cool any more


Did Slack ever really embrace and extend IRC and XMPP though? It always seemed to be some kind of hack to get your messages there to begin with.


The IRC gateway was there to mollify people who said "IRC is better! I refuse to switch!"

Slack advocates could say, "Don't worry, you don't have to switch. You can just keep using your IRC client with Slack. Everybody else will have a web UI, which they prefer, and you can keep using Irssi. Everybody wins."


Right, and now that everyone is hooked the loud minority (if we're being honest with ourselves) have to choose between speaking the Slack protocol or losing access to our contacts.

Are we doomed as a community to be surprised every time a company with power squeezes?


Embrace IRC. There are some excellent IRC clients, such as IRCCloud[0]. With web & mobile versions. I'm on IRC all the time, and there's still lots of good stuff there. I've been an IRC user for 15 years, and haven't lost any contacts due to arbitrary corporate decisions.

[0]: https://www.irccloud.com/


You are, as long as you give them power by continuing to use proprietary software and protocols.


My understanding was Google supported XMPP until a few companies including Microsoft only allowed their integrations one way and then abandoned it as they felt they were opening themselves up to being exploited rather than pushing an open standard.


They could have made two-way integrations mandatory and block organizations who did not comply.


Right, so eventually they'd block every major organization and then it's practically the same as abandoning XMPP federation. Commercial incentives just don't align with XMPP, that's the underlying problem.


How would that explain Email?


Email could never come into existence today. It only survives as a difficult-to-dislodge remnant of an earlier, more open, more idealistic Internet.

Loads of companies (including Facebook and Google) are trying to "fix" (read: kill) your email inbox.


XMPP support did very little to grow whatever power Google has in the chat market. Traffic to federated services and use of third party clients was low.


It really sucks. Apple did the same:

https://www.appleworld.today/blog/2016/8/8/hey-apple-any-pro...


It was not Apple's choice. You should do some reading on the topic.


Companies are just using Micro$oft's playbook. Oh, and spoiler alert, Microsoft still is too:

https://wiki.debian.org/InstallingDebianOn/Microsoft/Windows...

Embrace / Extend / Expunge


So how exactly do you expect running Debian/other Linuxes on Windows will extinguish them? I don't really see a way for that to happen.

Sure, the Linux subsystem is "Embrace", but a lot of things can be embraced without extended or extinguished.


An obvious way this can harm Linux is by giving junior users coming from a windows environment a way to do much of the things GNU/Linux can do - even if it's potentially inferior (would they even know?) - without actually becoming a user of anything running the Linux kernel.

Do you expect the Linux kernel to continue being runnable on contemporary laptops if decreasing numbers of users are even attempting to boot it?

The same thing happens with Docker on Windows in the datacenter. If users embrace the MS offering, and it runs their Linux containers, there will be less resources going into Linux kernel development from the server world.

Google going the fuscia/zircon or whatever it's called now route further diminishes the resources put into the Linux kernel.

I don't think there's any reason to reject the observation that there's a lot of competition in this space and a number of these moves substantially threaten Linux's relevance in the long-term.

The exodus of users to OSX has already been quite harmful to GNU/Linux's progress on the desktop. If it weren't for Intel investing so heavily in Linux kernel development I don't think we'd have modern wifi or gpu support, not from the community alone.

Much of what I describe above is the Embrace phase. Once a sufficient number of users are running their Linux userspace components on proprietary underlying kernels, the relevant companies can start investing in "improving" userspace in incompatible ways only their kernels implement - perhaps in patent-protected ways - Extend. Voila, you're locked in. And since the Linux kernel wouldn't have the development resources it once had, it just falls behind into obsolescence.


You post implies that you're officially affiliated with Slack. If so, are you really comparing yourself to "Micro[s]oft's playbook"? Why can't you work to fix the issue rather than follow the industry standard?


looks to me like they just copy/pasted the MOTD from an irc client that connected to slack's gateway


Ahh, I didn't recognize that. I had just thought they formatted it that way to seem cute.


Well, another day of being disappointed by Slack.

Aside from missing native clients mentioned in other comments my biggest pain point is their awful implementation of threads. Every time I think: They must be kidding, they can't be serious, that's just a bad dream. A few examples:

- The only place where you get noticed about responses to threads is the "New Threads" view, which makes it easy to miss responses, when you have responses to multiple threads waiting to be read.

- While having the "New Threads" view open, new messages aren't shown automatically and you have to click a link to show them.

- "Threads" for snippets and files are displayed directly in the channel the snippet/file got posted in.

- You can't post snippets and files in Threads.

- You can't use "/me" in Threads.


Slack threads are like a bad version of email built into an OK IRC client.


yeah threads are fucking terrible. it's a shame there's not a way to just turn them off.


Oh wow I'm glad I'm not the only one who hates the threads implementation. It's an awful user experience!


Great, I feel like an idiot. I advocated slack, because it granted the freedom to choose a client. Now I helped lock-in others.

Suggestions for alternatives, that I could migrate to? The requirements are: mid sized teams, desktop and mobile, all major os. People used web based client, native clients, irc gw, and bots. We need search and archive. Self-hosting is an option.


Take a look at Matrix. https://matrix.org/


Hey, I just wanted to say that it is brave of you to admit to making this mistake. I would have been one of those protesting your advocating, imploring, perhaps loudly, to consider the consequences :)

Anyway, yeah, a lot of us are now looking for practical solutions to this very unfortunate and serious problem.


IRC, with web clients like IRCCloud, TheLounge, or IRCAnywhere.


Everyone needs to have their trust betrayed once to understand what it means to trust.


Zulip. Open source with IRC gateway and bots. Most importantly a threading model that lets you tame the firehose making it far superior.


Prosody+Kaiwa

Prosody is an XMPP server Kaiwa is a web frontend that works really well with it. For a quick "try it out" Kaiwa makes a docker image that bundles prosody.

There are lots of bot options. Conversations is the android client to use. There are no great iOS clients though.


https://wire.com/


rocket.chat is the best alternative


On paper I like matrix, or prosody (xmpp/jabber) with extensions (ditto irc + logging bots etc).

But after looking a bit at rocket.chat along with the api - it's hard to recommend something else as a self-hosted, open slack alternative.

I'm not enthusiastic about the stack/mongodb dep - but boy is the api nice and documented, and their docker-compose a joy to get started with:

https://rocket.chat/docs/installation/docker-containers/dock...

https://rocket.chat/docs/developer-guides/rest-api/

[ed: oh, and there's a hosted option and you can pay if you want. I think that's also a big plus]


Out of curiosity, have you looked at Mattermost? How does it compare? About three years ago when open source Slack alternatives were starting to hit, Mattermost and Rocket.Chat were the top options. GitLab even ended up bundling Mattermost with their Omnibus installer (and were going to bundle Rocket.Chat as well, had they made it possible to support Postgres, but I don't think that's the plan any longer).


Not really. I'd prefer matrix (open protocol, federated) - but I seem to recall after reluctantly accepting that rc is a great product, I had a look.

And that bundling code inside a mysql container felt like it fell well short of the simple rc setup of db+app via docker compose...

https://github.com/mattermost/mattermost-docker-preview/blob...


To be frank, you should feel like an idiot. This was entirely foreseeable and people have been warning you not only about Slack, but about proprietary software and vendor lock-in for _literally decades_. Try not to make this mistake again. Advocate for free and open source.


> After years of evolving, Slack is at the point where the gateways can no longer handle all of our features or security needs.

Oops. They misspelled "where we are dominant enough that we have more to lose than gain by being able to interoperate with our competitors."


Demerit. These idiots need a few more hundred million dollar financing rounds to figure out how to use the rest of the RAM on my computer.


For weechat users, there's always the wee-slack plugin [0] which runs on the Slack API, rather than the IRC gateway.

[0] https://github.com/wee-slack/wee-slack


Does anyone know if there is an equivalent for irssi?

Perhaps it's time I give weechat a try :/


I've yet to find one, which is unfortunate because I am a much bigger fan of irssi.


It's certainly possible using BitlBee - https://www.bitlbee.org/

But as far as I can see nobody has written a Slack-API plugin for it, yet.


wee-slack is the reason I switched from irssi to weechat. Sad, but true.


Is Slack the Platform where you can have multiple accounts with the same displayname? A bit surprising to hear them talk about security


Yes: https://twitter.com/SlackHQ/status/970732100201697282?s=19


I was already against Slack out of principle, but this is pure madness. Their justification boils down to "some people want to".


We encountered this the other week. I didn't realize this was even a thing up until I saw it happen. It is sort of mind-boggling that they allow this. It was confusing to troubleshoot.


WAT? How does that go, if I try to message @username, where does it go then?


Display name != Username


Yeah they really dropped the ball on this one


I didn't know this was possible. How does it work with SSO authentication? I suppose enterprises can force display names?


To answer myself, yes, SSO plans can enforce display name uniqueness.


This thread need more visibility!


Ah, the good old "just when I began to think Slack is pretty decent after all", still remembering fights with Windows office communicator and others.

The reason I use the IRC gateway is primarily to cut down all the extra crap except textual messages, and to be able to message from the console without having to switch windows or launch web pages (I run irssi 24/7 under tmux). This has been a nice sweet spot, with the improvement of seeing message history as well.

The trend for things built in the 10's seem to be constant change and fear for shutting down. Conversely, IRC from the early 90's still works fine. IRC is like water pipes. It doesn't come with flashing lights but it does what it needs to do, does it reliably, and nothing more. And you can buy bottled water in various flavours but if water pipes didn't exist life would be far worse.


It seems that there is an increasing trend from Bay Area tech companies (maybe tech in general) to bootstrap by taking in users feedback (twitter RT feature), get to a certain size, and then totally abandon their base.

To an extent this makes sense, like if there is a new company CEO who has a different vision, etc. But many of these decisions-- dropping Google Reader, the trend to ditch the headphone jack, and now Slack killing IRC-- seem to be made for no apparent logic reason, and giving some bullshit excuse like "security reasons."

Is this driven by data? If so, why don't they release the data and show us? Alternatively, in a free market, the way to best compete is to offer more options to your customers, unless you've attained a semi-monopoly, or have some kind of trust agreement.

Is it that difficult to maintain these things? Apple and Google are among the richest companies in the world, and Slack just raised $250 million. Given that not only are all three features I'm discussing established and probably only need occasional maintenance, the headphone jack has been around for over 100 years. It's not like they need new science breakthroughts for it.

None of it makes any sense, unless the entire Bay Area has gone Dilbert.


> It seems that there is an increasing trend from Bay Area tech companies (maybe tech in general) to bootstrap by taking in users feedback (twitter RT feature), get to a certain size, and then totally abandon their base.

You should read the book "Crossing the Chasm". This strategy actually makes a lot of sense if you want to be successful. Summary: your early adopters are not your main customers, and there is a divide there. You will hit a ceiling in growth if you continue to focus on the early adopters.


There's a difference between focusing on people and completely abandoning them. One of the reasons many people (myself included) are leaving Twitter in droves is because Twitter has made changes which betray its original community.

In fact, at this point I would argue that Bay Area tech companies are actively hostile towards the people who helped create them. To use Twitter again as an example (because they have done so many stupid things), to come out with the ridiculous "we decided to change likes to hearts" icon crap when many, many people were crying out for some solution to the rampant abuse on the platform, was not just a lack of focus, but a show of active contempt.

One of my biggest criticisms of the growth model (in part championeered by YC) where you focus on getting users first and then figure out how to make money, is that it almost always leads to this sort of betrayal. This is also the general problem with offering "free" services to bootstrap things. There was a period of several years where some of us (again, myself included) were outright begging Twitter to let us pay for our account. This happened again with Ello, and when they took VC money I lost all trust in them.

When you have an entire paradigm of companies that are following this strategy as proposed, over time people will see a pattern, and when a company practises the first steps in that pattern, it's not hard to see where it leads. As a result, I'd argue it leads to an erosion of that initial base, and therefore companies in the future will not be able to bootstrap in the same way.


> But many of these decisions-- dropping Google Reader, the trend to ditch the headphone jack, and now Slack killing IRC-- seem to be made for no apparent logic reason, and giving some bullshit excuse like "security reasons."

Google Reader didn't bring Google more money, even indirectly. Removing the headphone jack leads to less cables and less open holes in the device. Slack's IRC gateway wasn't very good, and nobody used it, plus its existence allows easy circumvention of some paid tier features, like logging.

Everything has a reason, even if you might not like the reasoning.


> Google Reader didn't bring Google more money, even indirectly.

Was there a way to pay for it? Further, even if a feature doesn't bring money, does it cost sufficient money to maintain to merit removing? Why not just open source it and let the community maintain it?

> Removing the headphone jack leads to less cables and less open holes in the device.

The stated excuse for this was to allow the system to be thinner. By "less cables," do you mean inside the device or outside it? For inside it, I don't know, for outside it, it has lead to all kinds of drama, such as for professional musicians who have expensive equipment that used the classic jack.

Further, it's clear to me Apple was not confident it was a good idea by the fact they included the lightning jack->headphone adaptor for free. Regarding "less open holes", don't they have waterproofing technology already? One of the big arguments I've seen that makes more sense is that by forcing audio through bluetooth or through the lightning port, they are able to push DRM. Unsure what I think about that.

This also doesn't explain why other places, like Google, are following suit, much to the dismay of their customers.

> Slack's IRC gateway wasn't very good, and nobody used it, plus its existence allows easy circumvention of some paid tier features, like logging.

I use it extensively, and a quick persual of twitter (and this comment section) shows I am not alone. Further, if "nobody used it", then why would "circumvention of some paid tier features" matter, if nobody is doing circumvention?

Now I have to make the decision whether to have a tab open, which from past experience will suck up about a gig of ram and be generally sluggish, or to use their native app, which from what I understand is basically an app wrapper around Electron and is even more sluggish than the non-app.


On some further reflection, it seems that the "paid feature for free" argument could translate into "security", and thus explain Slack's strange messaging. That is so far the most logical explanation I've heard. Thanks for helping me understand!


I see Slack is now big enough that they can stop pretending to care about interoperability, and essentially pulled a Google Talk on us all. Fool me once, shame on you. Fool me twice, shame on me.


It looks like IRCCloud has done an API based integration which is then exposed again via their own IRCv3 system: https://twitter.com/IRCCloud/status/971416931373854721


That looks super interesting. That might be the reason to finally push me from self hosted znc to irc cloud.


Surprising absolutely nobody, private company closes access via open protocols with 3rd party clients.


The IRC gateway was the only thing that made slack even barely usable for me.


This currently seems to be the only successful business model. Give something for free to get traction. Then slowly erode the free part, and try to get as many people as possible to run on the subscription treadmill. In most situations open source, open protocols and open data formats are an anathema to the cash register going ka-ching. When you start spending other peoples money, they are sure to remind you of this simple fact.


This change, if it goes through, means I will disengage from Slack other than passive browsing from their Android app. My teammates will have to remember how to read email if they want non-trivial input.

It feels like a mixed blessing though, as it is a nice excuse to detox from this mess.


Well email is due for a comeback.


This is good news for me.

My company was considering Slack - the only reason it was agreed was due to the IRC gateway.

So it looks like slack is out of the question now.


What are the other candidates? What's your criteria?


I remember mIRC at this moment. It let an entirely new internet generation connect easier, compared to the chat clients of its' day.

Slack still strikes me as a modernized IRC client at heart. Today's IRC client. Discovered by a new internet generation with today's integration trimmings.

Let's look at IRC rooted technologies as waves of improvement for a moment. Platforms are guaranteed to come and go, no matter how big. Protocols seem to survive.

The need to chat will remain. Protocols like XMPP are important for this reason. Developing XMPP quickly as private protocol builds should be a worthwhile undertaking. XMPP innovation is something I should go learn about more, though.

No one platform can be the entire ecosystem. They all try. Maybe it's vanity, or a little insulting to create digital wells of content that the odds say will shut down one day.

A step like disconnecting is a challenge for that reason. It will invite lots of people to look elsewhere, trying to find how it should be.

It's not unreasonable to provide a limited subset of messaging features with via IRC/XMPP. It doesn't seem unreasonable to improve XMPP itself either.

I'm perfectly comfortable with a business strategy argument and wonder if Slack isn't looking long enough. Taking a 50-year vision might actually be better if something like XMPP interoperability and evolution remained to outlast everyone. Leaving the garden nicer than you found it, when possible, isn't always a bad thing.

Due to this walling of gardens, my phone has no less than 8 or 10 chat apps silo's I can't avoid. (Skype, Hangouts, WhatsApp, Slack, SMS, Messenger, etc.). To all chat visionaries, none of you are that important. I would replace you all in a heartbeat with something that had a longer shelf life.

The tech that keeps integration and interoperability are the ones that I care about most.

Tools like Pidgin or Trillian connected the worlds of MSN Messenger, ICQ, aim and IRC. Connection and connectedness is blissful for a reason - including across platforms.


Step 1: Build your initial product on open technologies, harvest goodwill of enthusiastic people

Step 2: Become popular and highly profitable

Step 3: Ditch openness of your platform, implying your initial supporters were just useful idiots


As much as I hate to admit it, I was android's useful idiot. I seem to have learned from my mistake though. I never bought into systems controlled by commercial entities afterwards.

Unfortunately, the pool of useful idiots doesn't dwindle with each cycle iteration since there are always a new batch of idiots willing to take the bait (and attack you if you voice your concerns). So this strategy won't loose its effectiveness. Expect to see many iterations in the future :(


Okay, I get that IRC isn't able to convey lots of modern fancy stuff, but XMPP? Really? I swear, it can do almost anything that fits into stanza exchange logic, as long as one's not afraid of adding an XML namespace (of course, it's being nice to search for already existing XEPs first). Afterwards it's client developers' problem to support shared threaded animated gif sticker emoji reactions or whatever.


> Afterwards it's client developers' problem

Riiiight. And how many clients do you know that have that? Or read receipts? Or file sending? Or... Or...?

There’s basically just one client that supports modern XMPP features. So no, it’s not the client developers’ problem. It becomes the end-users’ problem. And they will abandon XMPP in favor of solutions that don’t have tgat problem.


XMPP is a protocol. Slack's own RTM API is a protocol. It was claimed that the former cannot be extended but the later can be - which I argued is wrong.

Now you're arguing about something completely different. It's not like it's a death sentence if some RTM API-consuming app is not capable of something - why does it suddenly becomes an issue when we switch protocol to XMPP?


Because Slack both develops the protocol, and provides apps for all platforms that support all features in this protocol.

There’s exactly one XMPP client (Conversations for Android IIRC) that supports all the XMPP features (many of them in still experimental XEPs) that make it barely suitable for a modern mobile-heavy world, much less for anything else.

So yes. When you say it’s developers’ problem to develop clients, it’s not. It immediately becomes the end-users’ problem.


The one problem I had with the XMPP gateway is that it would lock up my client for several minutes while trying to connect. I don't have that problem when using the IRC gateway.

But at least I didn't have to deal with inline images and animated gifs over the gateway.


This is disappointing.

Why isn't there a public blog post about this? Why is the "more information" page behind an auth wall?


If you were Slack, would you post a blog post about this? It's clearly a negative, so there's no point in drawing attention to it.


You know why.


I was about to set up a native xmpp/irc client because “Safari reloaded this tab because it was using too much energy”

sigh Richard Stallman was right. Again.


Is there a specific list of IRC's deficiencies somewhere? Could we start on an IETF draft to address some of those rather than throw our hands in the air and build yet another walled garden?


One potential problem with that is that for many IRC users, many of the "deficiencies" either don't matter or are bonuses.

Also, see https://ircv3.net/irc/


Well for starters IRC doesn't let you keep your hands warm when somebody posts a giphy and your system resource usage goes up to crypto mining levels.


I don't rely on slack at work (we use mostly emails and some skype), I'm also part of a small-ish team, so I have to ask: do people in bigger-ish teams really send gif after animated gif in their work-related slack conversations? And if the answer is "yes", what does that help accomplish?


The more your work chat resembles an attention-addiction-skinner-box social media, the higher engagement numbers it gets.

It's relatively easy to see how these engagement numbers can be leveraged as a sales tool.


1. Yes, they do. We even have a bot to post the top giphy result for a search query.

2. It's absoletely as assinine and distracting as you imagine.


The matrix protocol has already emerged as a successor to IRC that maintains backwards compatibility. It has room encryption, voice and video, and it bridges to almost every chat service in existence (including Slack, at least until now).


Matrix isn't backwards-compatible to IRC, it has bridges for IRC. Also I believe the Slack bridge uses the Slack API (not the IRC gateway) so it should still work when Slack kills the IRC gateway. But yes, Matrix is quite amazing.


https://ircv3.net


This is super shitty.. the only reason to use slack was that you could escape from the shitty web/electron crap. Good bye slack.


I just recently started using slack and that's because a) of the irc gateway, b) people expressed interest in me connecting to a few "rooms" (I don't even know the slack terminology for room). Yes it's always peer pressure from the ones that know "better". It's sad that I 'll have to disconnect from those rooms and it's even sadder that I did not stand my ground but rather gave in and connected to slack. At least I 'll have the consolation I was right I the first place. Bye slack. You will NOT be sorely missed.


I'm honestly looking forward to a worthy competitor. Slack has literally been slacking, I haven't seen any noteworthy features in 2 years. And we still don't have a proper client imo, can we please get a native one with some more progress?


Came here to say this.

I was on slack in 2015, took a break and came back in 2017. Nothing changed - no new features, and yet it was less reliable than I remembered.

They aren't even up to date on emoji. I just can't find symbols I expect to be there. Talk about low effort. And yet they had time to redesign the ones they did have (and the new ones are fugly).


> After years of evolving, Slack is at the point where the gateways can no longer handle all of our features or security needs.

I don't think Slack ever cared much about the gateways. I have used the IRC gateway for years, and it was never compliant with IRC protocols. I even had to patch my IRC client to work with Slack.

IRC is also being extended with new features [1], some of which are designed specifically for gateways to services like Slack. But Slack never used these. It does not even use features that are supported by all IRC clients literally for decades (eg. AWAY)

[1]: https://ircv3.net/

Could you be more specific about what features IRC/IRCv3 lacks?


I attempted to use the xmpp gateway for a while before realizing it had a bug which caused the gateway to spam messages on reconnection. I contacted support and they said it was an intended feature and they wouldn't support proper xmpp group standards. That was the day I ditched slack forever.


This sucks, but it makes sense. I'm willing to be <1% of their users use these gateways, and it's becoming an engineer burden to maintain as they try and ship new features. I don't think this will translate to any significant loss of users anyways, as their main money-making users use it in a business setting where you kinda /have/ to use it.


Why is anyone surprised? Almost every software company embaces "open standards" when they're starting up, because it helps them get a foothold. But once they're established, they want to kick out that ladder, in case the newer competitor comes along.

Establish yourself, then build a moat.

This is also a sign that they may be planning to IPO. How else would they sell a walled garden?


Despite being a walled garden, the IRC gateway was Slack's saving grace. It was what made it palatable to many old-school chatters and people who didn't want to add another proprietary client to the giant list of other proprietary chat clients needed to keep in touch with people.


It is a shame. People with older computers will have a harder time, also people with their own work-flow and clients.

Deep down, we knew that the Gateways were just a temporary thing, to help people enter the walled garden and also to shut down who might complain about the move to slack.

Even though your company might use it (you can't do much there), you should resist when communities choose this system to their chat, there are open alternatives that fit better the use case.


WeeChat Slack API plugin (works without IRC-gateway)

https://github.com/wee-slack/wee-slack

Background

I'm not associated but I thought I had to share this. Since about a year back I've migrated to wee-slack for slack usage in my WeeChat IRC-client, it's also possible to use WeeChat as a bouncer through WeeChat relay (if not mistaken there's irssi-proxy:esque proxy-plugin too).

I've been a die hard irssi-fan and still use it for much of my IRC interaction and been using weechat as a irssi-like slack client. As a bonus we can use many of the features that didn't work through the irc-gateway.

You can also see a preview of my setup on my twitter

https://twitter.com/ahultner/status/923588418126348289

If you're interested of my personal setup you can find it in my dotfiles

https://github.com/Hultner/dotfiles/tree/master/cetrezMBP/.w...


This is what I use. Unfortunately as soon as you load previous Slack messages, the log file gets all messed up with their message order, so you can't rely on it as-is.


I think this just proves slack can no longer do what it was originally made for sending/receiving messages to boost productivity. Their are a ton of articles posted on hackernews discussing how slack turns a productive person into a slave of answering questions on slack. Slack is a distraction now, a glorified way to show your boss and others you are doing stuff while achieving nothing. Them removing these protocols isn't about forcing people to use their closed source protocol or shitty gui web technology. It is about taking a techie and forcing him to interact with the reset of the team like a good little sheep. Now he can't ignore the pings from pm and channels. Now he can't ignore the voice/video calls that someone demands of him/her sucking up more of his day with useless trash. All I hear in my head while I read this was either be a sheep like the rest or else.


Slack's official clients allow the user to control notifications, and therefore when they respond.


Embrace - Extend - Extinguish...

Never lock yourself in to Propriety systems. Open Code, Open Hardware, open Protocols


Zulip. Open source with IRC gateway, but most importantly a model that lets you tame the firehose.


It was working great and seriously used and appreciated by our users. This is a tragedy. Many feel the electron clients are extremely clumsy and massive resource hogs. Nobody likes threads. Nobody needs threads.


Slack never intended for these gateways to stick around.

They only offered them as a way to get a foothold in organizations where vestiges of influential IRC/XMPP users required them.


What a depressing, disappointing move.

An already closed ecosystem is making itself further insulated from open culture and competition.

This further solidifies my position of avoiding the product.


Is Mattermost a viable alternative, and is it possible to bridge it with IRC and XMPP?


Mattermost has bridges[1]. There's also Matrix[2] which is decentralised and has bridges for almost everything.

[1]: https://github.com/42wim/matterbridge [2]: https://matrix.org/


Have you tried running this stuff?

Have you tried running your own home server and then bridging your irc network to it?

It's not simple.


I have run my own homeserver, you're right it's not simple. However, the main Matrix homeserver has those bridges set up (so if you don't mind using it, you can). But in the context of a corporate environemnt, you have people who are paid to maintain services like this.


Can I bridge my Slack to the main Matrix homeserver ( matrix.org )


Yes, it's even included in the Riot UI.

Note that unlike IRC, where bots or users must be on the same server rooms are completely independent of any single homeserver. There's nothing that says a room belongs to a certain homeserver. So the bridges set up by matrix.org will work with any room, unless you explicitly turn off federation.


I'm dumb, I really don't see it in the UI.

I read https://medium.com/@RiotChat/slack-bridge-improvements-44c52...

I don't see a way to "add a slack" in Riot.


AFAICT the key is the "manage integrations" -button (nine squares, 3x3) in the UI.


I have some experience with MM as user and can say that is just an imitation of the Slack. Every pixel trying to say "we were unable to make a real copy of the Slack". Have feeling that developers still use Slack for their own communications and blind copy what they see.

Slack is not standard. There is a lot of the things that can be better in many ways.


Huh, looks like I'm not using Slack anymore. There's a couple slacks I connect to casually only because I can in my already running IRC client.


I wonder how hard it would be to write a custom bridge with the real time api, to make your own IRC gateway?


I was thinking about this too, then I realised I'd be spending some of my own precious life helping Slack mitigate the consequences of a user-hostile, and Open Web-hostile, decisions. Screw that.


Looks like it has already been done, thankfully :D

https://github.com/wee-slack/wee-slack


One of my ex-colleague build one a while ago in less that a few days so I guess not that hard. But he is in the habit of making IRC gateway for everything he use


I'm interested. Do you have a link to his homepage/github profile/... ?


unfortunately he didn't publish the code


Pretty easy, I reckon. I started writing a native Mac client using the API, and it was pretty straightforward. I don’t see there being a huge barrier to implementing a gateway.


I've been starting to toy around with it and Qt for a quick and dirty native app. Nothing worth sharing yet.

What route did you go?


Just a plain Cocoa app using Swift. Similarly nothing worth sharing, but the API is straightforward enough and I wanted to brush up on my Swift, so it was a worthwhile experiment.

Maybe I'll even finish it one day :)


https://github.com/ekmartin/slack-irc


Was considering doing this since they prohibit iframe embedding via a sameorigin requirement.


Not to simply pile on to the complaints about this, but I rely on the IRC gateway on my paid account for: Memory constrained use Bandwidth constrained use _Attention_ constrained use

I hope there will be a text only or “low latency” mode in the native client.


TIL there was an IRC gateway that I would have definitely used if I knew about it. Darn.


Embrace. Extend. Extinguish.


Something that is quite "fun" is to accidentally leave a few slack tabs open in the browser, while running pycharm.

(If you like watching the computer slow to a crawl and have to power it down).


Earlier discussion: https://news.ycombinator.com/item?id=16536254


This seems like as good of a place to ask as any:

Are there any decent terminal-based Slack clients? (at least until Slack decides to shut down their API...)


Seems like alot of us have an issue surrounding walled gardens. We too see the problem and have recently launched https://m.io to tackle the lack of interoperability across teams and platforms. For now we're allowing for anyone to chat across teams and with users that are on other enterprise messaging platforms like Cisco Spark.


Does anyone actually prefer coding to the IRC and XMPP protocols instead of the Slack API ?

https://github.com/erroneousboat/slack-term seems more than sufficient to me, and hackable if I find an itch to scratch...

Better yet, would anyone here pay for development of a self-hosted IRC or XMPP gateway to Slack? :P


This is how I find out these existed, I could have been using something that didn't a shitload of memory in firefox the whole time :(


That sucks. The IRC gateway was the only way I could ignore the rampant not spam and image dumps. I'll miss you, /ignore. RIP


This opens up a market for someone building a Slack app and putting it on the Slack marketplace, that would relay in/out messages from/to XMPP o IRC. I'd pay for this, I definitely don't want to use Slack from their Electron app that sucks both my battery and my RAM. I'd stick with Adium as an XMPP client connected to Slack.


When connecting over the XMPP gateway, have you ever had issues where your client would lock up while connecting and take multiple attempts to establish a connection? I had that problem and ended up switching to the IRC gateway.


Has anybody here switched to mattermost? How has your experience been so far?

Any "gotchas" or unanticipated pain-points to be aware of?


My org uses mattermost - a logical addition since we were already heavily invested in gitlab.

I don't run the services personally but I know the guys who do, and from what I can tell it mostly Just Works. We use our org's SSO for gitlab, and we use use gitlab auth for mattermost, and all the pieces work together well.

I don't use IRC with mattermost, but there are bridges available.


maybe its time to revive my macOS native slack client MacSlack :) https://twitter.com/harisamin/status/727634194814373889

I've posted about it before here on HN but wasn't sure if there's enough interest


Good riddance. Their XMPP gateway was extremely basic, frequently dropped messages. Why pretend it's working when it's clearly not?

Here's the compliance ranking: https://conversations.im/compliance/


This sort of app gets rewritten every two years. People act like it’s the second coming every time.

IRC with persistence? Oh that’s acana, slack, hipchat, whatever this year’s VC-backed boondoggle is. I haven’t seen anything new after IRC beyond ICQ. Just like movies now. Same meh, new packaging.


What must-have/killer features won't work with IRC/XMPP gateways? Also, even if there is something, shouldn't it be optional then?

I don't mind them wanting to discontinue support for it, it's their business after all. I mind the BS reason.

Feels like a Google Reader scenario...


...Welp; so much for being able to access Slack from a phone running a third-party OS. The Slack mobile web page is useless; you can't chat or view conversation logs from it, I've never figured out why it exists in the first place.


I stopped using the slack client because it was causing my desktop to hang, so I started using the IRC interface, which works great for my purposes. Since they are getting rid of how I access slack, I guess I'm done w/ slack.


We went to paid Slack because it was, functionally, a hosted IRC server. I even recommended it to others on that basis.

Looks like we're going elsewhere. What else is there that does the job? IRC interface, archives messages you missed.


One colleague at my last employer demanded to use the XMPP gateway and everyone hated it, because he constantly missed information, didn't get personal messages and didn't receive emoji reactions.

I'm glad the finally removed this.


From a business perspective, this is incredibly stupid, as they‘re basically abandoning their early, nerdy adopters who brought them into companies in the first place. It‘s a big „fuck you, now that we‘re a REAL COMPANY“, we don‘t need you anymore.

It’s also a bad sign on who has taken charge and what the culture is like by now. If they had REALLY wanted, nothing of this would have been impossible. If you can‘t secure a weak or weird protocol, just go down the route Google did with the Cloud SQL proxy and tunnel it. There‘s no big complication connecting to a localhost gateway instead that handles all the authentication and encryption - we‘re talking about a nerdcore audience anyway.

FWIW, I don‘t give much about IRC and love Slack as is, but I still can‘t believe they‘re acting this nearsighted.


From what I have seen the best solution for bridging chat protocols is a "tube" from https://sameroom.io - not free though.


If you're looking to bridge Slack and IRC, Matrix does a pretty good job of that.

https://imgur.com/a/f2fuO

I don't believe anyone's written a fully-functional XMPP connector yet though.


Free for some providers that have Sameroom-operated "BridgeBots".

Any combination of Hangouts, Skype, GroupMe, Telegram, and Gitter is free to connect.

We also had a Freenode BridgeBot, but couldn't get around the max connections per user issue.


Freenode permits I-lines for multiple users from the same IP. Have you looked into that?


We’re all whitelisted in terms of IPs. The issue is with # connections from the same nick. We worked with Freenode to find a solution and it didn’t pan out.

The overwhelming majority of customers connect to Slack though, so it wouldn’t matter price-wise.

I think I’m the only one reading #stripe from Skype :-)


Does that mean if I want to use an open source client with Slack, I can use the Gitter BridgeBot and open source Gitter client? Does it work with private Slack channels?


It does


Embrace, Extend, Extinguish


Duh of course. I can't believe the wholesale abandonment of IRC by so many open source communities for Slack. It's been so... so... horrifying to watch. Can't you see we're giving up critical data and history to an outfit that no one has control over whatsoever.

Slack charges you to search the history beyond a certain number of messages.

SLACK CHARGES YOU TO SEARCH THE HISTORY BEYOND A CERTAIN NUMBER OF MESSAGES!

Yeah, let's make everyone all across the world pay to access a software community's most vital resource regardless of their income or even means to pay. Let's actively make this information sit behind a paywall accessible only by those privileged enough to breach it, but only as long as they keep paying month after month.


This kind of announcement needed to include "and today we're announcing native apps across all platforms". Honestly, the Slack app has become worse (not better) over time.


Used you to grow, don't need you anymore. Thank you, but bye.


I guess I'll bid farewell to the Slack communities I've been participating in. I'm not interested in using a browser or installing additional software for chat.


You could try to get them to bridge to matrix


Bitlbee will compensate.


As much I would love this, it looks like the only real option right now is wee-slack plugin for weechat. I have been using it for almost a year now and it does it's job very well. Bitlbee for hipchat, wee-slack for slack. I'm ok (for now, it's just a matter of time before slack cannot be used without one of their official clients like the shit that happened with whatsapp and others)


Mmm, while this wouldn't have impacted my decision in the slightest, I am mostly glad that I have moved over to Discord for everything I used to do in Slack.


Is Discord any better? It's still a centralized service run by one company, is it not?


Can't speak for Slack, but Discord is a fully walled garden, and they make sure to control how content on the platform is consumed.

You can't automate your own account in any way without risking a ban due to breach of ToS (see "self-bots").

This makes it impossible, for example, to get local chat logs (as the official client doesn't support it).


My choices in communication technology are based on what myself, my friends, and my colleagues find easy, intuitive, and accessible. That it's a centralized service has no bearing on 99.999% of the reality I share with the people close to me.


I just want to point out that a use case is that some people like to conserve resources and the electron app is the biggest resource hog in my ecosystem....


Slack is the company that can't be bothered to support Opera, let alone open protocols. Incredibly lame, but par for the course.


The UI looks easily clone-able. (if anyone wanted) -the LHs selects major groups, then a list of minor groups and identities, then a pane of content.

The "value" is the persisting storage and maybe the integration with bots (which IRC had first anyway) and Markdown, which is a really low barrier to entry.

So it feels to me like (and I speak as one who often says others can do it, but with no intent to do it myself so be warned) its a low bar implementation goal to do an IRC backed open slack.


Well, that's the end of me using Slack.


Since Slack's APIs are open to use would it not be possible to make an IRC/XMPP 'proxy' server?


Relatedly, are there any 3rd party Slack apps out there? Their APIs are powerful and seem pretty complete.


Those APIs will probably be deprecated soon enough.


I doubt it. Many companies depend on Slack's APIs to do things like post build failures or provide custom commands.


Same could be said about their IRC gateway.


this sucks. i use smuxi specifically so all my chat apps can be in the same window. why do this? your web app is just not nice to use for text chat. its busy and poisoned by emotes and confusing menus.


Which features? Seems like an excuse to not maintain those services.


I am unsure why Microsoft Teams isn't used more.

Compared to slack, it has not much less, and it comes for free with each subscription to office 365.

I've seen the whole office 365 in action at my current company and quite frankly, it's well worth its price.


And with that goes any chance of me ever even trying slack.


I don't understand ... im using slack at work , and why should i use IRC or XMPP with slack ? and why it is so bad they cancel it ? realy.. its just tool .. why i need IRC on top of that?


Using IRC "on top" is to avoid using the Slack client at all. I can understand that, and Slack would shut down a lot of critics if they made native clients, and a CLI client.


just to be clear when taking about IRC we are talking about mIRC type right ? native client to what ? i'm using their electron client .. what is wrong about it ? ( memory hangy?)


IRC can be any client you want. Not much IRC, but the ability to leverage the hundreds of good IRC clients to use one in your workflow that fits your needs exactly.

The Electron client is a glorified browser and webpage with none of the benefits of a native app, but with all downsides that entails, including using gigabytes of memory for simple chat.

It's a damn chat client that needs to listen to and submit events, and order them into channels. That is it, it shouldn't use much, or feel slow at all.

And then there is the CLI issue. If you want developers to promote your product, then make it good for them. Many developers want to use live in the commandline.


Couldn't be more bummed about this.


It's just another private messaging system. It's making money, that's what counts for them.


Relevant XKCD: https://xkcd.com/1782/


This is a huge bummer.


Closed garden. :(


Bye bye slack


Slack was fine, now it is time to move back to IRC.

Some people like slack or telegram because they provide an API for BOTs. Something IRC has been open to since the begining.

Non power users might have trouble using IRC with the usual clients (mIRC/irssi/bitchx).

Today a family member, not technical and 60+yrs asked about "that tool" that is like whatsapp however it allows users that just joined a group to read old messages. He was referring to slack. He wanted to create a group and when new users from his company joined, they would be able to read whatever was written on that group.

So with this in mind, i think what would really work (also) is to have something on the front of IRC (some bouncer) with a pretty UI that logs everything and allows new users to connect via mobile, standard irc clients, and also send pictures, and read backlog (stuff slack does). However the backend chat server should be the decentralized existing ones, efnet/freenode/etc.

So maybe its time to re-invent slack and make a pretty UI to access usual standard IRC. ie. a new slack that uses old irc networks (decentralized networks) as its backend. But also allows users to talk from mobile apps, browsers, etc


You just described the Matrix riot client:

* https://matrix.org/

* https://riot.im/


Love matrix, but the OP just described the big adoption problem. Non-programmer wants to set it up for his company. How do you do that with a matrix server? Slack makes it pretty damn easy for non-techies to get set up and invite people. Matrix currently does not do that.


Maybe I'm not understanding you correctly, but with Riot.im you can just sign in, create a room, and then invite people to that room.

It gets a bit more complex if you want to run your own server, but that's not something you can do at all with Slack.


It's very possible I'm misunderstanding as well, but when you create a room on the Matrix homeserver, the only option you have is to make it so users on another homeserver cannot join that room, which means your only security is other matrix users not knowing your room name.

For a small corporate team that wants to pilot a chat program, like in the original comment, the gulf between Slack setting up your own private workspace with a few clicks and a room that has all of your chat history exposed to any user that knows the room name is pretty large.

I would love to see riot or matrix give you a few click options to have them host your own private matrix server, as that's a big obstacle for corporate customers who don't have the resources (human) to spin up their own servers (domains, adding ssl certs, adding nginx, etc.) just for trialing a chat program.


This is indeed a massive misunderstanding: rooms in Matrix can either be publicly joinable by default or be invite-only (just like in IRC). There's also a separate question of whether a room is locked to a given server (i.e. made unfederatable), but this is an extreme measure taken if you know the room will contain stuff you never want to ever leave that server. You can now also create communities to group your company/project's rooms together even if you're primarily using someone else's homeserver.

Separately: we're working on providing a "one-click" homeserver hosting option with a free trial precisely of the kind you're asking for.


Great, thank you very much for clarifying!


Like just about any IT service you call your ops team? Slack offers value in being hosted for sure but if you're worried install difficulty then we're in the world of on-prem services. Matrix is easy compared to some paid products I've used.


I've worked for a few small startups and smaller IT teams in larger corps, so the option of "call your ops team" isn't really feasible, so in that sense Slack wins because it's easy enough for the business owners to set it up, send out the email invites, and feel that it's relatively secure. I think Matrix is an all around better option, but just believe that they are missing why small companies or strapped teams pick Slack in the first place.


A few projects exist that try to be "modern" UIs for IRC (bias: I contribute to Lounge)

TheLounge - https://thelounge.chat (FOSS, self-hosted)

IRCCloud - https://irccloud.com (mobile clients OS, hosted)


Let me add Glowing Bear, a project I contribute to that builds on top of WeeChat: https://github.com/glowing-bear/glowing-bear


they don't look "modern"..


Yeah, there isn't enough low contrast text and excessive white space.


TheLounge has full support for themes and custom CSS on the client


Did you actually look at them? The Lounge looks like a less image-heavy Slack. It's definitely following most modern design trends like flat UIs.

At the very least it looks and feels far more modern than, for instance, mIRC.


I just played with The Lounge a bit and it actually looks really nice.


No way to edit a message I've already sent.

I'll stick with Slack.


You can't do that in IRC at all, so it would be impossible for a UI to offer that feature. ;)


It's on the horizon, though: https://github.com/ircv3/ircv3-specifications/pull/304


It is almost seems like you are saying there are technical reasons for them dropping IRC....


Besides that, if slack had IRC enabled and e2e you would be able to connect via IRC and actually verify that e2e is doing its job (ie. connect via irc and see scrambled texts).

One problem with all these closed client apps slack (with this update)/whatsapp/telegram is that there is no way to verify/audit it is actually doing proper e2e.

Users must trust the X company that they are really doing proper e2e.

These apps should allow users to download a plugin and use that to produce the e2e. Then the user would be able to download an open sourced audited plugin that encrypts the messages before they hit the whatsapp/slack/telegram company servers.

So for instance, if this was possible, everyone on a group would download and install the plugin that runs on top of whatsapp/slack/telegram and share an encryption key that only they know about. And do the same for conversations between 2 people.

There must be some point of trust, however with the current situation, it is hard to trust e2e code no one is able to audit.

Or just open the protocol so everyone can use and create their own clients and their own e2e mechanisms. Which is what IRC is.


Telegram's client is open-source.


Telegram's E2E is also crap and shouldn't be used[0]

0: https://security.stackexchange.com/a/49802


The two things IRC is actually missing for most people is push notifications and "offline" history. Yes you can get these if you run your own bouncer, or whatever, but it's not native to the technology. I think Matrix is ahead of IRC for solving both of those issues.


IRC is the protocol. There are myriad services which use the IRC protocol. Some of these do include push notifications and offline history, such as irccloud (and others).

The freedom to choose is one of the reasons people wish slack would open source their protocol.


Non power users might have trouble using IRC with the usual clients (mIRC/irssi/bitchx).

I've never used Slack but these name drops are all familiar.

Back in the good 'oldays of Eggdrop? It's amazing that Slack was "backwards" compatible with IRC for so long.

But honestly, their API is mature. No need to be backwards compatible. Easier to sell when you are in control of access and client.


Some have already mentioned similar clients, but also check out Convos[1]. Recently I had a very similar need for what you described and stumbled upon it.

[1] https://convos.by/


It has ALWAYS been time to move back to IRC!

(Arghh... I'll probably be downvoted to hell for a flippant, drive-by comment, but what the fuck... We all know that HN hates comedy.)


is it true what I've heard about irc and how it completely ignores stuff like encoding?


I appreciate the creativity in the presentation, but isn't every post here a "Tell HN" post?


Why is it that the worst tools and companies constantly seem to end up floating to the top in terms of popularity?


Time to use Discord


Discord has all the same problems Slack does. It's a proprietary VC-funded app without a sustainable business model.


What's Discord’s business model? Slack has a paid-for tier, but I haven’t seen anything like that on Discord.


This is pretty good explanation.

https://media.8ch.net/file_dl/25ece2fb253fc4e6cdd3ac4ed99e4f...


A file download is a pretty big commitment for an "explanation". I'm going to pass on that. :/


What browser do you use that can't play webm?


Clicking that link in Firefox immediately offers up a file download. So does IE. I'd test with Edge, but my Edge is broken. :( I'm guessing you use Google's browser and Google doesn't assume Google's video format is a download when passed as a URL?


Discord has a paid subscription, but since they've committed to be ad-free and not paywall off key features... well, there's almost no compelling reason for it.

https://discordapp.com/nitro


They also seem to be data-mining the chats, and preparing to sell off data assets. From the Privacy Policy: " Information we collect may include but not be limited to username, email address, and any messages, images, transient VOIP data (to enable communication delivery only) or other content you send via the chat feature."

They are pretty open that they collect a lot of data about you, and this is not even the full list ("not limited to").

"...we may conduct research on our customer demographics, interests and behavior based on the information collected. This research may be compiled and analyzed on an aggregate basis, and we may share this aggregate data with our affiliates, agents and business partners"

Shared for dollars, of course.

"As we develop our business, we might sell or buy businesses or assets. In the event of a corporate sale, merger, reorganization, bankruptcy, dissolution or similar event, your information may be part of the transferred assets."

They can sell your data, including all the chats they have collected.

It is of course a Privacy Policy and not a Business Model strategy document, but it is pretty far-reaching and allows for monetization of anything you do with Discord. You are the product.


I've used Slack as part of a few organizations. If I'm starting my own ad-hoc technical organization, is there any reason not to use Discord? Seems to have all the features I need.


I've used Discord extensively and it's high quality software.

The only reasons I could see someone choosing not to use it are:

- Doesn't have the same plethora of plugins that Slack does, although it does have a fairly complete API.

- It is a gaming product and it shows, which might make some more straight-laced people balk at its perceived unprofessionalism.


It's also not open source and you can't self-host it if needed. I'd recommend a IRC server and https://github.com/thelounge/thelounge


Love Discord. Only one bone to pick: Every time I sign up to a new Discord instance, I get to jump through all the same hoops to prove to Discord that I'm a Good Person There To Engage As A Proper Human Being. It gets old fast. I wish that Discord instances would talk to one another and say "Oh, that gal, she's probably OK..." and give me at least a step or two up the ladder.


Does Discord even support XMPP or IRC?


Bitlbee has a plugin: https://github.com/sm00th/bitlbee-discord


Note that using that (or anything else that logs into discord using your username and password) constitutes a breach of Discord terms of service.

That means they may ban accounts for using it.


evolution sucks


:(




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: