Yet Another Call For A Federated Twitter

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. (and its base) is already implementing this type of solution. The idea is that 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 would fit the federated microblogging solution description.

Does anyone see a reason why 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. does include Twitter compatible APIs, so it could easily interoperate with Twitter. Does 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 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?

26 thoughts on “Yet Another Call For A Federated Twitter

  1. I use exclusively.

    It was kind of strange to watch news of the Twitter DDOS break followed by an influx of people resurrecting/creating accounts, posting and then leaving again.


  2. Andy C,

    I figured that kind of thing would happen. I wish we could solve this problem at some point. It would be really cool if you could login to any federated server and the experience would be no different.


  3. I sort of use friendfeed as a twitter client so it is vaguely distributed for me anyway 😉
    It could probably be used as a microblogging site via IM/web/email but I don’t think SMS is an option


  4. imma,

    FriendFeed is only OK as a real Twitter client though. It would need a few more features to really be comparable to the existing clients. I do not remember if it has an SMS option, but there are mobile interfaces that are fairly good.


  5. This dream of ‘federation’ for Laconica also needs more time. One year on as we have < 20 instances. Most people are too lazy or not skilled enough to maintains, patch and secure their own instance.


  6. *nods*
    I use FriendFeed for other stuff too, so it’s just very convenient that it also does Twitter

    A bit more tricky to set stuff up, I do think it does better at pictures/video/audio & conversation grouping although I realise I’m only comparing the websites as I tend to avoid installs & plug-ins when possible (partly for portability) – presumably some of the twitter clients handle video,etc nicely too


  7. Yes, please turn Twitter into Skynet, since it’s not annoying enough as it is. At least maybe the next time I find myself peer-pressured into reading someone’s cornball “FML” tweets, I might get lucky and be murdered by a robot.


  8. I never meant to turn it into skynet, just something more reliable than it is. If you do not like Twitter, you can ignore it as well.


  9. I am using as my primary microblogging service. Regarding distributed servers Laconica 0.8 is pretty stable and the network subscriptions work really well.

    I would absolutely recommend Laconica for a federated microblogging solution.

    Who needs a more enterprise robust hosted version should check out which is the commercial spinoff from Laconica.


  10. Unfortunately, while you’re talking about all the technical details you’re missing the most important point – popularity.

    Twitter is established and has the audience and it doesn’t matter what system you build, the general public will not understand the difference.

    They will stick to the name brand. They will stick to what is popular and they will stay where the celebrities are.

    When the idea of a distributed twitter is great it would ultimately be like friendfeed, the domain of what are quite frankly the ubergeeks (and yes I’m one)..

    The only way for this vision to really come true is to get twitter to actually change how their platform operates and implement this themselves, otherwise the distributed network will continue to play second fiddle.


  11. FF is only partially effective as a client because it requires the establishment of fake friends to pull Twitter feeds in from people who do not have FF IDs. This reportedly locks down that ID on FF, blocking the Twitter user from adopting that ID on FF once they seek to work themselves away from Twitter. and FF can enable people to increasingly move beyond Twitter through improvements in Twitter-client features and in systems for managing identities across walled gardens and other platforms.

    Some early email systems only allowed people to send emails to recipients within the same system, such as AOL and CompuServe. Now those walls have come down, at least in the email sphere.

    I’ve been criticized for this (for good reason) but I believe until the identity aspects of and microblogging are re-examined, then we are not going to be in a good position from a usability perspective to push outgoing messages/microblog posts to the correct addresses on other platforms/networks nor are we going to be able to escape from having Twitter/Facebook serve as the default identity providers for social media clients.


  12. Markus,

    The problem with adoption of is what Paul stated, Twitter’s popularity.


    My first option above was for Twitter to become truly distributed, so that losing one server or location is not as big of a deal. I agree that they already have name recognition, and I was using as an example of what could be done.


  13. Anthony,

    The identity problem probably needs to be dealt with outside of Twitter. People already have an identity with their email address, but we have moved away from those as identifying information. OAuth is not the answer as it is purely about authorization meaning permission, not authentication like Facebook Connect or Google FriendConnect.


Comments are closed.