Live data from Hacker News

Tell HN: Slack decides to close down IRC and XMPP gateways

news.ycombinator.com

461–470 of 624 posts

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#461

Earlier quoted context omitted.

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.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#462
post #274

Earlier quoted context omitted.

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.

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?

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#463
post #147

Earlier quoted context omitted.

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 (tho…

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!

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#464
post #47

Earlier quoted context omitted.

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.

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?

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#465

Earlier quoted context omitted.

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

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#466
post #455

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

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

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

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#467

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…

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

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#468

Earlier quoted context omitted.

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

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

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#469
post #354

Earlier quoted context omitted.

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.

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!

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.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#470
post #378

Earlier quoted context omitted.

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

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

Post reply on HN