11 ms·

Slack, Zulip, this feels like we are back in 1999, when the internet was divided by ICQ, AOL Instant Messanger, Windows Live Messanger, and Yahoo Messanger. (In

Slack, Zulip, this feels like we are back in 1999, when the internet was divided by ICQ, AOL Instant Messanger, Windows Live Messanger, and Yahoo Messanger. (Instant/Live was a plus back then). And the only innovation over IRC was a backlog and buddy list. I wonder when the Trillian of Slack+Zulip will come out. I hope Trillian (which still exists) is already working on it.

coldtea 11y ago
Only Slack and Zulip are for specific teams/companies, not for the public at large. So there's no "fragmentation" issue, any more that there's one when a company uses Bugzilla and the other uses JIRA.
- joesmo 11y ago
  We have cross-organization Slack users in our company slack channels and I also have multiple 'organizations', so fragmentation is sometimes an issue.
  - epmatsw 11y ago
    Yep, we have a channel for developers that integrate with our product instead of having them email us. It's pretty efficient, but the fragmentation risk is there.
- scrollaway 11y ago
  This is a very short sighted view. There is a real need for an alternative to IRC - and closed source products do not cut it when we are talking about communication. What parent is talking about is a real problem. There's micro-ecosystems out there around specific closed source products, all of them centralized, none of them compatible... and in the mean time, the only real decentralized, open source group chat solution (IRC) has a lot of issues [1] which shouldn't exist in 2015. [1] https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToBsQ https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...
  - chc 11y ago
    As noted in the OP, Zulip is not a closed-source product anymore. But I'm not sure that really helps so much with the immediate problem, since it's more the proliferation of protocols rather than the scarcity of source that causes issues.
    - scrollaway 11y ago
      Yes, that's the title of the thread, you can assume I read that far at least ;) I'll give you I wasn't very clear. I'm super excited Zulip is going open source. And it's both the proliferation of protocols and the closed-sourceness(?) of the products that is problematic. Open source has two coupled benefits: 1. If the product becomes popular, it's easy to integrate with it, extend it, modify it, etc rather than just write an alternative from the ground up. This prevents the proliferation of new protocols just for the sake of an alternative. Right now, it makes no sense for me to go and build a FOSS alternative to Zulip. It would've made sense a few weeks ago. FOSS web services encourage/promote self-hosting. This also counts for something. 2. When extending a foss product, writing a gateway is a lot easier. Gateways don't slow down proliferation as much, but they do keep protocols somewhat close to one another and make it easier for users to migrate from one another. For example: It's been several years now and there is still no reliable open source XMPP-to-Hangouts gateway. But a Zulip/IRC gateway? If one doesn't exist already, I bet you there'll be one within weeks.
      - lwf 11y ago
        We have both already :) https://github.com/zulip/zulip/blob/master/bots/jabber_mirror.py https://github.com/zulip/zulip/blob/master/bots/jabber_mirro... https://github.com/zulip/zulip/blob/master/bots/irc-mirror.py https://github.com/zulip/zulip/blob/master/bots/irc-mirror.p... In addition to Zephyr mirroring, which we've had since 2012.
        scrollaway 11y ago
        Hurray \o/ Congrats on the release!
- danielhlockard 11y ago
  Strangeloop (the programming conference) is using a slack, as we speak. it's more than teams :)
sotojuan 11y ago
What annoys me about stuff like Slack is that it's misused. It's made for small teams but I've been 10k people open source projects use it instead of IRC. Of course, it was laggy and they eventually couldn't afford it.
- jedrek 11y ago
  Obfuscating usernames with real names and no ignore are also massive downsides.
  - gkop 11y ago
    Fyi, you can fix the usernames issue in Preferences > Message Display > Message Options.
  - CydeWeys 11y ago
    That was the biggest annoyance I experienced at companies that based their communications around IM clients like AIM or Gtalk. My previous company switched to HipChat at some point and everyone showing up as their real name instead of some stupid username was a surprisingly huge improvement.
