Great update! I don't feel so bad for missing the event now. -Mo @pay4tweet
On May 31, 11:39 am, Zac Bowling <[email protected]> wrote: > 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 ithttp://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
