[twitter-dev] Re: Thoughts on annotations
Hi, It was a lot of fun and thanks to the Twitter folks for hosting it and giving us api access. Here are a few of my takeaways 1. The hashtag is dead http://bit.ly/ct8orP 2. custom annotation renderers and micro-html tweets are coming to a client near you. 3. hello new world S. Sriram @565labs
[twitter-dev] Re: Thoughts on annotations
About Parking. Closest one near Twitter is Museum Parc Garage. It closes at 11pm on Sat and 6pm on Sun. There are other overnight parking but they charge $25-$32 for 12-24 hrs. Many parking options on 3rd Street between Harrison Folsom Full Day $8-10 on weekend. Some of them are outdoor so I don't think there is issue on building being closed at night. I am very surprise the parking situation near Twitter is better than expected. Next time I would map other parking options so we can share the info better on Tweet feed. Museum Parc Garage 300 3rd St (between Folsom St Saint Francis Pl) San Francisco, CA 94107 Neighborhood: SOMA (415) 284-9553 www.museumparcgarage.com Overnight Hotel Parking: $25.00 per night with In Out Priveleges Hours: Mon-Fri 6 a.m. - 11 p.m. Sat 8 a.m. - 11 p.m. 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
[twitter-dev] Re: Thoughts on annotations
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
[twitter-dev] Re: Thoughts on annotations
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
[twitter-dev] Re: Thoughts on annotations
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/(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