noobie 11y ago
You forgot Glip too.
Mithaldu 11y ago
And none of them manage to replicate even the most basic of IRC's network solutions in regards to user count scaling and server network combination.
hughes 11y ago
And backlog/offline message functionality is available by turning on logging and using a ZNC proxy. My "buddy list" is just a bunch of direct message channels that I keep open.
draw_down 11y ago
Wow, out of all the things that may have occurred to me over the last couple years of using Slack, "this feels like 1999" is definitely not one of them.
JoshM33k 11y ago
Those types of fragmentation issues never went away, they just changed focus. Whether it is Slack vs. Hipchat vs. Zulip, or WhatsApp vs. iMessage vs. text vs. Hangouts... more options means more (and easier!) ways to contact friends, family, and coworkers, but also means that you have to memorize a "best way to reach me" chart for each individual person.
- ossreality 11y ago
  >more options means more (and easier!) ways to contact friends, family, and coworkers utter nonsense.
- tbingmann 11y ago
  Best ask them first via email.
  - TillE 11y ago
    I don't even know my girlfriend's email address. I'm 30, and she's only a few years younger. The world is strange now. I miss Google Wave. Not the messy implementation, but the promise of a big influential company throwing its weight behind a modern, open communication protocol.
    - inopinatus 11y ago
      This. This was how I learned that the whole "don't be evil" thing was a load of bovine manure. Google Wave, as an XMPP-based protocol, held enormous promise as a federated rich discussion standard. Sadly their first implementation was clunky and had a confused approach to standards and integration; it was effectively stillborn. Then Google killed Google Talk by strongly favouring their closed "Hangouts" product which is practically inaccessible from chat clients. They went further, making it impossible to federate Google Talk to other XMPP services. Facebook and Microsoft followed suit, either ending XMPP support or closing their federation capability. All three are therefore complicit in the worst abrogation of Internet interoperability since the early days of MSIE. And Google, in a land grab for consumer eyeballs, was the cheerleader.
