Hacker News Reader

Comment by FooBarWidget | Hacker News Reader

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

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

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

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

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

View on HN

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

However, this is simply untrue:

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

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

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

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

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

Bait

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

Switch

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

edit-001: fmt changes.

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

> edit-001: ...

Are you planning very many edits?

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

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

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

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

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

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

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

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

> But that's not the point you made.

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

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

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

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

> Most of that stuff does not matter to people.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Shit like this is why IRC is still so popular.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

All valid points, but this makes me sad:

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

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

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

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

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

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

Nobody does, sadly.

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

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

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

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

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

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

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

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

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

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

Maybe we could do something about voicemail then?

ducks

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

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

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

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

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

Has a huge spam problem...

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

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

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

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

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

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

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

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

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

> netsplits are a common issue

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

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

Reply on news.ycombinator.com