This weekend's hackfest was at Twitter HQ was fun. About a couple dozen of us 
stayed awake for about 30 hours and still had enough to energy to present. Some 
pretty amazing things created and we helped identified a bunch of bugs. 

Now that I've had a chance to go home and catch up on some sleep, here is a 
brain dump of my thoughts.

* One of the documented recommended types is place/location, but this data is 
similar to what we store in the geo fields. I'm not sure what issues we may run 
into privacy using it rather then storing the Geo fields (users can 
enable/disable geo and remove geo data from all previous status updates). 

* We will always have twitter clients that will not understand or look even 
look at our attributes. This means that we can't can't have annotations that 
change the meaning of a tweet or make the meaning of the tweet useless. This is 
basically graceful degradation, and not progressive enhancement. We joked that 
want to see tweets that say: "This tweet can only be read in clients that 
support X annotations. Please upgrade your twitter client or try X client.". 

* You have to treat annotations as potentially hostile attack vectors.  As was 
proved with some awesome cornfied and flashing unicorn injections this weekend, 
any raw data can be store in annotations. Just because you stored it there, 
anyone can do store any raw data and anyone can post tweets that copy your 
annotation format. Twitter may sanitize javascript injections, but it doesn't 
stop other types of injections from occurring if you don't check. It's 
extremely important to validate, html encode, or whatever you need to with the 
data stored in the annotations.

As I did with my twitter remote shell execution example, I added my own 
signature and noance of my own into the twitter annotation to validate the 
sender had my secret. It may be one solution. 

* Attributes work at the time of creation because status updates are immutable. 
This may be obvious to most, but its a limitation that hits you a few times as 
you develop. Because of that we need to make sure that we can get most of the 
clients, including Twitter.com, support the most popular annotation formats. We 
can't fix update status updates after the fact so we have to get it right.  
(Adding annotations to new style retweets is in theory possible)

* Can't remind people enough to switch from twitter.com to api.twitter.com.  A 
bunch of little differences between the two that give you headaches. Our "board 
of wasted time" at the hackfest summed it up pretty well. 

* A good number of us spent a good deal of time on just getting past OAuth this 
weekend. We had a lot of people that understood the OAuth spec fairly well 
thankfully and @jmhodges was there to help (although not his area he deals with 
in the code). Since you update twitter with POST, it's optional to store the 
authentication data in the postdata instead of the authentication header 
according to the spec, and some our libraries were doing just that, but twitter 
only works with the Authentication header. We didn't know but this was 
documented on the Wiki and had to learned from trial and error. A bunch of us 
got caught up on using twitter.com instead of api.twitter.com. I think we all 
worked through it at about midnight late saturday. 

In the end it was pretty awesome. I want to thank @jonashuckestein for the the 
bookmarklet. It was awesome and saved us all time. 

http://jonashuckestein.github.com/Twitter.com-Annotations-Bookmarklet/ (see my 
stream with it http://twitpic.com/1st8sd )

I won't cover the bugs. I'll leave twitter to document those if and when they 
open up annotations to more developers. 

Thanks all!

Zac Bowling
@zbowling


Reply via email to