Zak,

Thanks for coming along and sharing your thoughts and feedback with
everyone. We're all impressed with what you and other developers came
up with this weekend and for finding those bugs and gotchas. We're
taking that information on board and making the necessary changes to
protect the API and improve the documentation.

For those who are interested in knowing about the other projects
please visit the wiki page [1] for a list of them.

Matt

1. http://wiki.github.com/themattharris/annotations-hackfest/

On May 31, 12:56 pm, "zbowl...@gmail.com" <zbowl...@gmail.com> wrote:
> 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 <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...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