Great update!  I don't feel so bad for missing the event now.

-Mo
@pay4tweet


On May 31, 11:39 am, Zac Bowling <zbowl...@gmail.com> 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

Reply via email to