What I do – Page 8 – Factory Joe

Announcing OAuth 1.0 Public Draft 1

Well, it’s been a long time coming, and if you’ve been following my Twitters at all, you’ll know that I’ve been working on an open, community-driven authorization protocol called OAuth for the past few months. Today we released the first Public Draft for review.

The idea started as a humble effort to accomplish two goals: first, to enable Ma.gnolia members who created their accounts with OpenIDs (and therefore don’t have traditional usernames and passwords) to be able to use Dashboard Widgets; and second, to enable Twitter to adopt OpenID when its current API requires a username and password to authorize access to protected status feeds.

In any case, both of these use cases were part of the same problem: the lack of a uniform and open protocol for what’s called “delegated authentication”. Another useful metaphor that I’ve come to like is what John Panzer and Eran Hammer-Lahav used before him, that of a valet key:

OAuth is like a valet key for all your web services. A valet key lets you give a valet the ability to park your car, but not the ability to get into the trunk or drive more than 2 miles or limit the RPMs on your high end German automobile. In the same way, an OAuth key lets you give a web agent the ability to check your web mail but NOT the ability to pretend to be you and send mail to everybody in your address book.

Arguably the value of OAuth as a technological innovation goes beyond that. After all, anyone can implement their own valet key system that works in their own universe of vehicles. The harder part is actually the social and political work of getting everyone to buy in and follow the same design pattern, leading to interoperability between systems.

In fact that’s where we were before OAuth: Google had AuthSub, AOL had OpenAuth (OAuth’s former name, by the way), Yahoo had BBAuth and Flickr had FlickrAuth (not to mention Facebook Auth and Windows Live ID Web Authentication). Which meant that if you were an independent developer (like Matt Biddulph from Dopplr) you had to pick which auth system you wanted to support unless you had money and time coming out of your armpits, you’d code against all of them.

Of course, that’s not reality. And no one has the time or energy to maintain support for every protocol, so instead, most people take the easy way out and just ask for the veritable keys to all the different services you use:

Now, don’t get me wrong, this gets the job done. And it works. But it’s a really really really bad idea.

Not only are people being trained into thinking that it’s okay to fill in any form that looks like a Gmail login box on any old website (trusted or not) but it’s creating an untenable situation where, as a member of these various services, you have no way to control the access you’ve given away without changes your password — which in effect will disable every one of these sites that’s storing your credentials — forcing you to revisit every one of them and share with them your new username and password. What a crappy experience!

Fortunately, Flickr got it right a long time ago and set the bar for user experience. In their model, you can try out a bunch of tools that help you upload photos to the service or use off-site mashups that do cool things with your photos all without giving away your most valuable credentials: your username and password!

Instead, when you sign in to your account, Flickr will assign special keys called “tokens” to each application that wants to access your account. Flickr then lets you configure how much access you want to grant to each app and lets you revoke that access at any time. No changing your password, no running around to have to re-authenticate all the apps that you still want to use if you want to disable one of them.

OAuth takes that approach one step further and extracts the best practices from the popular authentication systems I mentioned above and turns it into one elegant, unified authentication protocol that anyone can implement. And, because it’s an open standard that we hope many people will adopt and replace their own proprietary authentication systems with, it should be a no-brainer for developers to use and to support, resulting in fewer sites that, with a straight face, continue to ask you for your username and password (oh, and yes, it is compatible with OpenID, with Google Accounts, with Yahoo Accounts and any other sign-in system — OAuth doesn’t dictate how you sign-in, only how you delegate authentication).

Even though we’re only releasing the first public draft today, we already have pledges from Ma.gnolia, Twitter, Pownce, Jaiku, Dopplr and others that they intend to implement the protocol.

If you want to get involved, join our mailing list, take a look at the OAuth libraries under development for PHP, Ruby, Python, C# and others. We plan to formally release the final version the OAuth Protocol v1.0 on Oct 1, so watch this space for more news until then.

Stop building social networks

I started writing this post August 8th. Now that Dave Recordon is at Six Apart and blogging about these things and Brad Fitzpatrick has moved on to Google, I thought I should finally finish this post.

