Creating Open Profiles .:. kentbrewster.com

If you're reading this, chances are pretty good you have an online profile. Unless you're fantastically self-disciplined and all of your profile information is served by a single FOAF object which lives on a server in your basement--in which case you're a virtual hermit--there are several branches of "you" out there already, all constantly trying to strangle each other in the endless quest for search rankings and mindshare.

What I Want

  • To create, update, and share one (and only one!) instance of my public profile information--including contacts, status, location, and so forth--and serve it up so anyone who asks can see it with a minimum of fuss.
  • To delegate the right to update certain branches of my profile to agencies that I trust, such as MyBlogLog or Twitter.
  • To reserve administrative rights--including create, read, update, and delete--over the root of the profile.

That last is most important. For a while now I've been hearing about various "data portability" initiatives, most of which will only allow you to make a copy of some small subset of the current state of your profile. Everything else--including historic transactions and top-secret personal information--remains online, per the terms of the TOS you ignored when you first joined up.

Remember, if you can't delete it, it's not portable.

Narrowing the Scope

Okay, so ... what do I want it to do that I can accomplish myself? Simple stuff, mostly:

  • I want interested people to be able to hit a single url, http://foo.com/myid, and get back a JSON object containing my complete profile. If I add a callback to the url, http://foo.com/myid/callback, I want it to come back as JavaScript, properly wrapped for use with the SCRIPT tag hack. (Oh, and no screwing around with arrays of callback functions and the like; please give me the callback inside the return, like Pipes does.)
  • When I'm signed in, I want to see my public profile in a textarea and make changes that instantly update the whole thing. None of this hand-holding nonsense; I want the bare metal, please, and if I want to delete it, I want to delete it.
  • I also want a private object, consisting of nothing but key-value pairs. Each key will exactly match the branch of my main object I want others to be able to edit; each value will be the password I expect them to submit to make changes.
  • When one of my outside agents--Fireeagle, for example--makes a POST to my profile, I want it to check for a key-value match in my private object. If the agent knows the password, I want my profile to allow it to update the validated branch object.

A First Half-Blind Stab

To pull this off, I needed something big, fast, powerful, and free. Google's Application Engine was immediately interesting to me because of the single most impressive developer demo I've ever seen, Brett Slatkin's Introducing Google App Engine. Everything Brett showed in the video looked completely doable, and when I tried it out, by golly, it was. (I'm still looking at it, and cursing the fact that I can't copy and paste directly from the code in the video. Boy, would that ever be cool.)

Thanks to Steve Souders, late of Yahoo but recently moved to the big G, I've acquired early access. As of this writing App Engine still in closed beta; keep an eye on their blog for updates.

Can we See the Source Code, Please?

Nawp, sorry, not yet. It's like this: Open Profile is my first Python program, ever. I can see dozens of places where it sucks, and I'm not even remotely qualified to tell if something written in Python sucks or not. I'm in conversations right now with a Python expert; once I get it vetted I will credit him appropriately and open-source everything.

This thing would definitely work on a non-Google box, with the addition of user authentication plus minor mods to make it talk to MySQL, so if you wanted to put it on that server in the basement and own it completely, you could.

View My Profile

Here's my public profile on http://exo.appspot.com/kentbrew/ping:

The base URL is http://exo.appspot.com/kentbrew; the callback I've wrapped it in is ping. If you omit the callback, you'll get a pure JSON object, which your browser may or may not be able to handle inline.

As you can see, I have two branch objects in my profile, foo, containing the last value you guys put in, and status, containing an array of objects that you theoretically can't monkey with. Using my private object, which you don't see here, I've granted permission to edit object foo:

Owner: Object: Password:
New Value:

Confused? Try "boing", {"clank":"ding"}, or {"testing":[1, 2, 3]} to start.
Reload my public profile to see your changes.

Things to Do and Notice

  • Enter some valid JSON for the contents of the object you want to update. Be sure to quote your strings and bracket your objects and arrays.
  • You'll see an intentionally sparse success-or-failure message go by when you submit this. We don't want to give the bad guys any hints about what they might be doing wrong.
  • If you see the Success message, use the Reload link to see your changes serve up.
  • This should work for anyone, signed in to Google or not, because I've given you my root object name, my branch object name, and its password.
  • There's no callback option for the update function, since it's only supposed to be POSTed.
  • You should not be able to monkey around with my status object, since you don't know the password.
  • If you head over to exo.appspot.com and create your own object with an open branch, you ought to be able to update it from here.
  • Right, updates are not even remotely secure. This could be mitigated somewhat with https ... but please don't use this form for anything mission-critical.

