Chances are you’re reading this on the stunning redesign of atebits.com. Thanks to Tim Van Damme of Made by Elephant for his brilliant work.
This redesign is in celebration of the imminent release of a new app, Tweetie for Mac. In many ways it is the bigger cousin of the iPhone version (hence the codename: “Bigbird”). Tweetie for Mac is more than a port – in fact, it’s a complete rewrite. The new core is faster, more stable, and more extensible than its predecessor. Not only will it form the foundation of the Mac version, but also the foundation of the next generation of Tweetie 2.0 for iPhone.
I will posting more details, screenshots, and maybe even some screencasts of Tweetie for Mac later this week. Be sure to follow @atebits and @tweetie for up-to-the-minute info on the imminent release.
So you finished your amazing new iPhone app, it scrolls like butter, now you need to show the world. You could make a screencast by clicking around in the iPhone Simulator, but that has a tendency to look like you just clicked around in the iPhone Simulator.
I’m starting to put together some screencasts for Tweetie, and a number of developers asked how I made them look so awesome. Today I’m happy to share. The trick is a little app I wrote called SimFinger. It’s not a screencapture tool, rather it’s a bundle of little tricks to make a screencapture of the iPhone Simulator suck less.
SimFinger
First, download a copy of SimFinger. If you launch it, you’ll end up with something that looks like the shot below. SimFinger itself is composed of two parts. One is a fake “frame” that sits ontop of the simulator. It adds some shine and gives it an iPhone 3G-look. Clicking anywhere on it will just click-through to whatever is below. The other part is a little nub that follows around your cursor. It “indents” when you press down with your mouse, indicating what would be a “touch” on the phone.
I’m astonished that many people don’t know this. Say @atebits wanted to send a tweet to a bunch of users, he might try something like this:
@user1 @user2 @user3 let's all go to a party.
Looks good, right?
Wrong.
First, some background on how replies in Twitter work (as of Feb 2, 2009 – they are updating all the time).
Twitter provides two ways to reply to someone. The first is to simply prefix a username at the start of a tweet. So for example, @user1 could type in: “@atebits man, I would *love* to go to a party with you.“, and @atebits would see it as a reply to him. Awesome.
The other way to reply is to reply to a specific tweet. You can do this on twitter.com by clicking the little gray reply arrow next to a tweet. You can also do it in a client (that support it) by clicking the reply button when viewing a specific tweet. This does two things, first: it automatically prefixes a “@username” at the beginning of the tweet. Second: it sets the in_reply_to_status_id flag when posting to Twitter.
This last point is particularly cool – it’s a way for you to reply to a specific tweet. When people view this tweet on twitter.com, there will be a small link at the end of the tweet that says something like “in reply to atebits“. When you click it, it will take you to the specific tweet that user was replying to. In a client that supports following reply chains (like Tweetie), you can tap a button to see the tweet that someone was replying to.
Now, back to the original point. You wanted to invite @user1, @user2 and @user3 to a party. But @user1 was the only person to get back to you. You could conclude that @user2 and @user3 think you smell and would never go to a party with you, or you could learn a little more about how Twitter replies work.
The truth is, @user1 is the only one who saw that message in their Replies. @user2 and @user3 didn’t see it in their Replies at all. This is because Twitter only considers the first username as the person you’d like to reply to… it has no concept of multiple replies.
Today, if you want to send a reply to three people, you have to send three separate tweets.
I agree that it would be nice if you could include a few different @usernames in a tweet, and every username mentioned in it would get it as a reply. But that’s not how it works today, so you should keep it in mind. If you want it to change, well, I’m the wrong person to talk to – you could ask Twitter here and see what happens.
As a side note: this is one of the reasons why Tweetie doesn’t include a Twitter “friend address book” in the Compose screen. A lot of people have requested it so they can reply to multiple people… to them I say: please read this blog post. There is a second reason why Tweetie doesn’t have that feature, but it’s more technical and probably deserves another blog post (short version: it would be a hack, and if you see it in any other Twitter client today, I can pretty much guarantee that it’s a half-assed implementation).
Update: If you find yourself wanting to send a tweet to multiple users often, you might want to read Twitter Groups (Type 1) and check out http://www.grouptweet.com/, a very cool looking service.
The current authentication process for Twitter clients is straightforward:
Launch a Twitter client
Enter your username and password
That’s it
If Basic Authentication goes away, and OAuth is the only option, the process would look like this:
Launch a Twitter client
Client does some magic, then quits and sends you to a special login page on twitter.com
You login on twitter.com
You “approve” the client that just sent you to the browser
Your browser quits, you get punted back to the client (where it then does some more magic to actually log you in)
That’s it
OAuth will make you – the user – jump through these hoops so you don’t have to type your password into the client application directly, for your own security.
Time to be frank: any security that OAuth claims – with respect to native applications – is an illusion. If a native app wants to get a copy of your password, it will get a copy of your password. If it wants to hijack the authentication process, bring up a bogus “browser” for you to enter a password into, register keyloggers, muck with your system web proxy settings and sniff passwords before they hit the wire, or phish you some other way, guess what: it can and it will. OAuth does not solve these problems. It just adds complexity to the login process.
But this post is not meant to bash OAuth – I think it’s a fantastic solution to authenticate other web apps. The problem is that it flat-out sucks for everything else.
So why is there a push to standardize on this single authentication system? Why shouldn’t Twitter implement OAuth and keep Basic Auth around? Well, I think they should, but I can imagine a number of reasons why they don’t want to: buzzword compliance, implementation simplicity, the ability to remotely disable access tokens from misbehaving clients (which is a legitimately nice feature).
I think Basic Auth is fine (over SSL at least). But OAuth is the juggernaut of this new age of web stuff, here I am, holding back the tide of buzzword bullshit and I know I’m going to lose. And to be honest, a few years from now when OAuth is finally integrated sensibly, I think it actually will be quite nice.
“Integrated sensibly” is key. Today is an opportunity to get it right.
Fixing OAuth
I have a tendency to think of things that have already been thought of, so I apologize if this has already been discussed and rejected. I also have a tendency not to think things entirely through, though I’m hoping this post is a starting point, not a complete solution. In any event, I think there may be a way to fix OAuth and you’d only have to change 4 words of the spec.
The OAuth Core 1.0 spec hard codes the concept of a web browser as the means to authenticate with a provider. I would like to generalize that and introduce a new term, call it an authentication gateway for now.
An “authentication gateway” is any program that is capable of communicating securely between a device that is currently running a consumer and a service provider. A web browser is a perfectly acceptable type of authentication gateway. The idea is to allow for a few new types.
I think the ultimate goal is to have a single, global, native-looking, “blessed” authentication gateway on every device. This gateway could be expressed on different devices in different ways. On the iPhone for example, it could be represented as a special OS-provided window (running in a protected process) that slid up over an app, allowing the user to enter a password (or authenticate via something else like OpenID). The sheet would then slide back down revealing the app after authentication was complete. The requesting app would never need to quit. There would be no need for any web pages, and the authentication experience would be completely standardized across every app on that device that used OAuth.
On the Mac, the authentication gateway could be expressed much like the current keychain dialog today.
One added bonus of implementing OS-level “blessed” authentication gateways is that the OS vendor can use every trick in the book to prevent phishing. They can use secret APIs to make sure key strokes aren’t logged and proxy settings haven’t been compromised. They can also implement a system allowing users to validate the authenticity of the authentication gateway itself. For example, it would be trivial for a malicious application to bring up a window that looks and works exactly like the OS-provided gateway, but stole the user’s password. An OS vendor could prevent this by doing a “choose a special image when setting up your device, and check to make sure the image matches when you see an authentication window come up” (or ideally a something a little less cheesy). A number of financial sites use this trick. The benefit is that each provider wouldn’t have to come up with their own implementation of it (forcing the user to remember a different image on each site). The user would only have to remember one image, to check validity of their single, system gateway.
The other added bonus is that there is no reason why authentication gateways need to be limited to GUIs. A command-line gateway would be possible. So would some other gateway for an interface (or a device that doesn’t have an interface) that nobody has even thought of yet.
Chicken / Egg
There’s a bit of a problem here, and that is how to do this seamlessly and securely without explicit support from OS vendors. In a nutshell, we can’t. What we can do is build it, prove it works, then beg for support.
We can build this today. It won’t be perfectly secure, but it will be at least as secure as Basic Auth (in the sense that clients would still be able to see user passwords). That’s good enough for me, and that’s good enough for everyone who uses an email client today. It would be easy enough require other web apps to use the “web browser”-type authentication gateway, so security would stay exactly the same in that regard.
The only reasonable way to accomplish this today is to have each native app carry along their own implementation of an authentication gateway. On something like the iPhone, it would be unreasonable to require users to download a separate “authentication gateway” app to authenticate something else. On the desktop, you could certainly have apps that could install some shared gateway, but that could be easily abused by malicious apps, so it’s probably better for now for each app to carry their own.
There’s nothing stopping apps from sharing code, I’d be happy to contribute to an open source implementation of something like this. Again, this post was simply an attempt to get some discussion going. If you have your own thoughts, I encourage you to join in the discussion here and contribute to the OAuth Desktop Discussion Wiki.
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?
