I really want to see some innovation in the email space. The landscape is like a sea of false promises and dashed dreams. SMTP is one of the bread-and-butters of the internet, yet it just doesn't seem to be moving forward (maybe that's for the best), and no one's building extensions on top of it.
Maybe I'm naive in thinking it was possible but we could have avoided this whole "make an account on X messenger so we can talk", if someone had just jammed XMPP and SMTP together.
Every few years I'm tempted to try and write a SMTP server (MX) myself but then realize that postfix has been around so long and is the go to choice for a reason. I don't have 20 years of figuring out how X mail server interprets SMTP to be as reliable as postfix. I settled for trying to wrap it[0].
Yes, postfix has been around for so long and it is very solid. However, to run a mail server nowadays, it still needs a lot of configuration work and even additional daemons to add SPF checks, forwarding with SRS, and DKIM signatures. All of this is possible to be added though, which speaks for the flexibility of the postfix design.
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.
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. :)
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).
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?
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).
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.
The official reason for Google to give up on this is that there was a real problem of incoming spam from lousy domains, and no major player wanted to play the federation game with them. It's not as simple as you make it sound.
1) they are able (forced to) handle spam for Gmail (and internally for gtalk) - I'm not convinced by the spam argument.
2) there were only two "big" players, Google and Facebook. The benefit of federation would be as with email: an open internet with federation across organisation level services (community/company run servers).
The fact that Google didn't implement ssl for federation doesn't mean people "wouldn't" federate with them, it mean Google didn't make a real effort.
Yes. And the vision for Google Wave was great. The execution was just abominably bad (primarily on the frontend/UI side), and Google's failures in execution carried over reputationally to the—now dead—Apache incubator.
Not just the UI side. The underlying protocol was also pointlessly over-engineered. SMTP is still around because it is simple. You can get a basic SMTP client running in an hour or two. You can get a basic server running in a similar amount of time, at least in a higher level language. That matters, not because anyone will have anything usable in that time, but because it lets you start to experiment very, very easily.
Wave suffered from a UI that was a mess layered on top of a protocol that made it really hard for people to get started on experimenting with alternative frontends, and without a user-base giving people a reason to persist figuring out how to interoperate with it. Had the protocol been simpler, the UI mess might not have mattered so much - people might have come up with their own ideas.
Further than that, it seems to me SMTP is functionally included inside XMPP so there's no need in mixing them. Perhaps having an SMTP gateway that feeds into an XMPP server at most.
Yes, but no -- I wasn't one of the Google Wave faithful so I don't know the ins and outs of it, but I what I wanted was the ability to extend SMTP all together to include the possibility of negotiating XMPP -- almost like what's happened with HTTP 1.1/2/3 evolving to support new connection types and content types/etc.
It was sometimes possible to hold realtime conversations over email, before the amount of required spam processing became too high. There's no protocol reason why you can't do that between servers, although getting it into a client requires either IMAP push or something more modern.
> make an account
You are required to make an account somewhere so your account can be banned if you spam, basically.
Honestly I'm surprised no one has suggested replacing SMTP with a HTTP POST request. All you would need is an email address -> HTTP URL conversion (which I believe something like WebFinger already has). Then just POST your message to that URL and you're done. ISPs can run proxies that just authenticate that requests are from users and forwards them on.
But we do. The "re-inventions" just tends to be increasingly subtle, because the high level structure continues to make sense and the overall designs are simple to begin with, which makes it hard to come up with revolutionary new ideas in the space.
Umbrella's for example see continuous evolution in means of making better fully collapsible versions, making the deployment more automated, reducing weight, etc.
From Wikipedia, illustrating both that there's continued substantial effort in coming up with new ideas, and at the same time that it is hard to come up with something genuinely new:
> Umbrellas continue to be actively developed. In the US, so many umbrella-related patents are being filed that the U.S. Patent Office employs four full-time examiners to assess them. As of 2008, the office registered 3000 active patents on umbrella-related inventions. Nonetheless, Totes, the largest American umbrella producer, has stopped accepting unsolicited proposals. Its director of umbrella development was reported as saying that while umbrellas are so ordinary that everyone thinks about them, "it's difficult to come up with an umbrella idea that hasn’t already been done."[36]
They are significantly more, but it's not just replacement cost avoidance that's the benefit. They are easier to handle in wind, keeping you dryer and not having to fight the umbrella.
People come up with ideas for frustrating things they have a lot of contact with; seemingly every HGV driver has "invented" a way to automate matching cab (ie tractor) plates to trailer plates.
People buy cheap umbrellas, they suck, the people imagine better umbrellas that cost more: goto START.
A 9yo of my acquaintance is really inventive; he often says "what if we had something that would ...", yes, if you'd invented and developed that 50 years ago you'd have been a multi-millionaire.
A lot of inventions arise naturally out of a creative mind being confronted with the problem.
Maybe I'm naive in thinking it was possible but we could have avoided this whole "make an account on X messenger so we can talk", if someone had just jammed XMPP and SMTP together.
Every few years I'm tempted to try and write a SMTP server (MX) myself but then realize that postfix has been around so long and is the go to choice for a reason. I don't have 20 years of figuring out how X mail server interprets SMTP to be as reliable as postfix. I settled for trying to wrap it[0].
[0]: https://gitlab.com/postmgr/postmgr