Directions for Future Development

  • I can see an approach like this lending itself quite nicely to decentralized social networking. If I have a list of contacts and they each have their own open profiles and they all point back to me in a contacts array, we can deduce the same sorts of relationships we find in FOAF or XFN.
  • Unlike FOAF or XFN, delegated update rights are built in. Any service that cares could ask me to put up a branch object and give them a password.
  • Next up, I'm going to see if I can hook up Twitter and get some real status updates in there.

How It Feels So Far

Even though it's in an embryonic stage and nobody at all is paying attention, I like it.

I'm creating data. I'm authorizing access. I'm giving out passwords to my agents, not begging them from big faceless companies. Unlike all those other Web profiles, which could change or vanish at the whim of their hosting companies, this one feels powerful, like I own the thing, instead of it owning me.

Comments from before Disqus:

Krispijn .:. 2008-06-29 14:27:04
This is an interesting idea and reaction from Isaac, although I'm not tech savvy enough to follow all the ins and outs of it. I do see the need for a central profile I can manage myself and that can be used to update different sites at once (or am I already missing your point?).

I also wonder if in your opinion the new beta feature from MyBlogLog called Connector is part of the solution, of part of the locking up of profile data?
Kent Brewster .:. 2008-05-07 07:31:08
Thanks, Isaac; replies like these are what keep me going.

I built Open Profiles on Google's Application Engine because I wanted to try it out. Amazon's S3/EC2 was also an option, but that would have cost actual money, and "spent no additional money of my own" is usually one of my requirements. There's no reason why it couldn't be turned into a spec and run on anything.

With regards to business plans: given the amount of who-what-where information available through two-way connections from my public contact list to other public contact lists, I'm betting advertising would work. If the New York Times wanted to advertise on your profile--and potentially show up wherever you make a public mark on the Internet--how much would you charge?
Isaac Z. Schlueter .:. 2008-05-06 22:41:22
With this list of "wants", you've touched on perhaps the best way that a hacker could potentially add value to the world right now, in my opinion. But I don't think a google app is going to solve the problem for real.

There are A LOT of aspects of profile and contact management that suck right now. They suck hard, they suck for everyone, and most people are considerably less skilled than you at Python. App engine doesn't give them the tools they need to solve this problem. They have cell phones, they have profiles on a few social networking sites, they have their email and their IMs. Grandmothers and 6-year-olds have these toys. They use them a lot. The old telephone has transformed into a multidimensional web of networks, chopped into 17 different pieces that can't talk to one another properly.

Everyone I know bitches about this. Just ask anyone with a BlackBerry what hoops they have to jump through when someone changes their email address. I'm guessing they have to make that change in at least 3 places. *One* is too many, in my opinion.

As I see it, there isn't anyone out there with the right combination of motivations to get it done right. I'm not sure what the ideal business plan would be, but with this much suckitude effecting everyone, there's a lot of wealth to be created. Where there's wealth to be created, there's money hiding somewhere.

Google and Yahoo have resources. Yahoo has the data. MySpace and Facebook have done a good job leveraging the data they have. Plaxo has made an interesting stab at linking things together. Twitter and Last.fm and LinkedIn and other social networking sites aren't even trying to solve this problem; they have other fish to fry. The many varied cellphone/im/addressbook sync agents are a bandaid. OpenID is a bicycle; we need an airplane.

A single-site profile and closed social graph should one day seem as ridiculous as serving web pages over FTP. We should look back on the old days of web2.0, and laugh about what a pain it was to have to fill in your profile and import your friendlist from your email or IM account. It'll be a badge of pride among elite hackers to have done this, like BBS usage or a 5-digit IRC number.

Yahoo could do this. But they won't, because they already have a giant infrastructure for user profile data, and they don't gain anything from opening it up.

The platform should be open to everyone who wants to use it, but individual data and relationships should be managed by the user, and not make them have to think any harder than the average IM or email client. It should make it easy for strangers to contact me, but make spam almost impossible. If I change my phone number, my mom's phone should know about it so she doesn't have to.

I talk about this idea to anyone who seems even remotely interested, in the hopes that they'll beat me to solving it. I very much want to use this system, and it's going to take a metric ton of work to solve it in a real way.

I guess what I'm saying is, Please, Kent, don't stop hacking on this. Please invent something good so that I don't have to walk away from benefits and security in a year or two. Tell everyone you know about this, and ask them to improve on it if they can. Or, at the very least, be prepared to get a call from some random startup some day claiming that they're going to fix contact management, and asking about that Google app you whipped up back in the middle of 2008.

Like so many problems in our technological world, Unix got it right, in its limited way, and it just hasn't been adapted for the web yet.