I fortuitously ran into Tim O’Reilly, Brad Fitzpatrick and Dave Recordon in Philz yesterday as I was grabbing a cup of coffee. They were talking about some pretty heady ideas and strategies towards wrenching free one’s friends networks from the multiple social networks out there — and recombining them in such a way that it’d be very hard to launch a closed down social network again.

The idea isn’t new. It’s certainly been attempted numerous times, with few successful efforts to show for it to date. I think that Brad and Dave might be on to something with their approach, though, but it begs an important question: once you’ve got a portable social network, what do you do with it?

Fortunately, Brian Oberkirch has been doing a lot of thinking on this subject lately with his series on Portable Social Networks, starting with a post on designing portable social networks lead up to his most recent post offering some great tips on how to prepare your site for the day when your users come knocking for a list of their friends to populate their new favor hang.

In his kick-off post, Brian laid the problem of social network fatigue as stemming from the:

Creation of yet another login/password to manage

Need to re-enter profile information for new services

Need to search and re-add network contacts at each new service

Need to reset notification and privacy preferences for each new service

Inability to manage and add value to these networks from a central app/work flow

I think these are the fundamental drivers behind the current surge of progress in user-centric identity services, as opposed to the aging trend of network-centric web services. If Eric Schmidt thinks that Web 3.0 will be made up of small pieces loosely joined and “in the cloud”, my belief, going back to my time with Flock, is that having consistent identifiers for the same person across multiple networks, services or applications is going to be fundamental to getting the next evolution of the web right.

Tim made the point during our discussion that at one point in computing history, SQL databases embedded access permissions in the database itself. In modern times, access controls have been decoupled from the data and are managed, maintained and federated without regard to the data itself, affording a host of new functionality and stability simply by adjusting the architecture of the system.

If we decouple people and their identifiers from the networks that currently define them, we start moving towards greater granularity of privacy control through mechanisms like global social whitelists and buddy list blocklists. It also means that individuals can solicit services to be built that serve their unique social graph across any sites and domains (kind of like a fingerprint of your relationship connections), rather than being restrained to the limited freedom in locked down networks like Facebook. And ultimately, it enables cross-sharing content and media with anyone whom you choose, regardless of the network that they’re on (just like email today, where you can send someone on Yahoo.com email from Gmail.com or even Hotmail.com, and so on, but with finer contact controls). The result is that the crosscut of one’s social network could be as complete (or discreet) as one chose, and that rather than managing it in a social network-centric way, you’d manage it centrally, just as you do your IM buddy list, and it would follow you around on any site that you visit.

So it’s become something of a refrain in the advice that we’ve been giving out lately to our clients that they should think very critically about what social functionality they should (and shouldn’t) build directly into their sites. Rather than assuming that they should “build what Flickr has” or think about which features of Facebook they should absorb, the better question, I think, is to assume that in the next 6-8 months (for the early adopters at least) there’s going to be a shift to these portable networks. Where the basics will mostly be better covered by existing solutions and will not need to be rebuilt. Where each new site — especially those with specific functionality like TripIt (disclosure: we’ve consulted TripIt) — will need to focus less on building out its own social network and more on how social functionality can support their core competency.

We’re still in the early stages of recognizing and identifying the components of this problem. Thus far, the Microformats wiki says:

Why is it that every single social network community site makes you:

re-enter all your personal profile info (name, email, birthday, URL etc.)?

re-add all your friends?

In addition, why do you have to:

re-turn off notifications?

re-specify privacy preferences?

re-block negative people?

AKA “social network fatigue problem” and “social network update/maintenance problem”.

I’ve yet to be convinced that this is a problem that the “rest of the world” beyond social geeks is suffering, but I do think that the situation can be greatly improved, even for folks who are used to abandoning their profiles when they forget their passwords. For one thing, the world today is too network-centric, and not person-centric. While I do think people should be able to take on multiple personas online (professional, casual, hobby, family, and so on), I don’t think that that means that they should have those boundaries set for them by the networks they join. Instead, they should maintain their multiple personas as separate identifiers: email addresses, IM addresses and/or profile URLs (i.e. OpenIDs). This allows for handy separation based on the way people already materialize themselves online. Projects like NoseRub and even the smaller additions of offsite-identifiers on sites like Digg, Twitter and Pownce also acknowledge that members think of themselves as being more faceted than a single URL indicates.

