atebits

Twitter Groups

February 16, 2009

When people talk about Twitter Groups, they are probably talking about one of two completely different things.

Twitter Group Type 1

A way for a bunch of people to “join” a particular group, so that tweets sent to that group get routed to all the members.

Twitter Group Type 2

A client-side way for you to organize the people you follow into “subsets”, so you can classify tweets into different “streams” (for example, I could create a a Twitter development “group” that would just include tweets from only incredibly cool people like @al3x, @chockenberry, @atebits (me!), @tweetie, etc).

A number of people want a client-side grouping (group type 2) feature in Tweetie, and it’s hard to blame them. If you follow a ton of people it’s really easy to get bogged down with information.

(Before I continue, there are existing methods to keep yourself from going into information-overload on Twitter. The first is to stop following people. If someone is clogging up your timeline with a thousand inane updates a day, just stop following them. It really is that simple. They can keep following you, everyone wins. The lack of bi-directional “friendships” is Twitter’s single greatest stroke of brilliance. It also helps to remember that you don’t have to read every tweet).

Anyway, from a technical perspective, there are three ways to implement client side grouping. Here is why they all suck.

Method 1

Implement grouping on top of the Twitter Search APIs. For example, if I wanted to see the tweets of a few people, I could perform a search like “from:tweetie OR from:atebits OR from:gruber“. In fact, you can do this in Tweetie right now and use the saved searches feature to create pseudo-saved-”groups”.

This sucks for three reasons. The first problem is that the query length of a particular search is limited to 140 characters. So depending on the username lengths, you can only have a handful of people in a particular “group”. The second problem is that it flat-out doesn’t work for protected users. Now, I have my own thoughts on protected users (I think it goes against the open spirit of Twitter), but I understand why it exists, and any method that doesn’t work with protected accounts should be considered a hack. The third problem is that the search APIs have had some problems in the past (up until recently, doing a search for “from:tweetie” erroneously returned no results - by the way, Twitter: thanks for fixing that!)

You can get around the first problem by being clever in the client and breaking sets of users into multiple requests and then interleave the results back in the client. But you’d still be making O(n) requests to get the tweet stream for a particular group, so not only does it still exhibit problem 2 and 3, but you’re also dealing with something that doesn’t scale!

Method 2

Get timelines for each user individually, interleave the results client-side. At first glance this solves the problems of living on top of the search APIs, but in reality it sucks even more. Yes, it would fix problems with protected users and any potential search flakiness, but the scaling is even worse than Method 1.

Method 3

Implement groups by filtering your main timeline. In a nutshell, don’t do *any* extra work, just take the tweets already loaded as part of your main timeline and filter out certain ones based on some client-side group settings.

Does this work? Yes, if your Twitter client is running all the time. A desktop client can get away with this because it’s constantly grabbing the freshest stuff from Twitter. There are going to be very few “gaps” in your stream. A mobile client is a whole different story. Most mobile apps are open for brief spurts. When a Twitter client launches, it can only grab a certain number of “fresh” tweets in a single request. If you think about why people want groups, it’s probably because they want to single out a few important people who might not post as often as some others, but are completely drowned out by “noise”. There’s a good chance that there is enough “noise” to push those rare, important tweets way down in your timeline. As a result, they’ll never be seen by the client at all. In this respect, method 1 or 2 is better. If you launch your Twitter client often enough, or you don’t follow any “noisy” people, it might work fine. But “might” is not good enough for me.

Let Me Blow Your Mind

Now, what if I told you that Twitter already has this amazing feature that allows you to create sets of “followers” and could automatically interleave tweets from all these people server-side, so clients didn’t have to make tons of requests. Not only that, but it works with protected users and won’t ever get drowned by “noisy” tweeters.

Twitter does have this feature. It’s available today, for free, and clients don’t need to do any work to support it. Ready? Here it is:

Make another Twitter account.

But wait… um, oh, hrm, wait, no… ah… so you’re saying… wait, yes, that just might work.

This is what the Twitter system was designed to do. It was designed to let you get a stream of updates from some subset of people that you control. Call it a “subset”, call it a “group”, call it whatever you want. Want to add someone to a group? Follow them! Want to remove them from a group? Stop following them! The other secret benefit of this is that these “groups” will “sync” between all of your clients (well, the ones that support the idea of multiple accounts).

Tweetie has a fantastic multiple-account implementation. It takes one tap to see your different accounts. And when you’re replying there’s a button on the compose screen that lets you switch the “sender” account. You can set up a “follow”-only account and when you want to reply to something from it, just tap a switch to send it from your “real” account.

Now, the user-experience isn’t perfect, but it’s perfectly functional. Plus, you can do it today. Even cooler, Twitter doesn’t need to do anything special to support it, and neither does Tweetie. I don’t mean to sound lazy, but less features == less bugs.

(You can argue that Twitter should embrace the concept of “sub-accounts” that enforce the idea of a “follow-only” account/group/thing. I haven’t thought it through, but it might make sense).

Pretty cool, eh?

What About Group Type 1

All of this just-make-another-account stuff got me thinking about Type 1 groups again. I think there’s an opportunity for some clever web guys to come in and solve this problem. They can do it today, it won’t require any work on the part of Twitter or any Twitter client developers (less work for me, right?)

Here’s what I propose. A “group” would simply be another Twitter account. For example, I could make a group called @berkeley_cheese_eaters. I love cheese. I live in Berkeley (for a few more months, at least). I’m sure there are some other people here who love cheese. Now, I made this account, what I would do is register this account with this fancy new “twitter grouper service”. This service would monitor @replies to that account and basically re-post any tweets received on behalf of that account.

If I wanted to send a tweet to a group, it would be as simple as tweeting:


@berkeley_cheese_eaters Man, I love cheese.


The web service would notice this tweet (because it’s monitoring @replies to @berkeley_cheese_eaters), and would repost the text like so:


Man, I love cheese.
- @atebits


Obviously, the tweet would be posted “from” @berkeley_cheese_eaters, so you’d have to put who it was really from somewhere.

If someone else wanted to subscribe to this group, all they have to do is follow @berkeley_cheese_eaters! You can implement “private” groups by protecting updates. Owners of a group can “block” people. Twitter already supports all the necessary functions.

The other benefit of a system like this is that there’s no lock-in. It lives right on top of the Twitter universe, and there’s nothing stopping a bunch of different “grouping” services with different fancy features. As long as they all used this basic mechanism, there wouldn’t be any interoperability issues, and they wouldn’t need any special treatment from Twitter or from client developers.

Someone go build that.

Update: thanks to @richyfrost, who just pointed me at grouptweet.com which looks very slick (and I honestly had no idea even existed). You do have to DM the group (rather than send it a plain @reply), but perhaps that makes more sense?