I’ve blogged numerous times about XMPP, SMTP, and communications evolution on the web. I’ve suggested what I want ultimately and snippets of how we might get there. Here, I am going to outline just briefly what I consider “next steps”. The big ones. Get these done, and you will have made a *huge* stride in online messaging:
- Allow offline messages (type normal or chat) to be collected as “email”. Gmail sort-of does this by presenting unseen offline messages in the web interface inbox. I want IMAP access to these in the inbox and their archive. Heck, store them in a Unix mailspool (have to store them somewhere anyway) and existing IMAP servers will just work for you!
- SMTP messages are type=normal. If you store offline messages in a mailspool and run an SMTP server on that spool, you’re mostly done. Might be good to offer real-time deliver of those messages to the user of XMPP as well though.
That’s it! Sure, more can be done, but if you get the first one done I will be your biggest fan. Do both and you’re well on your way to an evolution in how we deal with email (both from a user and a protocol perspective). Yes, I’ve tried to build this. I want to do it as an ejabberd module, but ejabberd is barely documented. I’ll try again sometime if no one else does – maybe with ejabberd, maybe with someone else.
The idea is out: XMPP is a perfect replacement for SMTP. SMTP (the current standard e-mail program) is outdated for a variety of reasons, such as the fact that it’s not SPAM resistant and that you can’t know for sure (easily) who sent a message.
XMPP (a.k.a. Jabber) solves a lot of this and is a fully extensible protocol that has already been adopted as a standard for IM. The benefits are many, and there is only one major hurdle: every server on the Internet would have to change software!
Regular readers may be able to guess my (and others’) solution to that problem: backwards compatibility! When using XMPP for primary email, one must provide a bridge back to the SMTP world. There’s no real way around that for now. Fortunately, it’s not too hard. There are a few options:
- Write a client that supports both XMPP and SMTP (through POP3 or IMAP) and have an identical address on both networks (think @gmail.com).
- Modify (/write) an SMTP-based mail server to support XMPP.
- Modify (/write) an XMPP server to support SMTP.
I really believe option #3 is the way to go.
What else may be required for this to become a reality? Well, some way of keeping the traditional email experience (at least somewhat) may be required for the masses. This means things like an inbox (for non-chat messages) and tags for message history. Gmail actually already has this for offline messages. There was also some work in 2004 on an XMPP client that supported something like this.
Some say that the encoding of emails must be retained. I think this is bunk because it defeats the purpose of changing protocols and killing the old standard. Some thought does need to go into the handling of offline payloads (especially file transfers / email attachments). I think data: URIs may work for this, but something better may be in the works.
All it takes is one person who decides to adopt this as their primary way of functioning. They develop some software, and it spreads from there. I’m sticking with GTalk servers for Jabber for now (although I have the power to run my own @singpolyma.net), just because it’s easier for people who already have that address (I hate having multiple addresses). What I’m really waiting for / looking for is a decent client for this. Gmail has IM built in and handles this model for offline messages well, but it is not really even possible to reply to emails via Jabber, et cetera. GTalk interfaces (including Gmail) actually don’t support any XMPP message type except chat well just yet. We’re getting closer to something that could work though.