9 ms·

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

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.

dijit 9y ago
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.
cyphar 9y ago
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?
- dfabulich 9y ago
  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.)
  - cyphar 9y ago
    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.
  - MereInterest 9y ago
    > 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
    - signa11 9y ago
      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.
      - MereInterest 9y ago
        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.
      - arbie 9y ago
        > edit-001: ... Are you planning very many edits?
zer00eyz 9y ago
> 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 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.
akkat 9y ago
email is an open protocol and works great. you can add pgp on top of it if you want security
- ascorbic 9y ago
  Email does many things, but "works great" isn't one of them. PGP even less.
  - CaptSpify 9y ago
    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....
    - s73v3r_ 9y ago
      Has a huge spam problem...
      - cyphar 9y ago
        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.
        NikolaeVarius 9y ago
        You can easily choose to be not be a part of that. You do not have that luxury on email.
        CaptSpify 9y ago
        You know you can filter email based on the content, right?
        ascorbic 9y ago
adrianmonk 9y ago
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.
- MayeulC 9y ago
  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.
zAy0LfpBZLC8mAC 9y ago
> 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.
- s73v3r_ 9y ago
  "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.
  - zAy0LfpBZLC8mAC 9y ago
    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.
    - s73v3r_ 9y ago
      Most people using Slack are using the Slack client. Therefore, yes, I can count on there being a baseline.
woodruffw 9y ago
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.
epberry 9y ago
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.
- kuschku 9y ago
  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 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.
- saagarjha 9y ago
  > 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.
atomi 9y ago
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.
- bastawhiz 9y ago
  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.
lallysingh 9y ago
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.
alex_hitchins 9y ago
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.
- s73v3r_ 9y ago
  I'm fairly certain they're not Slack, so they couldn't do that.
deleted 9y ago
[deleted]
keyle 9y ago
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.
- rspeer 9y ago
  I don't think the person you're responding to is the one doing it.
progval 9y ago
> netsplits are a common issue This is a server software issue, not a protocol issue.
whatyoucantsay 9y ago
"Instead of blaming Slack, why not accept that the open protocols indeed suck?" said FooBarWidget to the world, via TCP/IP, DNS, HTTP, HTTPS...
e12e 9y ago
> 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.
jmiserez 9y ago
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.
- FooBarWidget 9y ago
  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.
Doxin 9y ago
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/ https://ircv3.net/

dijit 9y ago

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.

cyphar 9y ago

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?

dfabulich 9y ago
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.)
- cyphar 9y ago
  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.
- MereInterest 9y ago
  > 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
  - signa11 9y ago
    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.
    - MereInterest 9y ago
      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.
    - arbie 9y ago
      > edit-001: ... Are you planning very many edits?

zer00eyz 9y ago

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

akkat 9y ago

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

ascorbic 9y ago
Email does many things, but "works great" isn't one of them. PGP even less.
- CaptSpify 9y ago
  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....
  - s73v3r_ 9y ago
    Has a huge spam problem...
    - cyphar 9y ago
      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.
      - NikolaeVarius 9y ago
        You can easily choose to be not be a part of that. You do not have that luxury on email.
        CaptSpify 9y ago
        You know you can filter email based on the content, right?
      - ascorbic 9y ago

adrianmonk 9y ago

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.

MayeulC 9y ago
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.

zAy0LfpBZLC8mAC 9y ago

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

s73v3r_ 9y ago
"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.
- zAy0LfpBZLC8mAC 9y ago
  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.
  - s73v3r_ 9y ago
    Most people using Slack are using the Slack client. Therefore, yes, I can count on there being a baseline.

woodruffw 9y ago

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.

epberry 9y ago

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.

kuschku 9y ago
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 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.
saagarjha 9y ago
> 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.

atomi 9y ago

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.

bastawhiz 9y ago
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.

lallysingh 9y ago

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.

alex_hitchins 9y ago

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.

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

deleted 9y ago

[deleted]

keyle 9y ago

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.

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

progval 9y ago

> netsplits are a common issue This is a server software issue, not a protocol issue.

whatyoucantsay 9y ago

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

e12e 9y ago

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

jmiserez 9y ago

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.

FooBarWidget 9y ago
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.

Doxin 9y ago

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/ https://ircv3.net/