[twitter-dev] Re: OAuth support and reformatted DMs live on user streams
#1 OAuth. This took a long time to debug but I think I found the problem. It looks like you guys expect the OAuth Authorization header params to be separated by a comma (which is OK), AND at least one space (which is not OK). Am I right ? (The spaces after the comma are optional if I remember the OAuth spec correctly.) #3 The use cases for hydrated delete events would be exactly the same on your part as the ones for hydrating social events :) (which I believe is to make the stream more useful by itself and not *having* to use the REST API to understand the stream events). I keep user objects ATM, or ask the REST API for statuses or user ids I didn't encounter before, there's no question that it's doable, I was just wondering whether the same thinking would be applied consistently to all events, the delete ones right now and any new ones created in the future ? Thanks Mark and John Rémy @ldq On May 6, 6:46 pm, Mark McBride mmcbr...@twitter.com wrote: Did you adjust the timestamp in that tool? The hosebird implementation tolerates at most a 5 minute clock skew... in other words if it receives a timestamp that is 5 minutes older (or newer) than the current time, it rejects the request. ---Mark http://twitter.com/mccv On Thu, May 6, 2010 at 6:39 AM, lqd remy.ra...@gmail.com wrote: Hey guys, a couple questions/remarks on the new user streams features: 1) OAuth I have no problem using the stream with BasicAuth, nor using the REST API with OAuth. However I'm always getting 401s with OAuth on the stream, even though Zac's fork or earlybird works flawlessly. Just to try and locate the problem I tried signing the request with the official noob tool athttp://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signin... and sending the header with curl (with fiddling with spaces, tabs newline just in case, and even the realm value - just because earlybird's impl doesn't send it), and I still can't login. While my own code signing matches the parameters this tool outputs (and works on api.twitter.com) it doesn't match what the ruby gem generates, even when using the same timestamp and nonce, so I was suspecting some difference in the base string. (I don't know Ruby, or how to get the Base String there, but there's apparently a signature_base_string method, and it did seem to have all the oauth params in the query string) 2) +1 on the user burping at the beginning :) 3) Are the deletion notices going to be hydrated too ? ATM it's a little raw. While it's understandable for the status not to be there since it's just been deleted, maybe the full JSON user could be there instead of just its id ? Thanks Rémy @lqd On May 6, 12:41 am, Mark McBride mmcbr...@twitter.com wrote: Ok. The query string OAuth variant should be working now. We only support HMAC-SHA1 (just like twitter.com does) for signature methods, and don't have plans to support other schemes. ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 3:21 PM, John Kalucki j...@twitter.com wrote: We should probably just burp the whole user object out at connection start. On Wed, May 5, 2010 at 3:12 PM, Zac Bowling zbowl...@gmail.com wrote: Hydrated message support in earlybird! http://github.com/zbowling/earlybird/ OAuth in query string doesn't work and only HMAC-SHA1 signature (unless you only allow plaintext over SSL) but its fine. One feature request would be an inital event with the users credentials just like how the user's social graph comes down initially. Right now I don't know the user's screen_name unless I also hit api.twitter.com or he tells me on the command line. With that I could drop the dependency on the twitter gem. Zac Bowling @zbowling On Wed, May 5, 2010 at 10:54 AM, Mark McBride mmcbr...@twitter.com wrote: It should support both. Can you send me a direct email with a URL that you tried? ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 10:38 AM, Zac Bowling zbowl...@gmail.com wrote: My fork of earlybird works: http://github.com/zbowling/earlybird/ Fixing it to support hydrated objects. One thing is that it doesn't appear to support query string passed OAuth params but if I pass it as authentication headers it works. Zac Bowling On Wed, May 5, 2010 at 10:31 AM, Mark McBride mmcbr...@twitter.com wrote: OAuth support on betastream is live now. This is different OAuth implementation than we use on twitter.com, so if you find any rough edges please let us know quick like. The changes to make direct messages more distinguishable from tweets has also been pushed. This will probably require some changes in parsing logic when dealing with DMs. ---Mark http://twitter.com/mccv
Re: [twitter-dev] Re: OAuth support and reformatted DMs live on user streams
Other than orthogonality, I don't understand the use case for hydrated deletions. They're useful to delete existing data. What would you display, and why? Note that every byte that we send costs something in CPU, bandwidth and increased latency. On Fri, May 7, 2010 at 2:38 AM, lqd remy.ra...@gmail.com wrote: #1 OAuth. This took a long time to debug but I think I found the problem. It looks like you guys expect the OAuth Authorization header params to be separated by a comma (which is OK), AND at least one space (which is not OK). Am I right ? (The spaces after the comma are optional if I remember the OAuth spec correctly.) #3 The use cases for hydrated delete events would be exactly the same on your part as the ones for hydrating social events :) (which I believe is to make the stream more useful by itself and not *having* to use the REST API to understand the stream events). I keep user objects ATM, or ask the REST API for statuses or user ids I didn't encounter before, there's no question that it's doable, I was just wondering whether the same thinking would be applied consistently to all events, the delete ones right now and any new ones created in the future ? Thanks Mark and John Rémy @ldq On May 6, 6:46 pm, Mark McBride mmcbr...@twitter.com wrote: Did you adjust the timestamp in that tool? The hosebird implementation tolerates at most a 5 minute clock skew... in other words if it receives a timestamp that is 5 minutes older (or newer) than the current time, it rejects the request. ---Mark http://twitter.com/mccv On Thu, May 6, 2010 at 6:39 AM, lqd remy.ra...@gmail.com wrote: Hey guys, a couple questions/remarks on the new user streams features: 1) OAuth I have no problem using the stream with BasicAuth, nor using the REST API with OAuth. However I'm always getting 401s with OAuth on the stream, even though Zac's fork or earlybird works flawlessly. Just to try and locate the problem I tried signing the request with the official noob tool athttp://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signin... and sending the header with curl (with fiddling with spaces, tabs newline just in case, and even the realm value - just because earlybird's impl doesn't send it), and I still can't login. While my own code signing matches the parameters this tool outputs (and works on api.twitter.com) it doesn't match what the ruby gem generates, even when using the same timestamp and nonce, so I was suspecting some difference in the base string. (I don't know Ruby, or how to get the Base String there, but there's apparently a signature_base_string method, and it did seem to have all the oauth params in the query string) 2) +1 on the user burping at the beginning :) 3) Are the deletion notices going to be hydrated too ? ATM it's a little raw. While it's understandable for the status not to be there since it's just been deleted, maybe the full JSON user could be there instead of just its id ? Thanks Rémy @lqd On May 6, 12:41 am, Mark McBride mmcbr...@twitter.com wrote: Ok. The query string OAuth variant should be working now. We only support HMAC-SHA1 (just like twitter.com does) for signature methods, and don't have plans to support other schemes. ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 3:21 PM, John Kalucki j...@twitter.com wrote: We should probably just burp the whole user object out at connection start. On Wed, May 5, 2010 at 3:12 PM, Zac Bowling zbowl...@gmail.com wrote: Hydrated message support in earlybird! http://github.com/zbowling/earlybird/ OAuth in query string doesn't work and only HMAC-SHA1 signature (unless you only allow plaintext over SSL) but its fine. One feature request would be an inital event with the users credentials just like how the user's social graph comes down initially. Right now I don't know the user's screen_name unless I also hit api.twitter.com or he tells me on the command line. With that I could drop the dependency on the twitter gem. Zac Bowling @zbowling On Wed, May 5, 2010 at 10:54 AM, Mark McBride mmcbr...@twitter.com wrote: It should support both. Can you send me a direct email with a URL that you tried? ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 10:38 AM, Zac Bowling zbowl...@gmail.com wrote: My fork of earlybird works: http://github.com/zbowling/earlybird/ Fixing it to support hydrated objects. One thing is that it doesn't appear to support query string passed OAuth params but if I pass it as authentication headers it works. Zac Bowling On Wed, May 5, 2010 at 10:31 AM, Mark McBride mmcbr...@twitter.com wrote: OAuth support on betastream is live now. This is different OAuth implementation than we use on twitter.com, so if you find any rough edges please let us know quick
Re: [twitter-dev] Re: OAuth support and reformatted DMs live on user streams
You are correct on point 1. That should be fixed today. Sent from mobile device On May 7, 2010, at 2:38 AM, lqd remy.ra...@gmail.com wrote: #1 OAuth. This took a long time to debug but I think I found the problem. It looks like you guys expect the OAuth Authorization header params to be separated by a comma (which is OK), AND at least one space (which is not OK). Am I right ? (The spaces after the comma are optional if I remember the OAuth spec correctly.) #3 The use cases for hydrated delete events would be exactly the same on your part as the ones for hydrating social events :) (which I believe is to make the stream more useful by itself and not *having* to use the REST API to understand the stream events). I keep user objects ATM, or ask the REST API for statuses or user ids I didn't encounter before, there's no question that it's doable, I was just wondering whether the same thinking would be applied consistently to all events, the delete ones right now and any new ones created in the future ? Thanks Mark and John Rémy @ldq On May 6, 6:46 pm, Mark McBride mmcbr...@twitter.com wrote: Did you adjust the timestamp in that tool? The hosebird implementation tolerates at most a 5 minute clock skew... in other words if it receives a timestamp that is 5 minutes older (or newer) than the current time, it rejects the request. ---Mark http://twitter.com/mccv On Thu, May 6, 2010 at 6:39 AM, lqd remy.ra...@gmail.com wrote: Hey guys, a couple questions/remarks on the new user streams features: 1) OAuth I have no problem using the stream with BasicAuth, nor using the REST API with OAuth. However I'm always getting 401s with OAuth on the stream, even though Zac's fork or earlybird works flawlessly. Just to try and locate the problem I tried signing the request with the official noob tool athttp://hueniverse.com/2008/10/beginners- guide-to-oauth-part-iv-signin... and sending the header with curl (with fiddling with spaces, tabs newline just in case, and even the realm value - just because earlybird's impl doesn't send it), and I still can't login. While my own code signing matches the parameters this tool outputs (and works on api.twitter.com) it doesn't match what the ruby gem generates, even when using the same timestamp and nonce, so I was suspecting some difference in the base string. (I don't know Ruby, or how to get the Base String there, but there's apparently a signature_base_string method, and it did seem to have all the oauth params in the query string) 2) +1 on the user burping at the beginning :) 3) Are the deletion notices going to be hydrated too ? ATM it's a little raw. While it's understandable for the status not to be there since it's just been deleted, maybe the full JSON user could be there instead of just its id ? Thanks Rémy @lqd On May 6, 12:41 am, Mark McBride mmcbr...@twitter.com wrote: Ok. The query string OAuth variant should be working now. We only support HMAC-SHA1 (just like twitter.com does) for signature methods, and don't have plans to support other schemes. ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 3:21 PM, John Kalucki j...@twitter.com wrote: We should probably just burp the whole user object out at connection start. On Wed, May 5, 2010 at 3:12 PM, Zac Bowling zbowl...@gmail.com wrote: Hydrated message support in earlybird! http://github.com/zbowling/earlybird/ OAuth in query string doesn't work and only HMAC-SHA1 signature (unless you only allow plaintext over SSL) but its fine. One feature request would be an inital event with the users credentials just like how the user's social graph comes down initially. Right now I don't know the user's screen_name unless I also hit api.twitter.com or he tells me on the command line. With that I could drop the dependency on the twitter gem. Zac Bowling @zbowling On Wed, May 5, 2010 at 10:54 AM, Mark McBride mmcbr...@twitter.com wrote: It should support both. Can you send me a direct email with a URL that you tried? ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 10:38 AM, Zac Bowling zbowl...@gmail.com wrote: My fork of earlybird works: http://github.com/zbowling/earlybird/ Fixing it to support hydrated objects. One thing is that it doesn't appear to support query string passed OAuth params but if I pass it as authentication headers it works. Zac Bowling On Wed, May 5, 2010 at 10:31 AM, Mark McBride mmcbr...@twitter.com wrote: OAuth support on betastream is live now. This is different OAuth implementation than we use on twitter.com, so if you find any rough edges please let us know quick like. The changes to make direct messages more distinguishable from tweets has also been pushed. This will probably require some changes in parsing logic when dealing with DMs. ---Mark http://twitter.com/mccv
[twitter-dev] Re: OAuth support and reformatted DMs live on user streams
I'm just displaying the events as they arrive, eg John Kalucki deleted a tweet. If I have the specific status I'll show it's been deleted and link to it from the event (those 2 can be far from each other in the timeline). Nothing important really, I was mostly asking out of curiosity, I don't need them to be hydrated or anything :) Great new about the OAuth fix! Thanks for the answers John and Mark Cheers Rémy On May 7, 5:11 pm, Mark McBride mmcbr...@twitter.com wrote: You are correct on point 1. That should be fixed today. Sent from mobile device On May 7, 2010, at 2:38 AM, lqd remy.ra...@gmail.com wrote: #1 OAuth. This took a long time to debug but I think I found the problem. It looks like you guys expect the OAuth Authorization header params to be separated by a comma (which is OK), AND at least one space (which is not OK). Am I right ? (The spaces after the comma are optional if I remember the OAuth spec correctly.) #3 The use cases for hydrated delete events would be exactly the same on your part as the ones for hydrating social events :) (which I believe is to make the stream more useful by itself and not *having* to use the REST API to understand the stream events). I keep user objects ATM, or ask the REST API for statuses or user ids I didn't encounter before, there's no question that it's doable, I was just wondering whether the same thinking would be applied consistently to all events, the delete ones right now and any new ones created in the future ? Thanks Mark and John Rémy @ldq On May 6, 6:46 pm, Mark McBride mmcbr...@twitter.com wrote: Did you adjust the timestamp in that tool? The hosebird implementation tolerates at most a 5 minute clock skew... in other words if it receives a timestamp that is 5 minutes older (or newer) than the current time, it rejects the request. ---Mark http://twitter.com/mccv On Thu, May 6, 2010 at 6:39 AM, lqd remy.ra...@gmail.com wrote: Hey guys, a couple questions/remarks on the new user streams features: 1) OAuth I have no problem using the stream with BasicAuth, nor using the REST API with OAuth. However I'm always getting 401s with OAuth on the stream, even though Zac's fork or earlybird works flawlessly. Just to try and locate the problem I tried signing the request with the official noob tool athttp://hueniverse.com/2008/10/beginners- guide-to-oauth-part-iv-signin... and sending the header with curl (with fiddling with spaces, tabs newline just in case, and even the realm value - just because earlybird's impl doesn't send it), and I still can't login. While my own code signing matches the parameters this tool outputs (and works on api.twitter.com) it doesn't match what the ruby gem generates, even when using the same timestamp and nonce, so I was suspecting some difference in the base string. (I don't know Ruby, or how to get the Base String there, but there's apparently a signature_base_string method, and it did seem to have all the oauth params in the query string) 2) +1 on the user burping at the beginning :) 3) Are the deletion notices going to be hydrated too ? ATM it's a little raw. While it's understandable for the status not to be there since it's just been deleted, maybe the full JSON user could be there instead of just its id ? Thanks Rémy @lqd On May 6, 12:41 am, Mark McBride mmcbr...@twitter.com wrote: Ok. The query string OAuth variant should be working now. We only support HMAC-SHA1 (just like twitter.com does) for signature methods, and don't have plans to support other schemes. ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 3:21 PM, John Kalucki j...@twitter.com wrote: We should probably just burp the whole user object out at connection start. On Wed, May 5, 2010 at 3:12 PM, Zac Bowling zbowl...@gmail.com wrote: Hydrated message support in earlybird! http://github.com/zbowling/earlybird/ OAuth in query string doesn't work and only HMAC-SHA1 signature (unless you only allow plaintext over SSL) but its fine. One feature request would be an inital event with the users credentials just like how the user's social graph comes down initially. Right now I don't know the user's screen_name unless I also hit api.twitter.com or he tells me on the command line. With that I could drop the dependency on the twitter gem. Zac Bowling @zbowling On Wed, May 5, 2010 at 10:54 AM, Mark McBride mmcbr...@twitter.com wrote: It should support both. Can you send me a direct email with a URL that you tried? ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 10:38 AM, Zac Bowling zbowl...@gmail.com wrote: My fork of earlybird works: http://github.com/zbowling/earlybird/ Fixing it to support hydrated objects. One thing is that it doesn't appear to support query string passed OAuth
[twitter-dev] Re: OAuth support and reformatted DMs live on user streams
Hey guys, a couple questions/remarks on the new user streams features: 1) OAuth I have no problem using the stream with BasicAuth, nor using the REST API with OAuth. However I'm always getting 401s with OAuth on the stream, even though Zac's fork or earlybird works flawlessly. Just to try and locate the problem I tried signing the request with the official noob tool at http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/ and sending the header with curl (with fiddling with spaces, tabs newline just in case, and even the realm value - just because earlybird's impl doesn't send it), and I still can't login. While my own code signing matches the parameters this tool outputs (and works on api.twitter.com) it doesn't match what the ruby gem generates, even when using the same timestamp and nonce, so I was suspecting some difference in the base string. (I don't know Ruby, or how to get the Base String there, but there's apparently a signature_base_string method, and it did seem to have all the oauth params in the query string) 2) +1 on the user burping at the beginning :) 3) Are the deletion notices going to be hydrated too ? ATM it's a little raw. While it's understandable for the status not to be there since it's just been deleted, maybe the full JSON user could be there instead of just its id ? Thanks Rémy @lqd On May 6, 12:41 am, Mark McBride mmcbr...@twitter.com wrote: Ok. The query string OAuth variant should be working now. We only support HMAC-SHA1 (just like twitter.com does) for signature methods, and don't have plans to support other schemes. ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 3:21 PM, John Kalucki j...@twitter.com wrote: We should probably just burp the whole user object out at connection start. On Wed, May 5, 2010 at 3:12 PM, Zac Bowling zbowl...@gmail.com wrote: Hydrated message support in earlybird! http://github.com/zbowling/earlybird/ OAuth in query string doesn't work and only HMAC-SHA1 signature (unless you only allow plaintext over SSL) but its fine. One feature request would be an inital event with the users credentials just like how the user's social graph comes down initially. Right now I don't know the user's screen_name unless I also hit api.twitter.com or he tells me on the command line. With that I could drop the dependency on the twitter gem. Zac Bowling @zbowling On Wed, May 5, 2010 at 10:54 AM, Mark McBride mmcbr...@twitter.com wrote: It should support both. Can you send me a direct email with a URL that you tried? ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 10:38 AM, Zac Bowling zbowl...@gmail.com wrote: My fork of earlybird works: http://github.com/zbowling/earlybird/ Fixing it to support hydrated objects. One thing is that it doesn't appear to support query string passed OAuth params but if I pass it as authentication headers it works. Zac Bowling On Wed, May 5, 2010 at 10:31 AM, Mark McBride mmcbr...@twitter.com wrote: OAuth support on betastream is live now. This is different OAuth implementation than we use on twitter.com, so if you find any rough edges please let us know quick like. The changes to make direct messages more distinguishable from tweets has also been pushed. This will probably require some changes in parsing logic when dealing with DMs. ---Mark http://twitter.com/mccv
Re: [twitter-dev] Re: OAuth support and reformatted DMs live on user streams
#1 Mark can help. #2 I filed a story for later triage. #3 What would the use case be for hydrating status deletion notes? For display purposes, I can see them being used to remove tweets - but displayed tweets should be indexed by status_id. What else might you want to display when a following deletes a displayed tweet? You also could keep the user object that was sent with the status, if needed. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Thu, May 6, 2010 at 6:39 AM, lqd remy.ra...@gmail.com wrote: Hey guys, a couple questions/remarks on the new user streams features: 1) OAuth I have no problem using the stream with BasicAuth, nor using the REST API with OAuth. However I'm always getting 401s with OAuth on the stream, even though Zac's fork or earlybird works flawlessly. Just to try and locate the problem I tried signing the request with the official noob tool at http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/ and sending the header with curl (with fiddling with spaces, tabs newline just in case, and even the realm value - just because earlybird's impl doesn't send it), and I still can't login. While my own code signing matches the parameters this tool outputs (and works on api.twitter.com) it doesn't match what the ruby gem generates, even when using the same timestamp and nonce, so I was suspecting some difference in the base string. (I don't know Ruby, or how to get the Base String there, but there's apparently a signature_base_string method, and it did seem to have all the oauth params in the query string) 2) +1 on the user burping at the beginning :) 3) Are the deletion notices going to be hydrated too ? ATM it's a little raw. While it's understandable for the status not to be there since it's just been deleted, maybe the full JSON user could be there instead of just its id ? Thanks Rémy @lqd On May 6, 12:41 am, Mark McBride mmcbr...@twitter.com wrote: Ok. The query string OAuth variant should be working now. We only support HMAC-SHA1 (just like twitter.com does) for signature methods, and don't have plans to support other schemes. ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 3:21 PM, John Kalucki j...@twitter.com wrote: We should probably just burp the whole user object out at connection start. On Wed, May 5, 2010 at 3:12 PM, Zac Bowling zbowl...@gmail.com wrote: Hydrated message support in earlybird! http://github.com/zbowling/earlybird/ OAuth in query string doesn't work and only HMAC-SHA1 signature (unless you only allow plaintext over SSL) but its fine. One feature request would be an inital event with the users credentials just like how the user's social graph comes down initially. Right now I don't know the user's screen_name unless I also hit api.twitter.com or he tells me on the command line. With that I could drop the dependency on the twitter gem. Zac Bowling @zbowling On Wed, May 5, 2010 at 10:54 AM, Mark McBride mmcbr...@twitter.com wrote: It should support both. Can you send me a direct email with a URL that you tried? ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 10:38 AM, Zac Bowling zbowl...@gmail.com wrote: My fork of earlybird works: http://github.com/zbowling/earlybird/ Fixing it to support hydrated objects. One thing is that it doesn't appear to support query string passed OAuth params but if I pass it as authentication headers it works. Zac Bowling On Wed, May 5, 2010 at 10:31 AM, Mark McBride mmcbr...@twitter.com wrote: OAuth support on betastream is live now. This is different OAuth implementation than we use on twitter.com, so if you find any rough edges please let us know quick like. The changes to make direct messages more distinguishable from tweets has also been pushed. This will probably require some changes in parsing logic when dealing with DMs. ---Mark http://twitter.com/mccv
Re: [twitter-dev] Re: OAuth support and reformatted DMs live on user streams
Did you adjust the timestamp in that tool? The hosebird implementation tolerates at most a 5 minute clock skew... in other words if it receives a timestamp that is 5 minutes older (or newer) than the current time, it rejects the request. ---Mark http://twitter.com/mccv On Thu, May 6, 2010 at 6:39 AM, lqd remy.ra...@gmail.com wrote: Hey guys, a couple questions/remarks on the new user streams features: 1) OAuth I have no problem using the stream with BasicAuth, nor using the REST API with OAuth. However I'm always getting 401s with OAuth on the stream, even though Zac's fork or earlybird works flawlessly. Just to try and locate the problem I tried signing the request with the official noob tool at http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/ and sending the header with curl (with fiddling with spaces, tabs newline just in case, and even the realm value - just because earlybird's impl doesn't send it), and I still can't login. While my own code signing matches the parameters this tool outputs (and works on api.twitter.com) it doesn't match what the ruby gem generates, even when using the same timestamp and nonce, so I was suspecting some difference in the base string. (I don't know Ruby, or how to get the Base String there, but there's apparently a signature_base_string method, and it did seem to have all the oauth params in the query string) 2) +1 on the user burping at the beginning :) 3) Are the deletion notices going to be hydrated too ? ATM it's a little raw. While it's understandable for the status not to be there since it's just been deleted, maybe the full JSON user could be there instead of just its id ? Thanks Rémy @lqd On May 6, 12:41 am, Mark McBride mmcbr...@twitter.com wrote: Ok. The query string OAuth variant should be working now. We only support HMAC-SHA1 (just like twitter.com does) for signature methods, and don't have plans to support other schemes. ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 3:21 PM, John Kalucki j...@twitter.com wrote: We should probably just burp the whole user object out at connection start. On Wed, May 5, 2010 at 3:12 PM, Zac Bowling zbowl...@gmail.com wrote: Hydrated message support in earlybird! http://github.com/zbowling/earlybird/ OAuth in query string doesn't work and only HMAC-SHA1 signature (unless you only allow plaintext over SSL) but its fine. One feature request would be an inital event with the users credentials just like how the user's social graph comes down initially. Right now I don't know the user's screen_name unless I also hit api.twitter.com or he tells me on the command line. With that I could drop the dependency on the twitter gem. Zac Bowling @zbowling On Wed, May 5, 2010 at 10:54 AM, Mark McBride mmcbr...@twitter.com wrote: It should support both. Can you send me a direct email with a URL that you tried? ---Mark http://twitter.com/mccv On Wed, May 5, 2010 at 10:38 AM, Zac Bowling zbowl...@gmail.com wrote: My fork of earlybird works: http://github.com/zbowling/earlybird/ Fixing it to support hydrated objects. One thing is that it doesn't appear to support query string passed OAuth params but if I pass it as authentication headers it works. Zac Bowling On Wed, May 5, 2010 at 10:31 AM, Mark McBride mmcbr...@twitter.com wrote: OAuth support on betastream is live now. This is different OAuth implementation than we use on twitter.com, so if you find any rough edges please let us know quick like. The changes to make direct messages more distinguishable from tweets has also been pushed. This will probably require some changes in parsing logic when dealing with DMs. ---Mark http://twitter.com/mccv
