<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for daveman692</title><link>http://disqus.com/people/daveman692/</link><description></description><language>en</language><lastBuildDate>Thu, 29 Oct 2009 15:00:52 -0000</lastBuildDate><item><title>Re: Who or what will be the BitTorrent of Realtime? (Scripting News)</title><link>http://scripting.disqus.com/who_or_what_will_be_the_bittorrent_of_realtime_scripting_news/#comment-21283498</link><description>I think that Twitter, with its constant fail whaling, has proved that yes, we will need that.  I think something like BitTorrent with distributed distribution will suit those needs well.  I wrote about an idea using the DHT (distributed hash table), a common piece of filesharing tech, in a general sense on my blog, here: &lt;a href="http://taylorheffernan.squarespace.com/blog/2009/8/12/on-a-distributed-microblogging-network.html" rel="nofollow"&gt;http://taylorheffernan.squarespace.com/blog/200...&lt;/a&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">twitter-16944017</dc:creator><pubDate>Thu, 29 Oct 2009 15:00:52 -0000</pubDate></item><item><title>Re: Who or what will be the BitTorrent of Realtime? (Scripting News)</title><link>http://scripting.disqus.com/who_or_what_will_be_the_bittorrent_of_realtime_scripting_news/#comment-21087824</link><description>Stepping away from who will get brand value for a minute...&lt;br&gt;&lt;br&gt;I think it's also worth thinking about what the BitTorrent of real-time will look like from a technology perspective.  Both RSSCloud and PubSubHubbub are built around a model where a feed has one (or more) hubs that it specifies.  This means that the hubs need to be super scalable.  BitTorrent changed the downloading model, no longer did the site you're downloading from need to have a giant pipe, but instead you get many smaller pieces from lots of sites each with smaller pipes.  Is there a similar model that will need to emerge for real-time, many hubs with each giving you a piece of the content you're interested in?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Tue, 27 Oct 2009 01:13:43 -0000</pubDate></item><item><title>Re: A Social Web Travelogue</title><link>http://thesocialwebtv.disqus.com/a_social_web_travelogue/#comment-13764162</link><description>The green screen was fun!  Thanks Redgee and Trevor!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Fri, 31 Jul 2009 19:50:44 -0000</pubDate></item><item><title>Re: From Email Culture To Stream Culture: Out Of The Inbox</title><link>http://message.disqus.com/from_email_culture_to_stream_culture_out_of_the_inbox/#comment-9238048</link><description>I think that a lot of secretive email communication would do fine in a public setting. A pal wondering if we could meet up on an upcoming trip, or a recommendation for something to write about could certainly be managed in a fully public context.&lt;br&gt;&lt;br&gt;We have become used to living secretive lives, rather than open ones. Our ethics and codes of conduct are constructed around principles of default secrecy. &lt;br&gt;&lt;br&gt;From my perspective, a large swath of everyday business communication would greatly benefit from being conducted in the open, or dramatically shifted in tone and purpose. &lt;br&gt;&lt;br&gt;So it's not just that the sorts and styles of communication we are involved in now would shift to a public context, but the very nature of what and how we are communicating would change if we were to operate under the premise of openness.&lt;br&gt;&lt;br&gt;There is still a place for privacy and even secrecy, but the notion that all communication defaults to secret and is only made private or public after some examination seems to me to be the opposite of sensible. On the contrary, secrecy should be the exclusive province of only a small fraction of the world's dealings.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">stoweboyd</dc:creator><pubDate>Tue, 12 May 2009 04:56:36 -0000</pubDate></item><item><title>Re: From Email Culture To Stream Culture: Out Of The Inbox</title><link>http://message.disqus.com/from_email_culture_to_stream_culture_out_of_the_inbox/#comment-9237941</link><description>Hey Stowe, how are you finding this changing how you work especially with clients when not everything can/should be public?  I hate my inbox, but beyond thinking of new ways to sort it (I want to see my inbox become more social and topical and less chronological) I don't see how a lot of my email can transition to a fully public environment.  Thoughts?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Tue, 12 May 2009 04:44:04 -0000</pubDate></item><item><title>Re: DREAM JOB: $70K to use Twitter and Facebook</title><link>http://mashable.disqus.com/dream_job_70k_to_use_twitter_and_facebook/#comment-9177284</link><description>I'm so happy that my state is awesome!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Sun, 10 May 2009 02:18:11 -0000</pubDate></item><item><title>Re: How to get started with Facebook's new API? (Scripting News)</title><link>http://scripting.disqus.com/how_to_get_started_with_facebooks_new_api_scripting_news/#comment-8740440</link><description>They should hire me to design a new API for devs who are just getting&lt;br&gt;started. I see the data I want. Use OAuth to give apps access. It's so&lt;br&gt;straightforward, lots of prior art.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">dave</dc:creator><pubDate>Mon, 27 Apr 2009 13:55:29 -0000</pubDate></item><item><title>Re: How to get started with Facebook's new API? (Scripting News)</title><link>http://scripting.disqus.com/how_to_get_started_with_facebooks_new_api_scripting_news/#comment-8739990</link><description>Agreed, but Facebook has always had a history of changing their API back through when they launched Platform initially.  Things are far more stable these days though, but still as you point out hard to get started.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Mon, 27 Apr 2009 13:43:38 -0000</pubDate></item><item><title>Re: How to get started with Facebook's new API? (Scripting News)</title><link>http://scripting.disqus.com/how_to_get_started_with_facebooks_new_api_scripting_news/#comment-8739828</link><description>This moving target syndrome is a bad sign David. And the API should be simple enough that you don't need a toolkit.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">dave</dc:creator><pubDate>Mon, 27 Apr 2009 13:38:42 -0000</pubDate></item><item><title>Re: How to get started with Facebook's new API? (Scripting News)</title><link>http://scripting.disqus.com/how_to_get_started_with_facebooks_new_api_scripting_news/#comment-8739204</link><description>One of the challenges I've run into using Facebook's API in the past is that in general if the library you're using doesn't support their latest API methods, it can be a bit tricky to get going.  Take a look at &lt;a href="http://wiki.developers.facebook.com/index.php/Extended_permissions" rel="nofollow"&gt;http://wiki.developers.facebook.com/index.php/E...&lt;/a&gt; for more information on how to create an app that requests access to your stream.  You should be able to ignore FQL and use their REST API instead.  Take a look at &lt;a href="http://wiki.developers.facebook.com/index.php/Stream.get" rel="nofollow"&gt;http://wiki.developers.facebook.com/index.php/S...&lt;/a&gt;, though realize you'll need to hack on an existing FB library to make it easy.  They also are using Activity Streams so you could request an Atom feed of a user's stream with more info at &lt;a href="http://wiki.developers.facebook.com/index.php/Using_Activity_Streams" rel="nofollow"&gt;http://wiki.developers.facebook.com/index.php/U...&lt;/a&gt;, though you still need to construct the signature on the URL.&lt;br&gt;&lt;br&gt;And yes, they should duplicate the basics of Twitter's API to make things easier for developer's familiar with it who want to try out Facebook's.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Mon, 27 Apr 2009 13:21:31 -0000</pubDate></item><item><title>Re: Single sign-on service OpenID getting more usage</title><link>http://venturebeat.disqus.com/single_sign_on_service_openid_getting_more_usage/#comment-8217595</link><description>I think that one of the reasons why we're starting to see evidence of increased OpenID usage on these smaller sites is that they're largely the ones who have also been keeping up with evolutions to the user experience.  In the screenshot you used from Mixx, even though only one of the buttons actually said "OpenID", if a user chose AOL, Yahoo! or Google they'd be using OpenID under the hood.  The early statistics we're seeing are really reinforcing the idea that when made easy, people want to take advantage of accounts they already have when logging into social web sites especially when there are additional benefits such as profile sharing, friend discovery and activity sharing.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Tue, 14 Apr 2009 22:36:00 -0000</pubDate></item><item><title>Re: http://venturebeat.com/2009/04/02/verisign-brings-extra-security-to-the-iphone/</title><link>http://venturebeat.disqus.com/thread_4273/#comment-7805743</link><description>VeriSign's OpenID Provider (&lt;a href="http://pip.verisignlabs.com/" rel="nofollow"&gt;http://pip.verisignlabs.com/&lt;/a&gt;) also supports their VIP Token network so that you can better protect your OpenID by requiring this unique security code.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Fri, 03 Apr 2009 17:04:28 -0000</pubDate></item><item><title>Re: Episode 31: "On the Road at TransparencyCamp"</title><link>http://thesocialwebtv.disqus.com/episode_31_on_the_road_at_transparencycamp/#comment-6874230</link><description>I think this was the first TransparencyCamp and it was largely focused on the Federal level given that it was in DC.  It sounds like more are being planned both in DC and elsewhere.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Wed, 04 Mar 2009 12:26:21 -0000</pubDate></item><item><title>Re: Hey Dopplr, make me pay.</title><link>http://davemorin.disqus.com/hey_dopplr_make_me_pay/#comment-6675422</link><description>I would also happily pay for Dopplr in the range of $20 per year.  Dopplr is my calendar for anything over a few weeks away.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Thu, 26 Feb 2009 20:54:37 -0000</pubDate></item><item><title>Re: Implementing OAuth is still too hard&amp;#8230; but it doesn&amp;#8217;t have to be</title><link>http://josephsmarr.disqus.com/implementing_oauth_is_still_too_hard8230_but_it_doesn8217t_have_to_be/#comment-6361340</link><description>A bit like your OpenID recipe that you wrote a few years ago.  We're planning to write this sort of guide for our book, but haven't started on the OAuth content yet.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Tue, 17 Feb 2009 22:23:01 -0000</pubDate></item><item><title>Re: Implementing OAuth is still too hard&amp;#8230; but it doesn&amp;#8217;t have to be</title><link>http://josephsmarr.disqus.com/implementing_oauth_is_still_too_hard8230_but_it_doesn8217t_have_to_be/#comment-6361229</link><description>Actually I think the first step should be a good recipe guide and a companion "transparent provider" that the recipe uses. It would take the user through getting/writing a library, hitting a basic "hello world" up to a more complex API call, and it would provide lots of detail and feedback at each step. The idea is, we could tell developers to "first get your code working against this extra-friendly OAuth API, and then turn it to twitter or whoever else you want o hit, since then you'll be confident that it at least works in theory already." And yes, I agree that these types of developer aids are necessary for all the Open Stack building blocks!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jsmarr</dc:creator><pubDate>Tue, 17 Feb 2009 22:16:24 -0000</pubDate></item><item><title>Re: Implementing OAuth is still too hard&amp;#8230; but it doesn&amp;#8217;t have to be</title><link>http://josephsmarr.disqus.com/implementing_oauth_is_still_too_hard8230_but_it_doesn8217t_have_to_be/#comment-6361034</link><description>Makes sense and I think that these lessons and ideas are true for a lot of technologies.  If the OAuth community were to attack this list, what order do you think makes sense?  Is a validator the most important thing to build first?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Tue, 17 Feb 2009 22:05:39 -0000</pubDate></item><item><title>Re: David Recordon (Scripting News)</title><link>http://scripting.disqus.com/david_recordon_scripting_news/#comment-6097985</link><description>Thanks Dave, we should talk more often!&lt;br&gt;&lt;br&gt;I think one of the other things I learned was that there is more confusion about the differences and similarities between OpenID (&lt;a href="http://openid.net/" rel="nofollow"&gt;http://openid.net/&lt;/a&gt;) and OAuth (&lt;a href="http://oauth.net/" rel="nofollow"&gt;http://oauth.net/&lt;/a&gt;) than I realized.  The two communities know there is confusion, but I think we were hoping it was better understood than it is.  I should write a post about the two technologies and also cover the hybrid work underway within the community to make it so that you can use them together.&lt;br&gt;&lt;br&gt;As I said on the phone (re: #7), I think we've done a poor job communicating about the OpenID Design Summit that is being held this Tuesday.  From a week ago when a handful of us thought of the idea to today, a lot has happened and we didn't take the time to go back over the event description to make sure it said what we all wanted it to.  While I personally didn't write the description, last night I edited it to replace "invite-only, but request an invite" with "Because we want to keep it small, focused and given our limited space, the event is designed to strongly favor the participation of folks with design, user experience, usability, a/b testing and similar skills. If you'd like to come, please request but strongly consider what you can contribute to a purely DESIGN conversation (no business or really technical bits) before attending."&lt;br&gt;&lt;br&gt;No one that has requested an invite has been told "no".&lt;br&gt;&lt;br&gt;While we're not going to be making any changes to the OpenID protocol in this meeting, there will most likely be some ideas that emerge that could effect the underlying technology.  A group of people have already started to work on creating a specification working group to turn them into a specification and have it go through our community process to become standardized in a way that would certainly be backwards compatible.  The proposal is on our wiki at &lt;a href="http://wiki.openid.net/OpenID-Popup" rel="nofollow"&gt;http://wiki.openid.net/OpenID-Popup&lt;/a&gt; and anyone who is interested is welcome to participate.&lt;br&gt;&lt;br&gt;I'm sorry that I didn't take the time earlier to make sure the event's description said what it should have.  As I have been since 2005, I'm personally committed to making sure that the OpenID community continues operating in an open and transparent fashion; especially in areas where our process isn't as far developed as it is for things like our specification working groups.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Sun, 08 Feb 2009 15:33:46 -0000</pubDate></item><item><title>Re: 2009/01/28/paypal-openid/</title><link>http://mashable.disqus.com/thread_50568/#comment-6039869</link><description>While it is very true that security of your OpenID is really important, most people have this same problem already today with their email account.  If your email account was hacked, it would be easy to go to many different sites, submit their forgotten password forms and then gain access to your various accounts by reseting your password via your email address.  Most email providers only let you login using a password while OpenID Providers can implement whatever form of authentication they desire.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">David Recordon</dc:creator><pubDate>Wed, 28 Jan 2009 11:33:45 -0000</pubDate></item><item><title>Re: Episode 24: "On Feeds and OpenID Momentum"</title><link>http://thesocialwebtv.disqus.com/episode_24_on_feeds_and_openid_momentum/#comment-5450143</link><description>I'm glad to hear that you're finding the episode useful.  It's great to hear examples of the show helping others in a tangible fashion!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Wed, 21 Jan 2009 19:01:26 -0000</pubDate></item><item><title>Re: RSS as the foundation for realtime (Scripting News)</title><link>http://scripting.disqus.com/rss_as_the_foundation_for_realtime_scripting_news/#comment-4884944</link><description>I was not trying to imply that this would be a catch all. There are quite a few sites pulling plenty of feeds these days and this would be useful in that use case. &lt;br&gt;&lt;br&gt;I'll take a look at the Update Stream. Thanks for the link.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jauderho</dc:creator><pubDate>Sun, 04 Jan 2009 19:30:10 -0000</pubDate></item><item><title>Re: RSS as the foundation for realtime (Scripting News)</title><link>http://scripting.disqus.com/rss_as_the_foundation_for_realtime_scripting_news/#comment-4884710</link><description>SUP is only useful if you are already fetching a lot of feeds and thus can discover their SUP IDs to look for in the updates stream.  Thus, it's useful for FriendFeed as they already know about the majority of feeds that would be included in a SUP updates stream.&lt;br&gt;&lt;br&gt;SUP is useful if you want a layer of indirection between the list of changes and URLs of feeds (it would be useful for advertising updates to non-public feeds) but as it stands still seems like more work than something like the Six Apart Update Stream (&lt;a href="http://updates.sixapart.com/" rel="nofollow"&gt;http://updates.sixapart.com/&lt;/a&gt;) which contains full content and can be easily transformed into a list of updated feed URLs with curl and grep.  (n.b. I work for Six Apart)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Sun, 04 Jan 2009 19:12:24 -0000</pubDate></item><item><title>Re: LinkedIn InApps - 2008 Review</title><link>http://socialtimes.disqus.com/linkedin_inapps_2008_review/#comment-4856245</link><description>I'm sorry that you've been having problems trying out Blog Link both to show recent posts on your profile and to see recent posts from contacts within your LinkedIn network.  There should not be a problem showing recent posts on your profile assuming that you've added at least one website to your LinkedIn profile which has a RSS or Atom feed.  If you could, please send me a link to your LinkedIn profile (my email is &lt;a href="mailto:david@sixapart.com" rel="nofollow"&gt;david@sixapart.com&lt;/a&gt;) I'd be happy to take a look to see if we can find out why this isn't working for you.&lt;br&gt;&lt;br&gt;As to the home box which aggregates recent content from contacts within your network, it should select some of your contacts, look for recent updates, and then aggregate them together.  While we've done a lot of work to have Blog Link perform as intended, we've found situations -- especially when a LinkedIn user has a very large network -- that due to the information returned by the LinkedIn API and the work involved to aggregate content, the recent posts from your network view can be quite slow to load.  As the average LinkedIn user has well under a few hundred contacts within their network, it seems that the LinkedIn APIs and thus how our application is designed for users with far fewer contacts than you have.  Myself, I have around five-hundred contacts within my network and the recent posts aggregate view still loads far slower than we'd like.&lt;br&gt;&lt;br&gt;While we've worked with the LinkedIn InApp team to try to speed this up as much as possible, due to how Blog Link is uniquely using the LinkedIn APIs among the launch partners, this unfortunately doesn't seem like something that will be resolved for users with large networks in the near future.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Fri, 02 Jan 2009 19:06:30 -0000</pubDate></item><item><title>Re: Twitter warning: your account data is being sold</title><link>http://scobleizer.disqus.com/twitter_warning_your_account_data_is_being_sold/#comment-9713286</link><description>Twitter needs to let third-party applications authenticate you without asking for your password.  OAuth solves this problem and it would be great to see Twitter add support for OAuth to their API!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">David Recordon</dc:creator><pubDate>Thu, 01 Jan 2009 20:38:15 -0000</pubDate></item><item><title>Re: The space between Twitter and FriendFeed (Scripting News)</title><link>http://scripting.disqus.com/the_space_between_twitter_and_friendfeed_scripting_news/#comment-4236756</link><description>Sure, but it seems like all of that can be configurable.  Twitter gives you very few choices and FriendFeed quite a few more.  In this hybrid I could choose to only receive text from one person, photos + location updates from another, etc, etc.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">daveman692</dc:creator><pubDate>Sun, 07 Dec 2008 13:05:12 -0000</pubDate></item></channel></rss>