4 ms·

What I've really wanted to figure out for awhile now is how XMPP might work as a replacement for email. Even as new IMAP or Gmail clients appear on the market s

What I've really wanted to figure out for awhile now is how XMPP might work as a replacement for email. Even as new IMAP or Gmail clients appear on the market seemingly every few months now, I can't shake the idea that it's time for a new protocol, alas an impossibly tall order. Yet XMPP seems like the closest thing to an existing, modern standard to build upon. Am I tilting at windmills, or is there any validity to this idea?

AndrewDucker 14y ago
What, exactly, do you want to do with it, and how does it replace email? (Genuinely curious - I see suggestions for replacing email on a regular basis, but rarely ones that are deeply thought out.)
- fbeeper 14y ago
  Sometimes even the topic is what makes the difference (not even location or device) between talking synchronous or asynchronously. I'm not a very assiduous Facebook user, but at some point I've noticed it can blur the edge between sync/async. Maybe it is not perfect (and maybe it is no longer there), but I think its possible to mix both ideas. Neither should be left out.
- mortenjorck 14y ago
  There are some fairly general reasons, like XMPP being a much newer, extensible (it's in the name!), yet mature messaging protocol with a big community, but there are also some specific ones. One of big potential benefits I see is the XMPP concept of contact requests. Simply separating new senders from existing senders at an architectural level seems like a great start for an email replacement, both in terms of user experience ("who I know" is fundamentally separate from "who I don't know" regardless of the client), and in network utilization (spam is only ever as long as a request header instead of an entire message).
  - AceJohnny2 14y ago
    XMPP is focused on real-time, synchronous communication. It does provision for async communication with server storage of offline messages, and even originally discriminated "chat" messages from "email"-type messages with multiple recipients and a subject. IIRC, this latter feature is deprecated as the protocol developers focused on real-time stuff. Because in the end, and despite all its kludges, e-mail doesn't need replacement. Its biggest problem remains spam, and even that is under control by all the major providers.
qznc 14y ago
XMPP is not that clear [0] what happens, if the recipient is offline. I'm not sure, what the popular servers (Google, Facebook, etc) do in practice. As a proof of concept. It should be easy to implement a "shortcut send" into an email client, which sends a mail directly over XMPP, if sender and recipient are both online with this client. [0] http://xmpp.org/extensions/xep-0160.html http://xmpp.org/extensions/xep-0160.html
- dscrd 14y ago
  I have witnessed somewhat normal network situations (being connected to XMPP server while connecting / disconnecting to a VPN server) that have caused a stable and mature Jabber client (psi) not actually send messages even though it seems that it did successfully send them. For a mature messaging protocol, that smells really really bad for any serious use.
hoverkraft 14y ago
I've thought about this, too. Certainly much communication on the modern internet is realtime, so arguably a protocol based on realtime communication makes more sense than a protocol conceived for asynchronous communication. A system that allows a conversation to move between the two seems ideal -- look at how Facebook collapsed the distinction between IMs and "messages". Trying to have a realtime conversation over email (even with a thread-aware, modern client like Gmail) is still an exercise in frustration. The core support for the concept of presence in XMPP is also pretty compelling -- especially in remote collaboration settings, where transparency around another person's comings and goings can significantly reduce conversation friction. That being said, the current XMPP protocol, even including the large set of approved protocol extensions, still falls very short of what would be needed for it to serve as a viable email replacement. As others in this thread have mentioned, the core protocol doesn't include any specification for how to handle messages directed to offline users, and while XEPs have been developed to address this, implementations still vary widely between implementations. Limited by the structure of JIDs, the protocol extension for multi-user chat ends up being a clumsy hack. It looks like there are also problems with large binary data transfer (see http://metajack.im/2008/06/10/binary-data-is-xmpps-achilles-heel/ http://metajack.im/2008/06/10/binary-data-is-xmpps-achilles-...). Obviously, a lot of these problems can be resolved with additional protocol extensions, but this risks creating a hodgepodge of conflicting standards and generating a menagerie of different implementations before drafts are settled on. The fact that the core XMPP RFC makes no allowance for offline messages, which is essentially the core of email, makes me think it might be unwise to try to hot-swap the two.

AndrewDucker 14y ago

What, exactly, do you want to do with it, and how does it replace email? (Genuinely curious - I see suggestions for replacing email on a regular basis, but rarely ones that are deeply thought out.)

fbeeper 14y ago
Sometimes even the topic is what makes the difference (not even location or device) between talking synchronous or asynchronously. I'm not a very assiduous Facebook user, but at some point I've noticed it can blur the edge between sync/async. Maybe it is not perfect (and maybe it is no longer there), but I think its possible to mix both ideas. Neither should be left out.
mortenjorck 14y ago
There are some fairly general reasons, like XMPP being a much newer, extensible (it's in the name!), yet mature messaging protocol with a big community, but there are also some specific ones. One of big potential benefits I see is the XMPP concept of contact requests. Simply separating new senders from existing senders at an architectural level seems like a great start for an email replacement, both in terms of user experience ("who I know" is fundamentally separate from "who I don't know" regardless of the client), and in network utilization (spam is only ever as long as a request header instead of an entire message).
- AceJohnny2 14y ago
  XMPP is focused on real-time, synchronous communication. It does provision for async communication with server storage of offline messages, and even originally discriminated "chat" messages from "email"-type messages with multiple recipients and a subject. IIRC, this latter feature is deprecated as the protocol developers focused on real-time stuff. Because in the end, and despite all its kludges, e-mail doesn't need replacement. Its biggest problem remains spam, and even that is under control by all the major providers.

qznc 14y ago

XMPP is not that clear [0] what happens, if the recipient is offline. I'm not sure, what the popular servers (Google, Facebook, etc) do in practice. As a proof of concept. It should be easy to implement a "shortcut send" into an email client, which sends a mail directly over XMPP, if sender and recipient are both online with this client. [0] http://xmpp.org/extensions/xep-0160.html http://xmpp.org/extensions/xep-0160.html

dscrd 14y ago
I have witnessed somewhat normal network situations (being connected to XMPP server while connecting / disconnecting to a VPN server) that have caused a stable and mature Jabber client (psi) not actually send messages even though it seems that it did successfully send them. For a mature messaging protocol, that smells really really bad for any serious use.

hoverkraft 14y ago

I've thought about this, too. Certainly much communication on the modern internet is realtime, so arguably a protocol based on realtime communication makes more sense than a protocol conceived for asynchronous communication. A system that allows a conversation to move between the two seems ideal -- look at how Facebook collapsed the distinction between IMs and "messages". Trying to have a realtime conversation over email (even with a thread-aware, modern client like Gmail) is still an exercise in frustration. The core support for the concept of presence in XMPP is also pretty compelling -- especially in remote collaboration settings, where transparency around another person's comings and goings can significantly reduce conversation friction. That being said, the current XMPP protocol, even including the large set of approved protocol extensions, still falls very short of what would be needed for it to serve as a viable email replacement. As others in this thread have mentioned, the core protocol doesn't include any specification for how to handle messages directed to offline users, and while XEPs have been developed to address this, implementations still vary widely between implementations. Limited by the structure of JIDs, the protocol extension for multi-user chat ends up being a clumsy hack. It looks like there are also problems with large binary data transfer (see http://metajack.im/2008/06/10/binary-data-is-xmpps-achilles-heel/ http://metajack.im/2008/06/10/binary-data-is-xmpps-achilles-...). Obviously, a lot of these problems can be resolved with additional protocol extensions, but this risks creating a hodgepodge of conflicting standards and generating a menagerie of different implementations before drafts are settled on. The fact that the core XMPP RFC makes no allowance for offline messages, which is essentially the core of email, makes me think it might be unwise to try to hot-swap the two.