[tbingmann]

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.

[JoshM33k]

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.

[shanemhansen]

Every week I have to use a Cisco jabber client, Hipchat, Slack, and Hangouts within the same company.

I know it's got less of a "cool" factor because it wasn't invented last week, but I soooo wish everyone would just use IRC. Use irccloud if you want some nice apps and picture embedding.

[rikkus]

Is it possible to get what Slack provides using IRC? I mean the whole package, not just the text chat. Consider enterprise-friendliness, excellent mobile clients, zero-setup required (no separate keep-you-online relays), really easy integrations, etc.? We are adopting Slack because it's great and I'd have loved to make a case for IRC but I wouldn't know what server to recommend (we don't really want to install it, but we don't want to use a public server), where I can get commercial support, if there's a nice client (like irccloud is) for mobiles - there's a long list, unfortunately.

[inopinatus]

Also in-client searchable archives, media handling, history editing. All require going outside the IRC protocols.

IRC was designed by hackers, for hackers and it shows. Twenty years ago, IRC was my talk destination of choice and I operated a server within a major IRC network; these days my startup uses Slack which I determined to be the "least irritating" of the 21st century options.

I had high hopes for Google Wave but it was sadly stillborn.

[e12e]

Much of that can be had with a IRC bot. That doesn't include media handling, but you could do search via 1-on-1 /msg (query) with a bot. Then it'd truly be "in client" search.

Most would probably prefer a web ui, with search -- but recording chat could still be done via a bot.

I wouldn't say you could get most of the whole slack experience with just IRC, and you'd probably have to do some work (if only configuring channels/bots/find a web ui etc).

[inopinatus]

This doesn't resolve the multifarious issues with identity, reliability, scalability, federation, standardisation &c &c that further rule IRC out from being the universal panacea.

[ara4n]

Matrix.org is heavily inspired by Wave, albeit using HTTP rather than XMPp, for those searching a more alive option :)

[bjeanes]

> I had high hopes for Google Wave but it was sadly stillborn.

Yeah me too. Google really effed that one up. RIP

[scrollaway]

