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:


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.


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.


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:


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

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.


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.


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


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!



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


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:


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.


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.


> 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


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


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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact