Have you ever read someone’s tweet and not known what they are on about?
At IBM HackDay 5, I played around with an idea for a Twitter hack – a Twitter Glossary that would let users define terms they regularly use in tweets. The idea was that followers would see the definitions appearing as tooltips over those words when they appear in tweets.
I described the idea in more detail here. It’s now available for anyone to try.
The original hack
In the tradition of hackdays, I had a day to knock something together. At work, we have an internal service which lets you deploy a LAMP stack on request – ideal for developers wanting somewhere to try out web apps. I used MySQL to store the definitions, PHP to handle translating terms into definitions, and Greasemonkey to modify the twitter.com homepage, adding definitions as tooltips.
This meant the app was only available on the IBM intranet, but it was enough to show that the idea could work.
After blogging about it at the time, a few people asked if I’d make it available outside of IBM. But I couldn’t afford to pay for hosting it (I only have a single MySQL database where this blog is hosted, and didn’t fancy adding to the wordpress database).
Porting the app to Google App Engine
Fast-forward a year, and I was asked again. The difference now is Google App Engine. This wasn’t an option when I wrote the original hack, but now free hosting for scalable web apps is possible.
So on Friday night, I thought I’d try and port the original hack to run on GAE.
It needed a little work:
- the PHP web service needed porting to Python
- the PHP website where users add their own definitions was ported to Python/Django
- the MySQL database where definitions are stored needed porting to Google’s BigTable
I also compiled my original Greasemonkey script into a stand-alone Firefox extension, so non-Greasemonkey users could give it a try.
It was surprisingly easy – I had it all up and running in an evening, and still found time for quite a bit of Call of Duty 5 🙂
There was one thing that needed changing though…
Security – proving who you are on twitter
The original hack let anyone add definitions for any twitter user. The other nice thing of hosting it within the IBM intranet is that I could trust users a little more. While testers will do what they can to give it a kick, ultimately I didn’t worry too much about malicious users.
Moving the hack to the big bad Internet meant I needed to worry a little more about authentication – in particular, people adding definitions to other twitter users’ glossaries.
The twitter API doesn’t have a nice way of doing this without asking for someone’s twitter password. Given the recent uproar about Twply, that probably wouldn’t have been the best idea. 🙂
I threw together a workaround – when you sign-up the site selects a random word and asks you to tweet that in an @reply to twitglossary. As long as your tweets are unprotected, the site can verify that you really sent the tweet and so you are who you say you are.
By adding “login: required
” to the site’s manifest, I make the Google App Engine platform require users to login with a Google user account. This means I can cache someone’s twitter ID, without needing people to go through the @reply process every time they want to use the site. As users only enter their password on a google.com webpage (which passes the auth token) my code never sees people’s passwords.
It’s live now, so please give it a try.
Install the Twitter Glossary Firefox plugin, then visit http://twitter.com to see twitter with definitions added. (You don’t need to signup or authenticate anything to do this – authentication is only needed to modify a user’s Twitter glossary).
You should also see that the right column has a new “Twitter Glossary” item with a link to a page where you can add your own twitter definitions.
Clicking on this takes you to the Twitter Glossary page where (once you’ve authenticated) you will be able to add definitions for your own tweets.
Tags: twitter
It’d be better if you could authenticate users via DM rather than an @-reply (although I guess the latter helps publicise your app)… 🙂
@Frankie – The problem is that the urlfetch method you get with Google App Engine doesn’t support authenticated HTTP calls… which is why I’m currently limited to unprotected tweets in the public timeline.
If I get a chance, I will have a go at replacing the call to the GAE urlfetch call with some proper urllib code to do an authenticated call to twitter – then I could move to checking @replies or DMs from people who follow @twitglossary.
But like you say, the publicity in the meantime isn’t all bad 🙂