Re: [twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta
I made a minor change to see if it will flush the cache. The policy is, as of 9/1/2010: During the beta testing period, sites are encouraged to first pull and cross-check test data from both Site Streams and the REST API to develop confidence in correctness and robustness. Once a Site Streams client implementation is deemed sufficiently stable, the streaming data could, depending on your risk-tolerance, become the primary production data source. Once this feature graduates to production, Site Streams applications must only use the REST API for data that is not available through Site Streams or use the REST API as a fall-back data source. Disruptions during the beta period should be expected and masked by this fall-back. On Wed, Sep 1, 2010 at 3:21 PM, Dewald Pretorius dpr...@gmail.com wrote: John, That page still says exactly the same. On Aug 30, 5:24 pm, John Kalucki j...@twitter.com wrote: It's cached. It'll update via a process that is mysterious to me. On Mon, Aug 30, 2010 at 1:21 PM, Dewald Pretorius dpr...@gmail.com wrote: John, Is that page cached, because the third sentence of the first bullet under Important Items still says *exactly* the same? On Aug 30, 5:15 pm, John Kalucki j...@twitter.com wrote: Thanks. I've clarified the language. -John On Mon, Aug 30, 2010 at 12:42 PM, Dewald Pretorius dpr...@gmail.com wrote: John, Perhaps you should then rephrase the following at http://bit.ly/sitestream_doc One Site Streams graduates to production, sites must only use the REST API for data that is not available through User Streams or as a fall-back data source. It's in the first paragraph of Important Items. Here's another issue that probably needs to be considered. It applies mostly to DMs, because people will tend to use DMs for sensitive information, and would expect a certain level of privacy. Right now, an OAuth authorized site can query a user's DMs and do with that info what it likes. It could present privacy issues, but at least you have an audit trail of the DM request by the authorized site in your logs/system. You lose that audit trail with Site Streams. The DMs are indiscriminately distributed out to all OAuth authorized sites that subscribe to the user's stream. It may not seem like a big deal, because it's status quo minus the audit trail. Until you're hit with a multi-million dollar class-action lawsuit for indiscriminately distributing potentially sensitive information. Then it is a big deal. It's not only the lawsuit, it's a privacy PR disaster as well. On Aug 30, 4:25 pm, John Kalucki j...@twitter.com wrote: We're not forcing people over to Site Streams. If, on the other hand, if you start to consume Site Streams, we want you to stop regular polling on the REST API. If your service is modest, any excess delivery will be modest. Excessive options add complexity and slow development for what may be little practical efficiency gain. Bandwidth and CPU are nearly free at 1mbit/sec. It's all a balance. -John Kaluckihttp://twitter.com/jkalucki Twitter, Inc. On Mon, Aug 30, 2010 at 12:15 PM, Dewald Pretorius dpr...@gmail.com wrote: This is super news. However, if you're going to force web services to use Site Streams when it is in production (sites must only use the REST API for data that is not available through User Streams), then please add the ability to subscribe only to certain elements. For example, we need the ability to subscribe to only Follows, or to only Tweets and Retweets, etc. You make note that each stream may consume significant bandwidth ( 1MB). If a web service does not make use of the user's Follows, or of the user's Tweets, then it makes no sense to consume that bandwidth with the dead-weight of the elements that are not used by the service. I understand that Site Streams is in beta now. I'm putting in this request for when it is in production and we are forced to use it. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta
My initial thought was that this was for applications like TweetDeck where users have multiple accounts, but the docs say that Desktop clients should keep using the normal User Streams. Will there be an update for the User Streams to support having multiple accounts, are the docs wrong, or do you really want us to open (in some cases) 10 connections? Tom On 8/30/10 8:57 PM, Jesse Stay wrote: Freakin' awesome. Nice job guys! Jesse On Mon, Aug 30, 2010 at 12:52 PM, Mark McBride mmcbr...@twitter.com mailto:mmcbr...@twitter.com wrote: Site Streams, a new feature on the Streaming API, is now available for beta testing. Site Streams allows services, such as web sites or mobile push services, to receive real-time updates for a large number of users without any of the hassles of managing REST API rate limits. The initial version delivers events created by, or directed to, users that have shared their OAuth token with your application. Via Site Streams, the following events are streamed immediately and without rate limits: Direct Messages, Mentions, Follows, Favorites, Tweets, Retweets, Profile changes, and List changes. A subsequent version is planned that will optionally deliver each user's home timeline. For additional information on Site Streams and details on how to apply for access, see the Site Streams Beta documentation at http://bit.ly/sitestreams_doc. ---Mark http://twitter.com/mccv -- Twitter API documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Change your membership to this group: http://groups.google.com/group/twitter-api-announce?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta
Desktop clients that support multiple accounts should continue to open multiple connections on User Streams. -John Kalucki http://twitter.com/jkalucki Twitter, Inc. On Mon, Aug 30, 2010 at 12:00 PM, Tom van der Woerdt i...@tvdw.eu wrote: My initial thought was that this was for applications like TweetDeck where users have multiple accounts, but the docs say that Desktop clients should keep using the normal User Streams. Will there be an update for the User Streams to support having multiple accounts, are the docs wrong, or do you really want us to open (in some cases) 10 connections? Tom On 8/30/10 8:57 PM, Jesse Stay wrote: Freakin' awesome. Nice job guys! Jesse On Mon, Aug 30, 2010 at 12:52 PM, Mark McBride mmcbr...@twitter.com mailto:mmcbr...@twitter.com wrote: Site Streams, a new feature on the Streaming API, is now available for beta testing. Site Streams allows services, such as web sites or mobile push services, to receive real-time updates for a large number of users without any of the hassles of managing REST API rate limits. The initial version delivers events created by, or directed to, users that have shared their OAuth token with your application. Via Site Streams, the following events are streamed immediately and without rate limits: Direct Messages, Mentions, Follows, Favorites, Tweets, Retweets, Profile changes, and List changes. A subsequent version is planned that will optionally deliver each user's home timeline. For additional information on Site Streams and details on how to apply for access, see the Site Streams Beta documentation at http://bit.ly/sitestreams_doc. ---Mark http://twitter.com/mccv -- Twitter API documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Change your membership to this group: http://groups.google.com/group/twitter-api-announce?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta
We're not forcing people over to Site Streams. If, on the other hand, if you start to consume Site Streams, we want you to stop regular polling on the REST API. If your service is modest, any excess delivery will be modest. Excessive options add complexity and slow development for what may be little practical efficiency gain. Bandwidth and CPU are nearly free at 1mbit/sec. It's all a balance. -John Kalucki http://twitter.com/jkalucki Twitter, Inc. On Mon, Aug 30, 2010 at 12:15 PM, Dewald Pretorius dpr...@gmail.com wrote: This is super news. However, if you're going to force web services to use Site Streams when it is in production (sites must only use the REST API for data that is not available through User Streams), then please add the ability to subscribe only to certain elements. For example, we need the ability to subscribe to only Follows, or to only Tweets and Retweets, etc. You make note that each stream may consume significant bandwidth ( 1MB). If a web service does not make use of the user's Follows, or of the user's Tweets, then it makes no sense to consume that bandwidth with the dead-weight of the elements that are not used by the service. I understand that Site Streams is in beta now. I'm putting in this request for when it is in production and we are forced to use it. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta
Quoting Dewald Pretorius dpr...@gmail.com: Here's another issue that probably needs to be considered. It applies mostly to DMs, because people will tend to use DMs for sensitive information, and would expect a certain level of privacy. Right now, an OAuth authorized site can query a user's DMs and do with that info what it likes. It could present privacy issues, but at least you have an audit trail of the DM request by the authorized site in your logs/system. You lose that audit trail with Site Streams. The DMs are indiscriminately distributed out to all OAuth authorized sites that subscribe to the user's stream. It may not seem like a big deal, because it's status quo minus the audit trail. Until you're hit with a multi-million dollar class-action lawsuit for indiscriminately distributing potentially sensitive information. Then it is a big deal. It's not only the lawsuit, it's a privacy PR disaster as well. Ayup - *Twitter* loses an audit trail - they can track sends / TCP acknowledgements but have no idea what the receiver is doing with the packets. The consuming site must maintain an audit trail, though, right? Something like this happened at Facebook when they changed their developer TOS. Here's the wording they used: ?You must give users control over their data by posting a privacy policy that explains what data you collect, and how you will use, store, and/or transfer their data. You may cache data you receive from the Facebook API in order to improve your application?s user experience, but you should try to keep the data up to date. You will delete all data you receive from us concerning a user if the user asks you to do so, and will provide a mechanism for users to make such a request.? I'm assuming Twitter will want to do something similar, and I'd think it would also include honoring the delete messages that come down the streams. That could be *very* interesting if the service was doing indexing. ;-) -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta
Thanks. I've clarified the language. -John On Mon, Aug 30, 2010 at 12:42 PM, Dewald Pretorius dpr...@gmail.com wrote: John, Perhaps you should then rephrase the following at http://bit.ly/sitestream_doc One Site Streams graduates to production, sites must only use the REST API for data that is not available through User Streams or as a fall-back data source. It's in the first paragraph of Important Items. Here's another issue that probably needs to be considered. It applies mostly to DMs, because people will tend to use DMs for sensitive information, and would expect a certain level of privacy. Right now, an OAuth authorized site can query a user's DMs and do with that info what it likes. It could present privacy issues, but at least you have an audit trail of the DM request by the authorized site in your logs/system. You lose that audit trail with Site Streams. The DMs are indiscriminately distributed out to all OAuth authorized sites that subscribe to the user's stream. It may not seem like a big deal, because it's status quo minus the audit trail. Until you're hit with a multi-million dollar class-action lawsuit for indiscriminately distributing potentially sensitive information. Then it is a big deal. It's not only the lawsuit, it's a privacy PR disaster as well. On Aug 30, 4:25 pm, John Kalucki j...@twitter.com wrote: We're not forcing people over to Site Streams. If, on the other hand, if you start to consume Site Streams, we want you to stop regular polling on the REST API. If your service is modest, any excess delivery will be modest. Excessive options add complexity and slow development for what may be little practical efficiency gain. Bandwidth and CPU are nearly free at 1mbit/sec. It's all a balance. -John Kaluckihttp://twitter.com/jkalucki Twitter, Inc. On Mon, Aug 30, 2010 at 12:15 PM, Dewald Pretorius dpr...@gmail.com wrote: This is super news. However, if you're going to force web services to use Site Streams when it is in production (sites must only use the REST API for data that is not available through User Streams), then please add the ability to subscribe only to certain elements. For example, we need the ability to subscribe to only Follows, or to only Tweets and Retweets, etc. You make note that each stream may consume significant bandwidth ( 1MB). If a web service does not make use of the user's Follows, or of the user's Tweets, then it makes no sense to consume that bandwidth with the dead-weight of the elements that are not used by the service. I understand that Site Streams is in beta now. I'm putting in this request for when it is in production and we are forced to use it. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta
It's cached. It'll update via a process that is mysterious to me. On Mon, Aug 30, 2010 at 1:21 PM, Dewald Pretorius dpr...@gmail.com wrote: John, Is that page cached, because the third sentence of the first bullet under Important Items still says *exactly* the same? On Aug 30, 5:15 pm, John Kalucki j...@twitter.com wrote: Thanks. I've clarified the language. -John On Mon, Aug 30, 2010 at 12:42 PM, Dewald Pretorius dpr...@gmail.com wrote: John, Perhaps you should then rephrase the following at http://bit.ly/sitestream_doc One Site Streams graduates to production, sites must only use the REST API for data that is not available through User Streams or as a fall-back data source. It's in the first paragraph of Important Items. Here's another issue that probably needs to be considered. It applies mostly to DMs, because people will tend to use DMs for sensitive information, and would expect a certain level of privacy. Right now, an OAuth authorized site can query a user's DMs and do with that info what it likes. It could present privacy issues, but at least you have an audit trail of the DM request by the authorized site in your logs/system. You lose that audit trail with Site Streams. The DMs are indiscriminately distributed out to all OAuth authorized sites that subscribe to the user's stream. It may not seem like a big deal, because it's status quo minus the audit trail. Until you're hit with a multi-million dollar class-action lawsuit for indiscriminately distributing potentially sensitive information. Then it is a big deal. It's not only the lawsuit, it's a privacy PR disaster as well. On Aug 30, 4:25 pm, John Kalucki j...@twitter.com wrote: We're not forcing people over to Site Streams. If, on the other hand, if you start to consume Site Streams, we want you to stop regular polling on the REST API. If your service is modest, any excess delivery will be modest. Excessive options add complexity and slow development for what may be little practical efficiency gain. Bandwidth and CPU are nearly free at 1mbit/sec. It's all a balance. -John Kaluckihttp://twitter.com/jkalucki Twitter, Inc. On Mon, Aug 30, 2010 at 12:15 PM, Dewald Pretorius dpr...@gmail.com wrote: This is super news. However, if you're going to force web services to use Site Streams when it is in production (sites must only use the REST API for data that is not available through User Streams), then please add the ability to subscribe only to certain elements. For example, we need the ability to subscribe to only Follows, or to only Tweets and Retweets, etc. You make note that each stream may consume significant bandwidth ( 1MB). If a web service does not make use of the user's Follows, or of the user's Tweets, then it makes no sense to consume that bandwidth with the dead-weight of the elements that are not used by the service. I understand that Site Streams is in beta now. I'm putting in this request for when it is in production and we are forced to use it. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta
Try getting access to Site Streams without a signed agreement between your organization and Twitter prohibiting such shenanigans. ;-) -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos Quoting Dewald Pretorius dpr...@gmail.com: Ed, Developer responsibilities and developer agreements mean absolutely nothing to that person who wants to abuse users' DMs. In fact, they will probably trick users to authorize their app with a neat feature, and then in the background collect received and sent DMs. Twitter will not have the foggiest idea of which service it could be, because they will have no record of API requests, or pattern of requests, for received and sent DMs. On Aug 30, 5:15 pm, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: Quoting Dewald Pretorius dpr...@gmail.com: Here's another issue that probably needs to be considered. It applies mostly to DMs, because people will tend to use DMs for sensitive information, and would expect a certain level of privacy. Right now, an OAuth authorized site can query a user's DMs and do with that info what it likes. It could present privacy issues, but at least you have an audit trail of the DM request by the authorized site in your logs/system. You lose that audit trail with Site Streams. The DMs are indiscriminately distributed out to all OAuth authorized sites that subscribe to the user's stream. It may not seem like a big deal, because it's status quo minus the audit trail. Until you're hit with a multi-million dollar class-action lawsuit for indiscriminately distributing potentially sensitive information. Then it is a big deal. It's not only the lawsuit, it's a privacy PR disaster as well. Ayup - *Twitter* loses an audit trail - they can track sends / TCP acknowledgements but have no idea what the receiver is doing with the packets. The consuming site must maintain an audit trail, though, right? Something like this happened at Facebook when they changed their developer TOS. Here's the wording they used: ?You must give users control over their data by posting a privacy policy that explains what data you collect, and how you will use, store, and/or transfer their data. You may cache data you receive from the Facebook API in order to improve your application?s user experience, but you should try to keep the data up to date. You will delete all data you receive from us concerning a user if the user asks you to do so, and will provide a mechanism for users to make such a request.? I'm assuming Twitter will want to do something similar, and I'd think it would also include honoring the delete messages that come down the streams. That could be *very* interesting if the service was doing indexing. ;-) -- M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