The closest you can get is a foss slack alternative such as Mattermost, and push for an IRC bridge (Mattermost is working on it it seems: https://github.com/mattermost/platform/issues/650).

But it's not possible to get what you're asking without breaking the IRC protocol - it's not easily extended and the formatting rules are icky mIRC crap.

[voltagex_]

Go help with IRCv3 - you're talking about capabilities, which are part of the v3 protocol.

http://ircv3.net/specs/core/capability-negotiation-3.2.html

[XorNot]

The trick with capabilities is you need them to be reasonably standard. Which means the go to IRCv3 server should ship with them turned on, and the reference client should be capable of using them.

[bjeanes]

Slack's IRC bridge is actually pretty good. I know that's not quite what you're asking, but at least you personally could still interface using IRC.

[jwheare2]

Any reason you rejected IRCCloud? (disclosure: my company). We host private servers for teams and do the majority of what you're asking for.

[rikkus]

I didn't make the decision. Slack started to appear and I didn't know that IRCCloud had apps (which seem to have great reviews). If I had known, I would have suggested it as an alternative. As it was, I just kept quiet as Slack seemed great - even better than HipChat, which I used to use for the same purpose.

Perhaps IRCCloud could be sold as a rebranded Enterprise app as an alternative to Slack? I'd love to see some competition as it looks like only HipChat and Slack are getting talked about.

[hermanradtke]

I don't use it because I want to use my own irc client and not a web interface. I want ZNC as a service.

[bsimpson]

That sounds like a problem with the company. I can understand Slack and Hangouts (at least until Slack adds voice chat), but all that other stuff sounds like poor organization on the company's part.

[voltagex_]

What I posted in another thread still stands - https://news.ycombinator.com/item?id=10256943. Things were better when everything was brought under one client. I know iMessage is almost impossible to reverse-engineer (due to Apple kicking non-iClients off) but I wish there was more effort going into reversing Hangouts. Someone's emulated the JS client from GMail but that's about as far as it's got

[CydeWeys]

IRC's lack of scrollback alone kills it for these considerations, unfortunately. If there's an incident or discussion in progress and you only join the room partway through you have no way of catching up to speed.

[epsylon]

That's what bouncers are for.

[anentropic]

you wish everyone would use the worse option?

[rdtsc]

They were on their way out as some services were federating via XMPP. Then some stopped supporting it.

[scrollaway]

Sad as it may be, it's pretty clear at this point that XMPP won't be the communication protocol of the future. Everyone who ever seriously worked on it seem to have come out of the experience a broken man. Setting it up requires pretty deep knowledge and the promises of compatibility with most XMPP servers break down pretty fast unless you know which extensions to support.

All these problems are fixable but I don't see the tide ever actually changing direction and "hey suddenly XMPP is cool again, we should all use it".

One thing is for certain... humanity needs standard, open and widely-used protocols for communication. And there's a lot of ground to cover: Text, audio, video; single and multiuser; topical (IRC-like); social (invite-based/people I know); Synchronous (IM) and asynchronous (email/offline messaging)...

XMPP tried to do a lot of that. Maybe it tried to do too much. Maybe you just can't do all that in one protocol. I don't know, I just hope we'll get there soon - if nothing else, I'm tired of maintaining those "best way to reach me" charts JoshM33k is talking about.

[catern]

>Setting it up requires pretty deep knowledge

Not even remotely true! Prosody on Debian works out of the box, including federation. You just have to configure the domain name.

It's not hard to set up an XMPP server. It's hard to set up Ejabberd. Ejabberd is not the only XMPP server. Prosody is very easy to set up.

Honestly, people, think before you speak...

[scrollaway]

> Honestly, people, think before you speak...

I didn't just make this up on the spot, I've been dealing with these issues for years. So yes, I've thought about them a lot.

I used to run a prosody server on my home box. It is great software and a fantastic daemon compared to ejabberd (edit: Configuration-wise that is) but fat lot of good that does if you don't know what XEPs to set up when dealing with other servers. I shut it down because it was pretty much useless and I wasn't able to talk to my gtalk buddies from it anymore.

[catern]

> fat lot of good that does if you don't know what XEPs to set up when dealing with other servers.

I have no idea what XEPs to set up when dealing with other servers. I did not have to set up any such thing. Like I said, federation (server to server communication) works out of the box, at least on Debian.

[sanderjd]

Your comment is informative, but the last sentence is unnecessary and inflammatory.

[catern]

You're right. I would delete it, but it's past the edit deadline.

[PhasmaFelis]

> Honestly, people, think before you speak...

Was that really necessary?

[dorfsmay]

I've been using OpenFire, no problem there either.

I had never heard of Prosody, any major difference cons/pros between the two?

[rdtsc]

Yap. Agreed. XMPP looked good on paper, if you read just the mission statement. Thinking back, I tried to dive into it once and nope-d out of it quickly. I guess I just blocked that experience out of my mind for some reason.

[fletchowns]

Who might be the right entity to take on creating a replacement for XMPP?

[scrollaway]

¯\_(ツ)_/¯

One of the best things that could happen today I think is Google open sourcing the Hangouts protocol. It's a reasonable alternative to XMPP and has a massive userbase. The clients are pretty horrible but that might be completely unrelated to how good the protocol is (Note: I have no idea how good it is. Because it's closed source.).

I was hopeful for a while but I don't really see it happening anymore :( Oh well...

Edit: Oh and the worst part: Communication is just one side of that coin. The other side is identity and it's one hell of a side. OpenID was a disaster. Mozilla got it mostly right with Persona but completely botched the marketing and has all but given up on it now. There is no decent foss protocol for identity/authentication today other than Persona, and nobody is working on one. There was a time indeed where I could've pictured Google working on solving this just for the hell of it. Just because it would improve the world. That Google is gone, and there's nobody with the appropriate reach that seems willing to do it now.

[StavrosK]

I will forever mourn and be angered by Mozilla giving up on Persona so easily.

[e12e]

Has anyone got experience with both XMPP and SIP/H.323? From what I've been able to figure out, H.323 looks like it's one of the better candidates of protocols that exist today and is "reasonably" simple... while SIP... well, SIP smells a lot like it came from big TelCos. And not in a good way.

See eg: https://www.packetizer.com/ipmc/h323_vs_sip/

[lstamour]

Identity is a separate problem. So far, https://www.accountchooser.com and OpenID is winning -- if by winning you mean maintaining a list of very popular email providers and using their APIs. ;-)

[ocdtrekkie]

Yeah, I can't see Google ever either open sourcing Hangouts, or making it possible to federate it. Google's opinion seems to be that everything that is a service or protocol should be a Google API.

[vbezhenar]

https://matrix.org is a promising candidate.

[scrollaway]

