Hacker News Reader

Comment by PaulHoule | Hacker News Reader

Email is "good enough".

The real hole is "instant messaging". Somehow every few years we got from ICQ to AIM to Paltalk to Skype to Facebook Messenger to Slack to ... (at least Altassian had the decency to take HipChat behind the woodshed and shoot it)

The strange thing is that these services dry up, blow away, get replaced, but they don't seem to improve on what came before.

There is a standard, XMPP, but the only people who care about it are firefighters, cops, and soldiers. For all the anger at internet giants these days, I can't see for the life of me why people aren't pushing for open instant messenging.

View on HN

XMPP’s problem isn’t that people don’t care about it. Its problem is a double whammy of having zero branding/mindspace presence and being too technical for many users to bother with.

The second point is especially big. People expect to be pointed to a singular app/site, not “choose whichever client you like”. Your average Joe just doesn’t conceptualize services as being separate from clients in the first place, and even if they did having to choose a client is a dead end.

I totally agree with that. I've good experiences recommending Quicksy[1][2] though. It makes not only account creation easy as pie, but also helps people finding their peers by their phone numbers.

Give it to your average Joes and Janes and they will just use it like any other messenger. But since it is pure XMPP, can just use any other Jabber account to chat with them. :)

I recommended it a lot the last weeks and most of my pals just use it without any hassle. At least in my bubble most of the people have besides WhatsApp also Telegram or Viber or WhatEver installed. So it's for them Quicksy is just yet another app. But this time one, which helps to get out of the walled garden. :)

[1] https://play.google.com/store/apps/details?id=im.quicksy.cli... [2] https://quicksy.im

Well, there's [Matrix](https://matrix.org) in this space which I would characterize as pushing.

I didn't explain it fully, but the alternate future I was imagining was one where SMTP could evolve/instantiate a connection for "ASAP email" -- AKA instant messaging. Kinda like how HTTP can upgrade to websockets.

There would obviously be a lot to work out, but if something like this was in the SMTP standard (or at least introduced), I think eventually email providers would race to differentiate themselves with support for it, and we might not be where we are today. In my view there's no reason to even require the SMTP servers to serve chat traffic -- as long as they could hand off reasonably, and everything spoke the language as specified in the spec (or at least came close).

I don't want instant messaging in my email though. If you need synchronous communications, use a chat client.

This is probably where we differ -- I don't think limiting email to asynchronous communications helps anyone, and it could have been written in an extensible manner to also support synchronous communication.

Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents.

> Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents.

Wouldn't this be best handled with SRV DNS records or some other service discovery process outside of SMTP?

https://wiki.xmpp.org/web/SRV_Records

I agree that it would be but my wanting to bundle it with SMTP is for forcing the linking of the two concepts -- I guess my argument is less technical and more that I think the two concepts should have been linked early on -- I think if we'd bundled email and instant messaging (aka "live" or "instant" email), we would have encouraged service providers to offer the service in a standards compliant way.

I don't have a preference on exactly how the service discovery would work -- I'm merely suggesting instant messaging could/should have been an extension of the SMTP spec like websockets were an extension of HTTP.

[EDIT] - Looking over the link you sent, that is exactly what would have made a good addition in my mind -- if SMTP had some sort of functionality to suggest that XMPP was available and where to check (DNS SRV records)

After thinking about it some more, I agree with you. There should be some command or extension in SMTP and JMAP that, if the user permits it, the availability of XMPP could be exposed and a redirect of some sort could be provided (similar to intentions on iOS).

IRC works pretty well. I really fail to understand why any tech project puts their chat on Slack/Discord/Whatever when IRC is easy and open.

First, IRC isn't easy for newbies. I tried to adopt it at the first tech company I worked for, and our support folks had a lot of trouble getting the basics down. There could be a client that makes things easier, but I've never seen one as easy as Slack.

Second, IRC alone doesn't provide a bunch of features that everyone expects nowadays. You have to host or pay for a bouncer if you want to see what was said when you were offline, for example. Gotta use a 3rd party service for push notifications on iOS. Again, there's no reason why this couldn't exist, but it's another product, not just IRC.

> IRC isn't easy for newbies. I tried to adopt it at the first tech company I worked for, and our support folks had a lot of trouble getting the basics down. There could be a client that makes things easier, but I've never seen one as easy as Slack.

Years ago, I started out with mIRC on Windows 95. I didn't know many IRC commands, but as I recall, you could navigate through the menus to do things like list channels, join them, part from them, etc. So, I don't think that an application like that should be any more difficult to use compared to Slack.

Reply on news.ycombinator.com