tmslnz 11y ago
One could say that OS-level notifications could be considered a crude replacement of an aggregation tool like Trillian. We didn't have these back in the ICQ days and today it's easier (read: less painful) to listen on multiple messaging apps. Especially on mobile devices.
petrohi 11y ago
<shameless plug> We at sameroom.io do this in sort of backend-only way. </shameless plug>
ex3ndr 11y ago
We (https://actor.im https://actor.im) are actually working on this, but not trying to connect slack, but building telegram, skype, whatsapp, social networks to one, slack like interface that will help you easily manage communications from many networks. This is not our main feature, just something like side project.
- zobzu 11y ago
  that would be great. what would be greater though is ensuring that actor.im cannot read the data as it transits (or easy to setup on our own local machines) I'd pay a good bit for that!
  - ex3ndr 11y ago
    We had e2e encryption in the past, but we decided to make one click install of your own server or may be just key infrastructure to make everything cool.
- stevemartingale 11y ago
  This looks cool. FYI notifications is misspelled as "notificaitons" in the paragraph under "I don't believe in messaging. Email is better".
- hobarrera 11y ago
  "Mobile First" This is the regrettable de-facto standard. I'd like to see the opposite: a network that provides native desktop clients. Telegram seems to be the only one taking this seriously up to now.
- hobarrera 11y ago
  I also really dislike the idea of having to register with a phone number. I reminds me of ICQ, where I had to dig up some obscure number to log in. Except, I also lose my account permanently the moment I lose my phone.
zobzu 11y ago
+300.
austenallred 11y ago
There have been and always will be competing products and communities that serve similar purposes. We use what we think is the best one. Is this a bad thing? (Not to mention the fact that Slack is for internal teams, not for IRC-like discussions, though our open newsroom (http://newsroom.grasswire.com http://newsroom.grasswire.com) and some other communities (http://fpchat.com http://fpchat.com) have repurposed it for that.
- inopinatus 11y ago
  I think that "best tool for the job" attitude is a straw man. It seems to presuppose that "the job" is per-organisation, or even that there is one job. In truth many of us believe that the goal is enabling everyone - universally - to communicate without a single body holding centralised control of message history, reachability and access. Quick review of the globally federated protocols: Email is too slow and bulky and lacks "group" capability IRC is deeply unreliable and lacks identity, archiving, and media management NNTP is too amorphous, slow, and lacks any privacy or security controls Everyone thinks SIP is just for telephony (it isn't) XMPP is phenomenally complicated yet held great promise - if only everyone could agree on the extensions and semantics. - but was murdered by Google.
  - austenallred 11y ago
    No, it presupposes that there is a defined task. I suppose the difference between our points of view is that I would much rather have a better tool than a publicly accessible archive of message history.
  - e12e 11y ago
    You forgot h.323. On the surface, it looks to me like a "saner SIP", or XMPP with working, standard audio/video support -- but I might be wrong. I'm not sure why people claim IRC lacks archiving support. Isn't a bit like saying SMTP lacks archiving support? And doesn't basic IRC always go through a server? So there shouldn't be any technical barrier against a server archiving all chats (private and in channels)? As for NNTP, I'm not sure if NNTP over TLS, peering with only trusted sites (aka for internal use) would make sense or not. I never did use Usenet much. At least the D language forums have made an effort to bring NNTP into the www era[d]. It's interesting that no one seems to do a decent job of (server side) archiving for XMPP -- partly I think it's because as you state, the XEPs have gotten out of hand -- and partly XMPP appears to be especially popular for users that want privacy -- and treat ephemeral chat as a feature. [d] https://github.com/CyberShadow/DFeed https://github.com/CyberShadow/DFeed (format note, you probably should've just listed the protocols in separate paragraphs, as indented blocks with lines longer than ~50 characters doesn't format very well on hn).
lifeisstillgood 11y ago
But this is about social norms, not technology. Hear the phrase "remote workers...tap lightly on the shoulder". We have had thousands of years to work out our nuances over interruptions and social signals when around the same campfire. But suddenly (and from the past 20-30 years suddenly) we have phone conferences where half the conversation is "no, sorry, you go ahead" and email going from killer app to no longer being a way to get a reply in ten minutes but two days because the signal to noise ratio hit a tipping point somewhere around 2006. (No it's not spam, that's mostly a done problem. It's co-worker spam that's clogging our minds of not our inboxes) So the differences between Zulip and Twitter and Slack and IRC and Microsoft bloody communicator why does it not know about tabs ffs! (Sorry). The difference with all of these is not their technology - it's pretty much the same all the time - but their social utility. One day some comms package will get it all together (I think there is too little context to get it right yet) and we will all go"of course". Until then we will try each different social choices baked into the code - rooms or tags or whatever. Maybe the next step is to have rooms for something, open cry for others. Who knows - maybe we should look at pubs bars, libraries and streets for inspiration. Whatever it is - Zulip is not the right solution nor is it the best - it is one more random mutation in the evolution of remote communication.
deleted 11y ago
[deleted]
istvan__ 11y ago
Amazon for a long time (maybe even today) used IRC for 1:N communication. I personally like IRC over anything else, but I am probably just too old... :)
fallat 11y ago
IRC+ZNC = backlog support, and WAY more. I don't know why you'd want anything else.
- hobarrera 11y ago
  > I don't know why you'd want anything else. Voice+video just to begin with. The ability to work on poor networks (mobile?), read notifications, delivery notifications.
ara4n 11y ago
This is precisely the problem we're working on with Matrix.org - providing a standard API that can be used to bridge together all of these different protocols in one decentralised model. It's better than Trillian in that the defragmentation happens serverside and you can use any compatible client with it (or one of the existing services if you prefer). For instance, we turned on our first Matrix<->Slack bridge this week - see https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md https://github.com/matrix-org/matrix-appservice-bridge/blob/... for how easy it was.
- deleted 11y ago
  [deleted]
hobarrera 11y ago
Yup, it's a big shame. XMPP promised for quite a while, but then stagnated and failed to deliver what most users were expecting (mostly due to implementations, not lack of protocol features). I've recently given up on IM, and written about it recently: https://hugo.barrera.io/journal/2015/09/21/giving-up-on-im/ https://hugo.barrera.io/journal/2015/09/21/giving-up-on-im/ If only zulip were federated. :(
- kybernetikos 11y ago
  > If only zulip were federated. :( Now that it's open source, could it be made to be federated?
  - hobarrera 11y ago
    It would require changes to the core of the protocol itself, and that all deployments update to a version of the app that implements those changes. Pretty hard, yet possible.

coldtea 11y ago

Only Slack and Zulip are for specific teams/companies, not for the public at large. So there's no "fragmentation" issue, any more that there's one when a company uses Bugzilla and the other uses JIRA.

joesmo 11y ago
We have cross-organization Slack users in our company slack channels and I also have multiple 'organizations', so fragmentation is sometimes an issue.
- epmatsw 11y ago
  Yep, we have a channel for developers that integrate with our product instead of having them email us. It's pretty efficient, but the fragmentation risk is there.
scrollaway 11y ago
This is a very short sighted view. There is a real need for an alternative to IRC - and closed source products do not cut it when we are talking about communication. What parent is talking about is a real problem. There's micro-ecosystems out there around specific closed source products, all of them centralized, none of them compatible... and in the mean time, the only real decentralized, open source group chat solution (IRC) has a lot of issues [1] which shouldn't exist in 2015. [1] https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToBsQ https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...
- chc 11y ago
  As noted in the OP, Zulip is not a closed-source product anymore. But I'm not sure that really helps so much with the immediate problem, since it's more the proliferation of protocols rather than the scarcity of source that causes issues.
  - scrollaway 11y ago
    Yes, that's the title of the thread, you can assume I read that far at least ;) I'll give you I wasn't very clear. I'm super excited Zulip is going open source. And it's both the proliferation of protocols and the closed-sourceness(?) of the products that is problematic. Open source has two coupled benefits: 1. If the product becomes popular, it's easy to integrate with it, extend it, modify it, etc rather than just write an alternative from the ground up. This prevents the proliferation of new protocols just for the sake of an alternative. Right now, it makes no sense for me to go and build a FOSS alternative to Zulip. It would've made sense a few weeks ago. FOSS web services encourage/promote self-hosting. This also counts for something. 2. When extending a foss product, writing a gateway is a lot easier. Gateways don't slow down proliferation as much, but they do keep protocols somewhat close to one another and make it easier for users to migrate from one another. For example: It's been several years now and there is still no reliable open source XMPP-to-Hangouts gateway. But a Zulip/IRC gateway? If one doesn't exist already, I bet you there'll be one within weeks.
    - lwf 11y ago
      We have both already :) https://github.com/zulip/zulip/blob/master/bots/jabber_mirror.py https://github.com/zulip/zulip/blob/master/bots/jabber_mirro... https://github.com/zulip/zulip/blob/master/bots/irc-mirror.py https://github.com/zulip/zulip/blob/master/bots/irc-mirror.p... In addition to Zephyr mirroring, which we've had since 2012.
      - scrollaway 11y ago
        Hurray \o/ Congrats on the release!
danielhlockard 11y ago
Strangeloop (the programming conference) is using a slack, as we speak. it's more than teams :)

sotojuan 11y ago

What annoys me about stuff like Slack is that it's misused. It's made for small teams but I've been 10k people open source projects use it instead of IRC. Of course, it was laggy and they eventually couldn't afford it.

jedrek 11y ago
Obfuscating usernames with real names and no ignore are also massive downsides.
- gkop 11y ago
  Fyi, you can fix the usernames issue in Preferences > Message Display > Message Options.
- CydeWeys 11y ago
  That was the biggest annoyance I experienced at companies that based their communications around IM clients like AIM or Gtalk. My previous company switched to HipChat at some point and everyone showing up as their real name instead of some stupid username was a surprisingly huge improvement.

noobie 11y ago

You forgot Glip too.

Mithaldu 11y ago

And none of them manage to replicate even the most basic of IRC's network solutions in regards to user count scaling and server network combination.

hughes 11y ago

And backlog/offline message functionality is available by turning on logging and using a ZNC proxy. My "buddy list" is just a bunch of direct message channels that I keep open.

draw_down 11y ago

Wow, out of all the things that may have occurred to me over the last couple years of using Slack, "this feels like 1999" is definitely not one of them.

JoshM33k 11y ago

Those types of fragmentation issues never went away, they just changed focus. Whether it is Slack vs. Hipchat vs. Zulip, or WhatsApp vs. iMessage vs. text vs. Hangouts... more options means more (and easier!) ways to contact friends, family, and coworkers, but also means that you have to memorize a "best way to reach me" chart for each individual person.

ossreality 11y ago
>more options means more (and easier!) ways to contact friends, family, and coworkers utter nonsense.
tbingmann 11y ago
Best ask them first via email.
- TillE 11y ago
  I don't even know my girlfriend's email address. I'm 30, and she's only a few years younger. The world is strange now. I miss Google Wave. Not the messy implementation, but the promise of a big influential company throwing its weight behind a modern, open communication protocol.
  - inopinatus 11y ago
    This. This was how I learned that the whole "don't be evil" thing was a load of bovine manure. Google Wave, as an XMPP-based protocol, held enormous promise as a federated rich discussion standard. Sadly their first implementation was clunky and had a confused approach to standards and integration; it was effectively stillborn. Then Google killed Google Talk by strongly favouring their closed "Hangouts" product which is practically inaccessible from chat clients. They went further, making it impossible to federate Google Talk to other XMPP services. Facebook and Microsoft followed suit, either ending XMPP support or closing their federation capability. All three are therefore complicit in the worst abrogation of Internet interoperability since the early days of MSIE. And Google, in a land grab for consumer eyeballs, was the cheerleader.

tmslnz 11y ago

One could say that OS-level notifications could be considered a crude replacement of an aggregation tool like Trillian. We didn't have these back in the ICQ days and today it's easier (read: less painful) to listen on multiple messaging apps. Especially on mobile devices.

petrohi 11y ago

<shameless plug> We at sameroom.io do this in sort of backend-only way. </shameless plug>

ex3ndr 11y ago

We (https://actor.im https://actor.im) are actually working on this, but not trying to connect slack, but building telegram, skype, whatsapp, social networks to one, slack like interface that will help you easily manage communications from many networks. This is not our main feature, just something like side project.

zobzu 11y ago
that would be great. what would be greater though is ensuring that actor.im cannot read the data as it transits (or easy to setup on our own local machines) I'd pay a good bit for that!
- ex3ndr 11y ago
  We had e2e encryption in the past, but we decided to make one click install of your own server or may be just key infrastructure to make everything cool.
stevemartingale 11y ago
This looks cool. FYI notifications is misspelled as "notificaitons" in the paragraph under "I don't believe in messaging. Email is better".
hobarrera 11y ago
"Mobile First" This is the regrettable de-facto standard. I'd like to see the opposite: a network that provides native desktop clients. Telegram seems to be the only one taking this seriously up to now.
hobarrera 11y ago
I also really dislike the idea of having to register with a phone number. I reminds me of ICQ, where I had to dig up some obscure number to log in. Except, I also lose my account permanently the moment I lose my phone.

zobzu 11y ago

+300.

austenallred 11y ago

There have been and always will be competing products and communities that serve similar purposes. We use what we think is the best one. Is this a bad thing? (Not to mention the fact that Slack is for internal teams, not for IRC-like discussions, though our open newsroom (http://newsroom.grasswire.com http://newsroom.grasswire.com) and some other communities (http://fpchat.com http://fpchat.com) have repurposed it for that.

inopinatus 11y ago
I think that "best tool for the job" attitude is a straw man. It seems to presuppose that "the job" is per-organisation, or even that there is one job. In truth many of us believe that the goal is enabling everyone - universally - to communicate without a single body holding centralised control of message history, reachability and access. Quick review of the globally federated protocols: Email is too slow and bulky and lacks "group" capability IRC is deeply unreliable and lacks identity, archiving, and media management NNTP is too amorphous, slow, and lacks any privacy or security controls Everyone thinks SIP is just for telephony (it isn't) XMPP is phenomenally complicated yet held great promise - if only everyone could agree on the extensions and semantics. - but was murdered by Google.
- austenallred 11y ago
  No, it presupposes that there is a defined task. I suppose the difference between our points of view is that I would much rather have a better tool than a publicly accessible archive of message history.
- e12e 11y ago
  You forgot h.323. On the surface, it looks to me like a "saner SIP", or XMPP with working, standard audio/video support -- but I might be wrong. I'm not sure why people claim IRC lacks archiving support. Isn't a bit like saying SMTP lacks archiving support? And doesn't basic IRC always go through a server? So there shouldn't be any technical barrier against a server archiving all chats (private and in channels)? As for NNTP, I'm not sure if NNTP over TLS, peering with only trusted sites (aka for internal use) would make sense or not. I never did use Usenet much. At least the D language forums have made an effort to bring NNTP into the www era[d]. It's interesting that no one seems to do a decent job of (server side) archiving for XMPP -- partly I think it's because as you state, the XEPs have gotten out of hand -- and partly XMPP appears to be especially popular for users that want privacy -- and treat ephemeral chat as a feature. [d] https://github.com/CyberShadow/DFeed https://github.com/CyberShadow/DFeed (format note, you probably should've just listed the protocols in separate paragraphs, as indented blocks with lines longer than ~50 characters doesn't format very well on hn).

lifeisstillgood 11y ago

But this is about social norms, not technology. Hear the phrase "remote workers...tap lightly on the shoulder". We have had thousands of years to work out our nuances over interruptions and social signals when around the same campfire. But suddenly (and from the past 20-30 years suddenly) we have phone conferences where half the conversation is "no, sorry, you go ahead" and email going from killer app to no longer being a way to get a reply in ten minutes but two days because the signal to noise ratio hit a tipping point somewhere around 2006. (No it's not spam, that's mostly a done problem. It's co-worker spam that's clogging our minds of not our inboxes) So the differences between Zulip and Twitter and Slack and IRC and Microsoft bloody communicator why does it not know about tabs ffs! (Sorry). The difference with all of these is not their technology - it's pretty much the same all the time - but their social utility. One day some comms package will get it all together (I think there is too little context to get it right yet) and we will all go"of course". Until then we will try each different social choices baked into the code - rooms or tags or whatever. Maybe the next step is to have rooms for something, open cry for others. Who knows - maybe we should look at pubs bars, libraries and streets for inspiration. Whatever it is - Zulip is not the right solution nor is it the best - it is one more random mutation in the evolution of remote communication.

deleted 11y ago

[deleted]

istvan__ 11y ago

Amazon for a long time (maybe even today) used IRC for 1:N communication. I personally like IRC over anything else, but I am probably just too old... :)

fallat 11y ago

IRC+ZNC = backlog support, and WAY more. I don't know why you'd want anything else.

hobarrera 11y ago
> I don't know why you'd want anything else. Voice+video just to begin with. The ability to work on poor networks (mobile?), read notifications, delivery notifications.

ara4n 11y ago

This is precisely the problem we're working on with Matrix.org - providing a standard API that can be used to bridge together all of these different protocols in one decentralised model. It's better than Trillian in that the defragmentation happens serverside and you can use any compatible client with it (or one of the existing services if you prefer). For instance, we turned on our first Matrix<->Slack bridge this week - see https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md https://github.com/matrix-org/matrix-appservice-bridge/blob/... for how easy it was.

deleted 11y ago
[deleted]

hobarrera 11y ago

Yup, it's a big shame. XMPP promised for quite a while, but then stagnated and failed to deliver what most users were expecting (mostly due to implementations, not lack of protocol features). I've recently given up on IM, and written about it recently: https://hugo.barrera.io/journal/2015/09/21/giving-up-on-im/ https://hugo.barrera.io/journal/2015/09/21/giving-up-on-im/ If only zulip were federated. :(

kybernetikos 11y ago
> If only zulip were federated. :( Now that it's open source, could it be made to be federated?
- hobarrera 11y ago
  It would require changes to the core of the protocol itself, and that all deployments update to a version of the app that implements those changes. Pretty hard, yet possible.