I remember reading about matrix when they first announced. Was pretty excited about it, haven't heard anything since. I It's just tech though; even if it's mind-blowingly great, won't do much good if no large-scale userbase picks it up somehow.

[ara4n]

Whilst we're not trying to replace XMPP, Matrix.org does provide an entirely different architecture (decentralised and evetually-consistent history, high baseline feature set, HTTP-based, etc) that can be used for group chat/VoIP/etc.

[sitkack]

I don't know who will do it, but it will be in-band, meaning inside http and using html5.

[rekoros]

I did some research on XMPP interop and its demise (ignore the title) - https://sameroom.io/blog/announcing-support-for-google-hango...

[hobarrera]

At some point it did fade a bit. About 2-3 years ago enough people were using XMPP/Gtalk so that I could reach about 80% of my acquaintances thought it.

Now, there's no single network that holds over 25% of them. Except facebook, but most of them don't actively use facebook every day, nor pay attention to it's IM.

[tbingmann]

Best ask them first via email.

[TillE]

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]

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.

[CydeWeys]

Weird. I'm 30 too and I know all of my acquaintances' email addresses. How do you not know your girlfriend's email address? You can't even do something as simple as forwarding her your travel tickets so she knows your itinerary, or a receipt for concert tickets so she knows when it is, or send out a group email with details of the time and location of your party, etc.

Email was drifting off for me a handful of years back, but ever since smartphones ascended email has experienced a huge resurgence. I'm likely to use it in preference to SMS for (a) longer messages and (b) messages with multiple recipients (e.g. your standard activity planning emails).

[morganvachon]

It would be nice if the iOS and Android built-in Contacts apps had better support/integration for all the various messaging apps that work on their respective platforms. Rather than trying to remember who uses which services, their contact card could simply contain the entire roster of their services and usernames, and you could initiate a conversation in that service from within the contact card. I know you can do this with the baked in messaging services for each platform (SMS/MMS and iMessage for iOS, SMS/MMS and Hangouts for Android), but I'm talking about a one-stop-contacts-shop for every major messaging platform. Maybe that would require too much cooperation between messaging app authors and the big OS vendors, but I think it would be possible.

An alternative solution would be a cross platform third party Contacts app that offers that kind of integration. I've seen multi-messenger apps (Trillian, IM+) for both platforms, but that's not quite the same thing and it inevitably leaves out important functionality from the official apps.

[andrewaylett]

That they don't on Android is due to the app, not the platform - if the client adds contact integration, it gets listed in the contact's card. Lync, of all things, is a good example of this. I'm pretty sure Skype does too.

[morganvachon]

I wasn't aware of that, thank you. I haven't used an Android phone in a while.

[coldtea]

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.

[scrollaway]

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

[coldtea]

>This is a very short sighted view. There is a real need for an alternative to IRC

There might be one -- but this is absolutely not what this and Slack are aiming to do.

>and closed source products do not cut it when we are talking about communication.

Not sure about that. As it seems, for 99% of the world who only uses "closed source products" for chat, they do cut it. (Interoperability is orthogonal of course).

[scrollaway]

Slack and IRC are room-based, semi-synchronous, topic-centered communication protocols with support for direct messaging.

Slack literally took the concept of IRC and put a bunch of cool bells and whistles on it. They updated it, centralized it and sold the idea as an enterprise solution. It works great, and the tech could be a kickass replacement to IRC, done correctly.

[mikekchar]

I don't really disagree with you... but I often wonder how much Slack actually adds to IRC. We use it at work (and as a 100% remote person in a mostly co-located team, it is a godsend). I can't really think of anything in Slack that wouldn't be easy to implement with IRC bots.

Persistent history is easy. Email notification is easy. Storage of various assets like text snippets and pictures is easy. I've never used any, but I'm assuming that at least one of the web interfaces for IRC works well...

I think the main thing that Slack has done is package it up so that you don't need to cobble together 100 different things -- which is, of course, very valuable. Or at least more valuable than the monthly cost that they charge ;-)

To be honest, I would really rather be using free software. I would be quite happy to pay for a service that made it easy for me (as Slack does), but software freedom is valuable to me.

[scrollaway]

I've wondered the same. Like you said, though, there is value in packaging useful features together.

IRC is "You could do that ...", while Slack is "You can do that". So like you're saying, you could set up a bunch of channel bots (And for what it's worth, I think channel bots are fairly ugly. If I say "Let's work on #133", I want #133 to be linked, I don't want a different user spewing 3 lines of noise and a long link). But most people won't do that because it's too much of a hassle. So most of IRC does not showcase what's really possible.