This is a good thing. And this is where social computing needs to go.

We need to stop building independent spider webs of sticky siloed social activity. We need to stop fighting the nature of the web and embrace the design of uniform resource identifiers for people. We need to have a user agent that actually understands what it means to be a person online. A person with friends, with contacts, with enemies, with multiple personas and surfaces and ambitions and these user agents of the social web need to understand that, though we live in many distinct places on the web and interact with many different services, that we as people still have one unified viewport through which we understand the world.

Until social networks understand this reality and start to adapt to it, the problem that Dave is describing is only going to continue to get worse for more and more people until truly, the problem of social network fatigue will spread beyond social geeks and start cutting into the bottom lines of companies that rely on the regularity of “sticky eyeballs” showing up.

While I will always and continue to bet on the open web, we’re reaching an inflection point where some fundamental conceptions of the web (and social networks) need to change. Fortunately, if us geeks have our way, it’ll probably be for the general betterment of the whole thing.

A Bill of Righteous intent

Before the Bill of Rights for Users of the Social Web, there were various efforts at establishing clear policies or practices related to the ownership, scope and providence of so-called user data. While I can’t name them all, I might cite P3P, The Cyberspace Charter of Rights, the DigitalConsumer’s Bill of Rights and then Attention Trust afterwards. This is clearly not a new problem, but it has gained renewed prominence owing to the wide adoption and popularity of social networks.

As such, I want applaud the authors’ effort on pulling this together in a timely fashion, and offering it up to the world to discuss, improve upon, and ultimately see to its implementation.

Continue reading “A Bill of Righteous intent”

MarsEdit 2.0 is out!

I’ve been involved for many months in the MarsEdit beta list, even before Ranchero (Brent Simmons) sold it to Red Sweater Software (Daniel Jalkut). Today, after months of long work, Daniel has finally released MarsEdit 2.0.

Besides an exhaustive UI overhaul, MarsEdit now supports Flickr account access through its new Media Manager, support for the WordPress ~~ATOM~~ XML-RPC protocol for adding categories and custom code macros among other things.

Brent’s written up the release, as well as TUAW. For $30, it’s a pretty solid deal for a great piece of software.

Groups for Twitter; or A Proposal for Twitter Tag Channels

This is the post that I alluded to in my last one about Whispering Tweets. I’ll make a disclaimer right now that the title of this post is misleading and actually not about Groups for Twitter. In fact, I’m not at all convinced that groups (at least as they are commonly understood on sites like Flickr) are ultimately a good idea or a good fit for Twitter. But, I do think that there is certainly some merit to improving contextualization, content filtering and exploratory serendipity within Twitter. This is a rather messy proposal to that effect.
Continue reading “Groups for Twitter; or A Proposal for Twitter Tag Channels”

Whispering Tweets

As a preface to the post that I intend to write next, I wanted to quickly jot down an idea that I think would be useful for Twitter… it’s partly inspired by my own instinct towards openness and partly clarified by Lane Becker‘s comment about Twitter Groups (the topic of my next status):

Personally, I’m not particularly interested in being able to create groups of people I can send certain subsets of messages to. That kind of fine-grained privacy management stuff drives me crazy on sites like Vox. Maybe I’m old-skool, but it feels like people in that environment are all about what they’re hiding, not what they’re sharing, and I prefer sharing. Hiding inhibits usage and growth, and it’s lame like high school. Don’t do it.

Emphasis added.
So it’s interesting that Twitter went with a binary model of privacy — either you have it or you don’t. Sure, you can direct message folks, but in terms of your complete timeline, either the world knows what’s up with you or they don’t. This is certainly straightforward and easy to grok, but doesn’t really allow for a third option, which would be a form of conservative promiscuity: a very public timeline with support for statuses that can only be seen by your innermost circle (or even just yourself).

The first step would be to set up a “whisper circle” or “inner circle” that will receive your whispers. This leaves you free to maintain a public timeline while adding the ability to restrict at least some of what you’re doing to a small, and more intentional, audience.

