Prologue

First, this is an automated post since I am on vacation, just so you know. 

That said, pardon my "posting three consecutive posts on a topic" thing.  The fact is I wanted to have an automated post so the blog wouldn't go dark for 5 days and this, which was originally part of the last post, got so long that it made sense to give it an entire post of its own. 

End Prologue

(I'm not sure that was actually a prologue since it has nothing to do with the actual post below, but anyway...)

One of the biggest ironies of the whole discussion of "Federated Servers" is that Twitter's nature does not lend itself to Federation.

Ask yourself, what do people like about twitter?  Generally its that they can communicate in real time but using a "broadcasting" model (as opposed to one-to-one like IM).  But one of the most important points there is that the communication has to be in real time.

Federated services such as smtp based e-mail are not in real time.  There are communication problems between servers, network errors, servers going down, and other various incidents that can often times prevent an e-mail from being delivered instantaneously.  As someone who runs an e-mail server I can tell you first hand that it isn't abnormal for an e-mail to be several hours late. 

But if that same thing happened to a Twitter like service it would absolutely ruin it.  The whole point to microblogging is "the timeline" 

Messages coming in at different speeds or coming from different servers who might not be in sync time wise can end up causing a lot of trouble.  You start to get scenarios where, for example, all of someone's tweets for the day aren't delivered to their followers until 11pm when a server problem is fixed.  Then the receiving server has to decide whether all those messages get marked based on the reader's time of receipt or the senders time of post.

In e-mail this is an easy thing because messages are treated as individual entities.  But in a service like twitter where the updates are part of a timeline and not marked as read or unread things can get confusing. 

If you insert stalled messages in at their time of post the reader is likely to miss them because they'll be checking for "tweets" posted after the last time they checked.  If you in turn insert stalled messages into the time line at the time of their receipt you completely kill the linear aspect of the service. 

Ever wonder why all these IM compatibility initiatives have died on the vine?  Its because its next to impossible to create a federated service that works in real time.   It may be possible to federate a Twitter like service but its one heck of a challenge and not one that's going to be solved by Identi.ca's fairly simplistic implementation.