I was still waking up and recovering from yesterday when I wrote this so forgive the typos, grammar, and mixing up attributes as annotations.
I also wanted to mention that I'm glad that twitter didn't confuse annotations by using the term namespace or providing some kind of mechanism that goes that direction. I originally was wondering about conflicting but this method is better. Namespace gives developers a sense of ownership with the data stored in that annotation type. You can easily still easily namespace your types if you want (possibly in the reverse DNS format used in Java) but you can't prevent other developers from using them and that needs to be conveyed. If you need to strongly store annotation data, you can use signatures, hashes, version markers, or whatever in the annotation that you want to provide that, but it's up to the developer to what they want to fit their needs. Also wanted to playfully rant that parking overnight on the weekend near Twitter HQ sucks, especially when there is a baseball game. The closest garages all close at night on the weekends, so I ended up moving my car 3 times. Next time I'm taking BART and riding my bike. :-) Also 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
