Twitter, Without all the Suck (continued)

Twitter "fail whale" graphicYesterday, I started a discussion of things I don't like about Twitter. I pointed out that lack of message prioritization in the client was a problem. I also noted that since Twitter has an API, that should be easy to fix, and I wouldn't be surprised if somebody already has.

The problem I want to talk about today is tougher to fix, and the fix basically entails throwing it away and starting over.

The term "microblogging" has been invented to describe what Twitter does. I strenuously object to that name. That which makes blogging so excellent and so important is exactly what's lacking in Twitter.

Blogging is a decentralized, user-hosted service. Anybody can host a blog—or designate a service to host it for them. Anybody can access and read blogs using a standard protocol suite. It's an open, distributed environment.

Twitter doesn't do that. It's centralized. So let's stop calling it "microblogging". Let's call it something else, such as a "status posting application".

This isn't just some prissy argument about names. It gets to the fundamental flaws of Twitter. The biggest and most obvious of which is its lack of reliability. Twitter crashes a lot. A whole lot. So much that an entire cult has emerged around its lack of reliability.

Blogging doesn't fail. Sure, some particular blog may go offline for some amount of time, maybe frequently so, but that doesn't crash all the other blogs you read.

Microblogging, if done right, could be like that too.

The first step is to define a protocol suite, just as we have for blogging. There are two key functions to microblogging: publishing (the content of the tweets) and notification (that a new tweet has been posted). These could be implemented with standard protocols. Publishing can be done with ATOM, the successor to RSS, an open protocol use for blog syndication. Notification can be done with XMPP, an open protocol used for messaging (Google Talk uses it).

Next, build and distribute an open source reference implementation for microblogging publishing and reading. I'd expect publishing could be implemented as an add-on module to an existing blog system. Reading may be a combination of an XMPP receiver for asynchronous update notification and an ATOM/RSS reader for historical content.

The final step is to add multi-protocol support to these tools, to provide legacy support to hosted services such as Twitter and identi.ca. That allows people to move to the open microblogging environment at their convenience, without losing connection with those staying behind on hosted services.

I think that's what a microblogging platform should look like. It's constructed on an open source platform, so it's ideal for extension and innovation. It's distributed and robust, so it doesn't need a cute failure mascot. It would provide the capability of Twitter, without all the suck.

Comments

Comments have been closed for this entry.

tweetdeck

You were discussing the idea of grouping followers.. Tweetdeck, an Adobe Air application has a handle on that: http://bit.ly/ILZwj

I agree though. There are tweeters I'm more interested in than others.

Filtering, continued

Now that I think of it, I'd really like to be able to selectively filter my own tweets. Some I'd like to keep to close friends, and some completely public. Not an option, but it would be a great one.

Access Control

Jenn, I didn't mention it for fear of getting too bogged down in details, but if I were to reinvent microblogging I'd probably include some notion of authentication and access control. That way you could designate some tweets for public access, other tweets for varying levels of private access.