N. B.: You would only get one “inner circle” to start. For real private messaging circles, you really should just use email or Pownce. As far as I’m concerned, use the best tool for the job. This proposal is being made with the knowledge that many people would be interested in having personal d-lists or buddy sets like Pownce, but I’m defying that out of concern that overloading Twitter with this kind of management functionality would turn Twitter into something it’s not and wasn’t intended to be — which is a replacement for email in 140 character chunks.

I propose a very simple syntax for these kinds of messages: just begin your message with a bang (!) and then type your message as usual (yes, I do realize the irony in using the exclamation point for whispering). An example:


!psst... I'm whispering...

This status will only show up in the timelines of those friends who have been added to your inner circle. It will not show up in any public timelines. To reply to a whisper with a whisper, one of my friends could use either:

!@factoryjoe I can hear you. or @factoryjoe !I can hear you.

In either case, the use of an @reply to my whisper should not betray my confidence and would guarantee that I’d get the response in my replies. Like private tweets, only my inner circle at the time that I sent the message would be able to see my “whisper stream”.

I should also note that the name “whisper” comes from IRC lingo. It will make sense why I’m using both this syntax and this name in my next status on Twitter Channels — and, as an old Dodgeball user, the use of the bang to preface a message has been done before.

For now I’m curious about your thoughts on the usefulness of this proposal. Again, it’s incomplete without my next post, but as a simple protocol and as a way to bring back some folks who have gone private to living in the sunlight again, I thought I would offer it up for feedback.

Keynote Template for laying out iPhone apps

November 9, 2008. I’ve updated my template to include the 3G iPhone and to support better layering on individual slides. Now available on its own page.

Blake Burris reminded me that during iPhoneDevCamp I had created a simple Keynote template for laying out flows for iPhone apps, similar to the approach I took in developing exPhone using a Keynote document to do the basic wireframing and page layout design.

Four states come with this template, and can be seen in the figure above. Go ahead and download it and lemme know what you think — if this is useful. And, of course, you’ll need Keynote to make use of this.

WordPressMU: Making a smart platform choice

I recently engaged in an interesting discussion with a client about their choice of platform technology for their website and community build-out. Their current website is built in .NET and they’re getting to the point where things are about to start getting set in stone in terms of scaling and overall architecture and it kinda freaked me out that they’d continue down this path using a platform that I think offers little when it comes to organic community-building or much in the way of “doing web things right”.

I decided I’d write up my arguments for switching platforms in the hopes that I might test my thinking and in the process persuade our client to move to a more community-forward platform.

Continue reading “WordPressMU: Making a smart platform choice”

The story of exPhone.org

At FOO Camp, we held a session on Green Code and discussed various tactics for reducing power consumption by reducing (primarily) CPU cycles through wiser platform decisions and/or coding practices.

Somewhere in the discussion we brought up the impending launch of the iPhone and it occurred to me that there really wasn’t any substantive discussion being had about what to do with the many thousands of cell phones that would be retired in favor of newer, shinier iPhones.

Thus the seed for exPhone.org took root and began to germinate in my mind — as something simple and feasible that I could create to raise awareness of the issue and provide actionable information for busy people who wanted to do the right thing but might not want to wade through the many circuitous online resources for wireless recycling.

I had a couple constraints facing me: first, I needed to get this done while Tara was traveling to Canada as I wanted it to be an [early} surprise birthday present. Second, I needed to get it done before iPhoneDevCamp so I could leverage the event to promote the site. And third, I had other competing priorities that I really needed to focus on.

I went about designing the site in Keynote (my new favorite design tool), relying heavily on inspiration from Apple’s Environment section. I did a bunch of research and posted a lot of links to a Ma.gnolia group (in lieu of a personal set) and created a Flickr group at the same time. I of course also registered the associated Twitter account.

As I went about developing the site, I felt that I wanted to capture everything in a single page — and make it easy for printing. However, I brought my buddy Alex Hillman into the project to help me with the trickier PHP integration bits (his announcement) and he convinced me that multiple pages would actually be a better idea — not to mention compatible with my primary purpose of encouraging sustainable behavior! — and so we ended up breaking the content into three primary sections: Preparation, Donation and Recycling.

