Live data from Hacker News

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

news.ycombinator.com

551–560 of 624 posts

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

#551
post #107

Everybody here is disappointed at Slack, and I like open protocols and open platforms just like everybody else, but I still have a contrarian view. Instead of blaming Slack, why not accept that the open protocols indeed suck? IRC does not specify encoding, netsplits are a common issue, file sending sucks, etc. XMPP also has file sending problems, does not play nice with mobile, is fragmented (not every client impleme…

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

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

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

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

#552

Earlier quoted context omitted.

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.

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

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

#553

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

> Afterwards it's client developers' problem Riiiight. And how many clients do you know that have that? Or read receipts? Or file sending? Or... Or...? There’s basically just one client that supports modern XMPP features. So no, it’s not the client developers’ problem. It becomes the end-users’ problem. And they will abandon XMPP in favor of solutions that don’t have tgat problem.

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

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

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

#554

Earlier quoted context omitted.

Companies are just using Micro$oft's playbook. Oh, and spoiler alert, Microsoft still is too: https://wiki.debian.org/InstallingDebianOn/Microsoft/Windows... Embrace / Extend / Expunge

So how exactly do you expect running Debian/other Linuxes on Windows will extinguish them? I don't really see a way for that to happen. Sure, the Linux subsystem is "Embrace", but a lot of things can be embraced without extended or extinguished.

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

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

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

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

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

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

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

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

#555
This sort of app gets rewritten every two years. People act like it’s the second coming every time.

IRC with persistence? Oh that’s acana, slack, hipchat, whatever this year’s VC-backed boondoggle is. I haven’t seen anything new after IRC beyond ICQ. Just like movies now. Same meh, new packaging.

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

#556

Earlier quoted context omitted.

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…

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.

That idea is as old as Victor Borge...

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

#558

Earlier quoted context omitted.

> you can add pgp on top of it if you want security Nobody does, sadly. Baking it into the protocol like Signal and WhatsApp did means nobody has to want it, they just get it included without having to bolt on any extras.

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

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

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

#559

Earlier quoted context omitted.

> Afterwards it's client developers' problem Riiiight. And how many clients do you know that have that? Or read receipts? Or file sending? Or... Or...? There’s basically just one client that supports modern XMPP features. So no, it’s not the client developers’ problem. It becomes the end-users’ problem. And they will abandon XMPP in favor of solutions that don’t have tgat problem.

XMPP is a protocol. Slack's own RTM API is a protocol. It was claimed that the former cannot be extended but the later can be - which I argued is wrong. Now you're arguing about something completely different. It's not like it's a death sentence if some RTM API-consuming app is not capable of something - why does it suddenly becomes an issue when we switch protocol to XMPP?

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

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

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

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

#560

Earlier quoted context omitted.

What's Discord’s business model? Slack has a paid-for tier, but I haven’t seen anything like that on Discord.

This is pretty good explanation. https://media.8ch.net/file_dl/25ece2fb253fc4e6cdd3ac4ed99e4f...

A file download is a pretty big commitment for an "explanation". I'm going to pass on that. :/
Post reply on HN