20080706 – 135448+0000
I acknowledge that nothing here is new, but I’ve tried to go from first principles. IIRC, Ralph Meijer has already had some of this stuff working.
Okay… Instead of users being referred to by a profile URI, which seems a bit sucky to me, let’s start off by assuming there’s only one microblogging site per domain. I think that’s a reasonable restriction.
This allows you to refer to a particular user globally by a tuple consisting of a username and a domain. Are we good so far?
As far as I can tell, existing microblogging sites don’t allow an @ sign in their usernames, so this allows us to have a string representation for any user, globally, of:
user@domain
Wowee, groundbreaking.
So assuming that’s all okay so far, we need a protocol to carry data from one domain to another. Given that we want to avoid polling, we’d be best off with a continuous stream orientated protocol, rather than a request/response one. A TCP based protocol seems sensible, since presumably neither end is going to be behind a heavily restricted NAT, and so communications are going to be reasonably free.
The protocol probably needs to be extensible, which suggests to me that we want to be looking for an XML based protocol. And that rather suggests that XMPP or BEEP is a solution here. BEEP is actually lighter - as long as we strip out the over-engineered stream bits we don’t want - but there are many fewer libraries, and besides, most of these sites have an XMPP interface anyway.
So, this suggests that each microblogging update is carried in a single stanza, and that the “subscriptions” are effectively treated as a roster subscription.
So far, we have XMPP, with some kind of message (we’ve not yet decided what) whizzing between servers.
Next, let’s consider what existing facilities are present in XMPP which might do this job.
The obvious one is PEP. In PEP, each user has a number of nodes, which are individually addressable, and can effective act as broadcast demultiplexers - the user emits a message - an XML gobbet - “aimed at” the node, and the node emits a message to each subscriber.
It’s simple, and almost exactly what we want, so if nobody objects we’ll go with this.
And there we have an almost complete OpenMicroblogging specification.
The missing bits are:
- discovering metadata about the user, which can probably be done with s to the user, or possibly XEP-0154 attributes.
- the precise formatting of the microblogging updates.
- an optimization for reducing server-server traffic loads.
The latter can be done by, in the case where the microblogging update is open and public (ie, has a predictable and largely uncontrolled access model), then we may as well send updates conceptually between servers, such that multiple users on remote servers “share” a single update message.
The easy way to do this is for the remote server to indicate that the subscription is being proxied.
The thing I wonder about, though, is why one would bother have microblogging at all, in this circumstance - what I’ve outlined above is, after all, essentially a simple PEP service that could be put into place today with many servers, and would take minimal client development. That would mean, though, that microblogging sites would essentially act as an interface onto the XMPP service, which is an odd state of affairs, but I think overall I prefer it.
Pointless Keyword Of The Day: Rick Moranis.
Posted in XMPP | 4 Comments »