We riffed back and forth in SVN and things started to solidify quickly and we quickly realized that we should make the site more social and interactive. And, rather than build our own isolated silos, we decided we’d pull in photos from Flickr, bookmarks from Ma.gnolia and Delicious and use the groups functionality on Flickr and Ma.gnolia. This meant Alex simply had to toss the feeds into Yahoo! Pipes, dedupe them and then funnel the results in a SimplePie aggregator on our end to output the resultant feeds. It turned out that Pipes was, for some reason, not as reliable as we needed and so Alex ripped them out and ended up bumping up SimplePie’s caching of the direct feeds.

Alex put in extra effort on the Flickr integration side, creating an exPhone user account on Flickr and setting up email posting to make it super simple to get your photos of your exphones on to the site. All you have to do is take a photo of your exphone and email it to myexphone@exphone.org with a subject like this: tags: exphone, ‘the make and model of your phone’ (yes, the make and model should be in single quotes!). We’re kinda low on photos on there, so we’d love for you to contribute!

Lastly, I’ve gotta give props to The Dude Dean for his SEO tips. I’m typically not a fan of SEO, but I think when applied ethically, it can definitely help you raise your relevance in search engine results. We’re nowhere in sight, but I’d love to get up in the cell phone recycling results.

I’ve written this up primarily to demonstrate an evolving design process (Keynote to HTML to SVN prototyping to iterative launch) and the use of existing technology to build a simple but rich web application. By leveraging web services via various APIs and feeds, Alex and I were able to build a “socialized” site will little original development where most of our efforts were focused on content, design and behavior. I also made sure to mark up the site with microformats throughout making it trivial to add the organizations I mentioned to your address book or reuse the data elsewhere.

I like the idea of “disposable web apps” or “single purpose apps” that provide useful information, useful functionality or simply reuse existing materials in a novel or purposeful way. I’m also thrilled that Alex and I cobbled this thing together from scratch in a matter of three days. Yeah, it’s not a long-term, high value proposition, but it was great fun to work on and is something concrete that came out of that discussion at FOO Camp.

I of course welcome your thoughts and feedback and invite you to add your own stories, links or photos to the site!

What is a DevCamp?

$DevHouse + BarCamp = DevCamp$

While the event is still fairly fresh in my mind, I wanted to take a moment to extract some of the elements that I think made iPhoneDevCamp such a success. I’d like to put down my thoughts on how others can emulate our model towards yet another extension of the community-run, grassroots-driven event known as BarCamp — into a new style of event that shall be called DevCamp^*.

You’ll note that in the original logo deliberations for iPhoneDevCamp I was very intentional about not including iPhone-specific artwork in the mark, instead choosing something more generic to the idea of building or construction. Fortunately Louie Mantia pitched in and was able to help me refine some of the ideas that I had and we ended up with the logo above — which you can download in vector form.

Anyway, getting back to the event itself…

First and foremost, the event set out to capture the spirit of four successful event models before it: SuperHappyDevHouse, BarCamp, Mash Pit and Mac Hack. It helped a great deal to have had experience running those events before and we relied on our collective instincts to keep the event flowing and ensuring that the participants were both enjoying themselves and contributing to the overall atmosphere of the event.

Equally important in the success of the event were the people involved. It was a rare privilege to work with such dedicated and passionate folks and I really can’t say enough how much the model of selflessness Raven Zachary, Christopher Allen, Dominic Sagolla, Blake Burris, Whurley, Jerry Murray and countless others portrayed over the weekend. First time participants eagerly volunteered their energies to improving the event for others in incremental but crucial ways. In all my experiences with BarCamps, DevHouses and DevCamps, the lesson is consistently that these events are all about the people who come together for each other — and go out of their way to improve the experience of their fellow campers.

It’s truly remarkable to see, but I’ve seen it over and over again and I think it’s at the heart of what’s been called the “Spirit of BarCamp“. iPhoneDevCamp was no different and carried forth a tradition that’s come to define our community and the events that we host.

Moving right along…

An essential aspect of this event, like the first BarCamp, was implicitly “embracing the chaos” as we like to say. The first BarCamp was organized in six days and catered to nearly 300 people. iPhoneDevCamp was planned in only three weeks and catered to nearly 400 (if not more). We were able to cobble together an incredible venue stemming from a simple tweet. We pulled in over forty sponsors who provided. When Raven originally put out the call to Whurley and me about throwing this event, we had no idea how it might turned out — and embracing that uncertainty and being transparent about our progress lead us to be open to the twists and turns along the way that ultimately resulted in an incredibly worthwhile experience.