Like I mentioned in the g+ rant I linked above, it'd be possible to improve this by adding scripting features and such to IRC servers. But nobody's doing that. The harsh reality is that "could" is a long, long way from "can".

> To be honest, I would really rather be using free software.

Me too, man. Me too. I don't use Slack out of principle, and I'm a heavy IRC user. Sadly it doesn't often compare :/

[zyxley]

> There might be one -- but this is absolutely not what this and Slack are aiming to do.

That's kind of a weird statement to me, because every time I've sold a techie-type person on Slack it's been by describing it as "private IRC with persistent history and a bunch of other neat things".

[twic]

private IRC. Hence global interoperability and federation is not what this and Slack are aiming to do.

[scrollaway]

You're missing the point. Just because it's not what they're aiming to do doesn't mean the tech isn't appropriate for it.

You're commenting on their business model rather than the tech. For all you know, Slack could be planning to expand their business to hosting public chat rooms, then your comment wouldn't make any sense anymore.

[coldtea]

The "private" part kind of gives their game away, doesn't it?

It's not meant to be an IRC replacement. That it has point to point communication, channels etc, doesn't make it IRC.

Slack is all about the default stuff it bundles with it, and the features it includes as native for work teams.

[rdtsc]

The problem is not just the open vs closed source. Even if Google, Yahoo, Slack all open source their products. You'd still not be able to send messages from one to another unless they also federate at the protocol level.

So you can be connected with a universal "messaging" client to any of the available servers then send messages to someone on Google, or Slack etc.

[chc]

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]

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]

We have both already :)

https://github.com/zulip/zulip/blob/master/bots/jabber_mirro... https://github.com/zulip/zulip/blob/master/bots/irc-mirror.p...

In addition to Zephyr mirroring, which we've had since 2012.

[scrollaway]

Hurray \o/ Congrats on the release!

[lips]

But one more protocol on the stack with mac/windows/iphone/android clients is, IMHO, an entirely different ball of wax than a libre project with only a single platform under its belt. In my situation, the existence of mobile clients is clinch for actually pitching it to any org I participate in.

[joesmo]

We have cross-organization Slack users in our company slack channels and I also have multiple 'organizations', so fragmentation is sometimes an issue.

[epmatsw]

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.

[danielhlockard]

Strangeloop (the programming conference) is using a slack, as we speak. it's more than teams :)

[peruvian]

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]

Obfuscating usernames with real names and no ignore are also massive downsides.

[gkop]

Fyi, you can fix the usernames issue in Preferences > Message Display > Message Options.

[CydeWeys]

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.

[Mithaldu]

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]

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.

[lifeisstillgood]

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.

[ex3ndr]

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

[hobarrera]

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.

[hobarrera]

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

[stevemartingale]

This looks cool.

FYI notifications is misspelled as "notificaitons" in the paragraph under "I don't believe in messaging. Email is better".

[zobzu]

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]

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.

[ara4n]

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/... for how easy it was.

[austenallred]

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) and some other communities (http://fpchat.com) have repurposed it for that.

[inopinatus]

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.

[e12e]

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

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

[inopinatus]

Good thought re.H.323, it is often forgotten in these discussions, in part because many implementers resent binary protocols and the ITU has few friends outside the telephony world. https://www.packetizer.com/ipmc/h323_vs_sip/

The IRC protocol is neither sophisticated nor scalable enough that we can all federate our private trusted IRC servers. IRC services are severely limited by being a brittle undirected acyclic graph of servers with little but text forwarding in the protocol. Trying to do anything sophisticated like e.g. identity management, is an ugly business.

NNTP has no identity scheme and no private channel. Running it over TLS doesn't change that. You can forge an ersatz private channel with encryption (I once did so, using Usenet as a message queue to backhaul out-of-band service alerts) - but it's neither pretty nor grandma friendly.

[austenallred]

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.

[hobarrera]

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/

If only zulip were federated. :(

[kybernetikos]

> If only zulip were federated. :(

Now that it's open source, could it be made to be federated?

[hobarrera]

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.

[draw_down]

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.

[tmslnz]

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.

[istvan__]

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

[petrohi]

<shameless plug>

We at sameroom.io do this in sort of backend-only way.

</shameless plug>

[fallat]

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

[hobarrera]

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

[zobzu]

+300.

[noobie]

You forgot Glip too.