Live data from Hacker News

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

news.ycombinator.com

541–550 of 624 posts

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

#541
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!

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

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

#542

Earlier quoted context omitted.

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

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

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

#543

Earlier quoted context omitted.

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

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.

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

#544

Earlier quoted context omitted.

"The obvious solution? Use a product that does not interoperate with absolutely anything at all ..." You mean use a product with a baseline feature set where you can count on all the clients seeing things the same way and supporting the same thing.

Sorry, but that is just obvious flat-out bullshit. Have you tried using Psi (an XMPP client) to communicate with a user using the Slack client (well, after this change, obviously ...)? Did you have any success with that? No, of course not. In other words: Slack is obviously not a product where you can "count on all the clients seeing things the same way and supporting the same thing.". Slack works with exactly one cl…

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

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

#545
post #304

Earlier quoted context omitted.

"There are open protocols like Matrix which are superior to Slack in that they are decentralised, have support for full e2e encryption, entirely self-hostable, don't store your data outside of the home-servers used for communication, etc." How does that translate to superior communication between my coworkers and I? Most of that stuff does not matter to people.

My point was that the protocol is superior to Slack in general. Whether you have a use for those features is a different point -- those features are clearly already useful to quite a few people. But to answer your question, self-hosting would be useful in making sure that internal communication isn't shared with a third-party. e2e could also be useful (depending on what you work on) if you want to just use the public…

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

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

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

#546
post #149

Earlier quoted context omitted.

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

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

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.

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

#548
post #149

Earlier quoted context omitted.

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

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

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

#549
post #354

Earlier quoted context omitted.

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.

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

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

#550
post #104

Earlier quoted context omitted.

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

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.
Post reply on HN