In fact, Christopher Allen’s participation didn’t materialize into much later into the event planning process. His desire to rekindle aspects of the original Mac Hack that he chaired in 1993 lead us to step back and encourage Chris to take the reigns and bring his experience to bear. Sure enough, he did a fantastic job of guiding the Hack-a-thon and presiding as master of ceremonies. He was able to deftly get people on the same page and describe how we were to work with one another and really join in the spirit of collaboration and learning.

It was this aspect of education that I hoped would resonate most with participants — and that with an open atmosphere where no question was off limits, we’d see some really interesting and inspiring thinking about how to embrace the constraints of the iPhone as an opportunity palette — and to really push what might seem conventionally possible with just a cell phone with an internet connection and a web browser.

I would argue that it was the imposition of external and topical constraints that lead to such enormous focus and productivity. I’d add to that the utter necessity of having a widely diverse assortment of skilled participants in attendance in order to be able to approach problems from multiple perspectives and skillsets and to not accept simple technical limitations as barriers to executing on a vision. As Kent Bye put it:

Again, I think this underscores my point that Diversity for the sake of Diversity is a good thing, simply because it enriches the fabric of the intelligence available for solving problems in new and unexpected ways. It’s no surprise that Tilt, one of the favorite apps of the camp, was developed by a small but diverse team made up of a game designer, an artist, a couple developers and a documentary filmmaker.

So the best design pattern that I would extract from this event comes, historically, from Chris Allen’s experience at Mac Hack and deserves something of a brief retelling:

On Saturday morning, the organizers were huddled in the ops room reviewing how to most appropriately award the incredible schwag our sponsors had donated. We had a bunch of iPod and iPhone add-ons, a number of tchotchkes and other ephemera, but we also had a couple iPhones, a couple Adobe Creative Suite Design Premium packs and various other top quality prizes… but we wanted to make sure that we had an equitable way to distribute the prizes. We started brainstorming:

“We could do a raffle.”

“We could have a hack contest for best app.”

Chris Allen broke into the discussion and told us that instead what they used to do at Mac Hack was reward participation and helpfulness. He proposed that staff get 100 or so total “special tickets” that we’d pass out throughout the event to people who were being the most helpful, the most constructive or generally contributing something to the event that didn’t necessarily directly benefit themselves. These special tickets were the ones that would be used for the big prizes drawing — the iPhones and Creative Suites — and the regular tickets would be dispensed as people arrived as an incentive for sticking around for the entire event.

By focusing on helpfulness and enculturating a spirit of coopetition, we avoided zero-summing the event by encouraging and refocusing energy on sharing, co-educating and building things collaboratively. Eventually people were having so much fun doing pure experimentation and hacking that they forgot all about the prize tickets… providing the perfect opportunity to swoop in and reward their participation. All in all, this approach worked extremely well and is a pattern, again, that I think should survive iPhoneDevCamp and carry forth into other such DevCamps.

To bring this all together — what I’m most proud of out of this event is how it brought people together to solve (or at least hack on) some pretty challenging and vexing problems and to do so with utter abandon, wearing one’s passion on her or his sleeve. It was an opportunity to learn in an open environment where diversity and raw talent were at a premium. There was no room for posturing or pretentiousness. And I think for folks not familiar with the camp community, like Michelle Quinn of the LA Times, this was a novelty and not something that she’s used to at conferences or events.

And I think it’s a testament to those involved and those who helped organize the event that we’ve set the bar exceedingly high for subsequent iterations. Like BarCamp and SuperHappyDevHouse before it, DevCamp offers a free, compelling, low-cost event model for organizing people around their passions. While there is already talk of subsequent iPhoneDevCamps, there is also interest in extending the model already. I’m excited to see how people can take this original design and stay true the values of openness, diversity, education, and the passionate pursuit of ideas and expertise.

DevCamp Miami came before Raven’s creation of the iPhoneDevCamp name. I believe Raven coined the name independent of the prior event but seems like a good idea to extend the name outward, while we have momentum.