I have updated this draft and released some code.

Regular readers of my blog know that I am obsessed with one thing: decentralisation. I hate having all my eggs in one basket. IMHO, if anyone has the ultimate power, then it’s not true Web 2.0. In my recent thinking this has extended to my view of social networks such as Facebook and MySpace.

One of the much-used features of these is personal messages. This can be public (ala Facebook wall) or private (ala Facebook message). I here intend to provide a TEP, which I will implement, suggesting a way to do this in a decentralised and RESTful manner.

Detecting the endpoint

I love XRDS! This format comes to us from the OpenID world but really provides a standard way to associate RESTful endpoints with a URL [example].

I think it makes most sense to have one type URL for this TEP and declare a namespace for extending XRDS to (optionally) tag endpoints with a ‘sub-type’. This could look like the following:

<?xml version="1.0" encoding="UTF-8"?><xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)" xmlns:dsn="http://singpolyma.net/dsn/xmlns">

<XRD>

<Service priority="50">

<Type>http://singpolyma.net/dsn/pmt

<URI>http://example.com/msg

<dsn:msgtype>private</dsn:msgtype>

</Service>

</XRD>

</xrds:XRDS>

(I will create these pages in a bit.) I would propose the following dsn:msgtype for now: private (only to you) and public (like Facebook wall). As this is a TEP, nothing is remotely final. I’m not sure I like msgtype as the tag name, for one thing.

Sending Data to the Endpoint

This part is easy. To support maximum compatibility with existing systems, either GET or POST data is to be accepted. All fields passed must be processed. The simplest system will simply take all data passed via both GET and POST and put the field name as a header and the value under/beside it in the message body. No data may be ignored (unless there is a particular value, such as a session ID, specific to your server which you want removed). The following is a list of fields which make sense to use in a special way. If you are going to do something special for one of these values you should use the name given here, but really any data can have anything done with it as long as it is included somewhere in the message.

subject, from (contact of sending user), cc, url (of sending user), name (of sending user), body

XHTML is allowed. Special data (such as calendar events) should be marked up with microformats where possible.

A way to contact the user back SHOULD be supplied. If either from or url is a URL, XRDS discovery can be performed on it in order to detect an endpoint for this TEP to use in replying.

I am going to write some code to implement this both for WordPress and independently soon. I may also create a simple service targeted at adding this capability to a blogger blog (or other locked-hosting website).

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:

1. Write a client that supports both XMPP and SMTP (through POP3 or IMAP) and have an identical address on both networks (think @gmail.com).
2. Modify (/write) an SMTP-based mail server to support XMPP.
3. 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.