Unless you live under a rock, you have heard that there were massive DDOS attacks that affected Twitter, Facebook and a few other sites. The sites affected had varying degrees of success in staying functional, but Twitter seemed to be the hardest hit. Given that Twitter was having issues for most of the day, many people migrated to other services like FriendFeed. However, FriendFeed is not an alternative microblogging platform, it is a completely different type of site. So, what can we do if Twitter goes down?
If Twitter goes down, the blogosphere reacts as if the world is ending. It may be a bit much, but Twitter has become a mainstream application. When it goes down, a lot of people know about it. Can we avoid downtime? Probably not, but there are ways to work around this problem. First, Twitter could itself become distributed. Similar to software like email, why not have several Twitter installs around the world that all talk to each other?
A distributed Twitter would require several moving parts. First, there is the problem of data replication. If I am on an east coast US server, how does my tweet get replicated to the other servers around the world? If the servers are all Twitter servers, then they can register with one another in order to pass updates along. Granted, I am not a networking expert, but the Publisher/Subscriber model works for many things, and a distributed server architecture is yet another place this could work.
Another problem is, how do we find a user? Dave Winer has a very good explanation and options where he relates it to the way that DNS works. The idea of a central identity server is interesting, but I feel like that just transfers the single point of failure problem from Twitter to the identity server. Again, we could create distributed identity servers as well to avoid that problem, and it would have to deal with the same data replication problems that I mentioned before.
What if Twitter decides not to distribute itself? Then we are forced to create a federated microblogging architecture. Identi.ca (and its Laconi.ca base) is already implementing this type of solution. The idea is that Laconi.ca instances will all use the OpenMicroBlogging specification. The OpenMicroBlogging specification does not mention federation directly, but it does link to the OAuth Discovery specification which does seem to describe a federated system. Based on a quick scan of all of this documentation, it seems as if Laconi.ca would fit the federated microblogging solution description.
Does anyone see a reason why Laconi.ca is not being touted as the solution to federated microblogging? Obviously, there would need to be some agreement between teams, as nothing moves forward without Twitter itself. Laconi.ca does include Twitter compatible APIs, so it could easily interoperate with Twitter. Does Laconi.ca need a champion or evangelist? I can think of two people that would fit this position perfectly, Robert Scoble and Dave Winer.
Unless someone tells me there is a significant issue with Laconi.ca being a federated microblogging solution, we need to make this a priority. Can we recruit Scoble and Winer to the cause? Is there any reason why not to do this?