Digital Identity – Page 6

Coverflow for People

Ever since Apple bought Coverflow, I thought that it would make an awesome interface for browsing people. In fact, I had previously designed “people in the browser” for Flock to look something like this in the early days:

Of course, at the time, the design required a few things that we still lack, namely: 1) bigger default personal photos or avatars, 2) ubiquitous universal identifiers for people (this was before OpenID) 3) and free access to public data about people, typically found at the end of those identifiers.

Anyway, CoverFlow for people is something that I think could be a very powerful way of revealing “the ghosts in the machine” — across Leopard — or in interfaces generally. Imagine this kind of view showing up in Mail.app, Adium, iChat… where your friends, family and the rest get to update their own user pictures on a whim, and set their status and contact preferences in a way that visually makes sense. The new integrated Gtalk features in Gmail seem to be prioritizing your “Top 250”, so this is also something that could be added to the People Coverflow API without much trouble in order for the interface to scale accordingly. Anyone able to hack up a demo of this idea?

hCard for OpenID Simple Registration and Attribute Exchange

One of the many promises of OpenID is the ability to more easily federate profile information from an identity provider to secondary consumer applications. A simple example of this is when you fill out a basic personal profile on a new social network: if you’ve ever typed your name, birthday, address and your dog’s name into a form, why on earth would you ever have to type it again? Isn’t that what computers are for? Yeah, I thought so too, and that’s why OpenID — your friendly neighborhood identity protocol — has two competing solutions for this problem.

Unfortunately, both Simple Registration (SREG for short) and its potential successor Attribute Exchange (AX) go to strange lengths to reinvent the profile data wheel with their own exclusive formats. I’d like to propose a vast simplification of this problem by adopting attributes from the vCard standard (also known as RFC2426). As you probably know, it’s this standard that defines the attributes of the hCard microformat and therefore is exceptionally appropriate for the case of OpenID (given its reliance on URLs for identifiers!).

Very quickly, I’ll compare the attributes in each format so you get a sense for what data I’m talking about and how each format specifies the data:

Attribute	SREG	AX	vCard
Nickname	`openid.sreg.nickname`	`namePerson/friendly`	`nickname`
Full Name	`openid.sreg.fullname`	`namePerson`	`n (family-name, given-name)` or `fn`
Birthday	`openid.sreg.dob`	`birthDate`	`bday`
Gender	`openid.sreg.gender`	`gender`	`gender`
Email	`openid.sreg.email`	`contact/email`	`email`
Postal Code	`openid.sreg.postcode`	`contact/postalCode/home`	`postal-code`
Country	`openid.sreg.country`	`contact/country/home`	`country-name`
Language	`openid.sreg.language`	`pref/language`	N/A
Timezone	`openid.sreg.timezone`	`pref/timezone`	`tz`
Photo	N/A	`media/image/default`	`photo`
Company	N/A	`company/name`	`org`
Biography	N/A	`media/biography`	`note`
URL	N/A	`contact/web/default`	`URL`

Now, there are a number of other other attributes beyond what I’ve covered here that AX and vCard cover, often overlapping in the data being described, but not in attribute names. Of course, this creates a pain for developers who want to do the right thing and import profile data rather than having folks repeat themselves yet again. Do you support SREG? AX? hCard? All of the above?

Well, regular people don’t care, and shouldn’t care, but that doesn’t mean that this isn’t a trivial matter.

Instead, the barriers to doing the right thing should be made as low as possible. Given all the work that we’ve done promoting microformats and the subsequent widespread adoption of them (I’d venture that there are many million hcards in the wild), it only makes sense to leverage the upward trend in the adoption of hcard and to use it as a parallel partner in the OpenID-profile-exchange dance.

While AX is well specified, hCard is well supported (as well as well-specified). While AX is extensible, hCard is too. Most importantly, however, hcard and vcard is already widely supported in existing applications like Outlook, Mail.app and just about every mobile phone on the planet and in just about any other application that exchanges profile data.

So the question is, when OpenID is clearly a player in the future and part of that promise is about making things easier, more consistent and more citizen-centric, why would we go and introduce a whole new format for representing person-detail-data when a perfectly good one already exists and is so widely supported?

I’m hoping that reason and sense will prevail and that OpenID and hCard will naturally come together as two essential building blocks for independents. If you’re interested in this issue, please blog about it or express your support to specs@openid.net. I think the folks working on this spec need to hear from folks who make, create, build or design websites and who recognize the importance and validity of betting on, and support and adopting, microformats.

OpenSocial and Address Book 2.0: Putting People into the Protocol

I wonder if Tim O’Reilly knows something that he’s not telling the rest of us. Or maybe he knows something that the rest of us know, but that we haven’t been able to articulate yet. Who knows.

In any case, he’s been going on about this “Address Book 2.0” for awhile, and if you ask me, it has a lot to do with Google’s upcoming announcement of a set of protocols, formats and technologies they’ve dubbed OpenSocial.

[Aside: I’ll just point out that I like the fact that the name has “open” in it (even if “open” will be the catchphrase that replaces the Web 2.0 meme) because it means that in order to play along, you have to be some shade of open. I mean, if Web 2.0 was all about having lots of bits and parts all over the place and throwing them together just-in-time in the context of a “social” experience, then being “open” will be what separates those who are caught up and have been playing along from those who have been asleep at the wheel for the past four years. Being “open” (or the “most” open) is the next logical stage of the game, where being anything other than open will be met with a sudden and painless death. This is a good thing™ for the web, but remember that we’re in the infancy of the roll-out here, and mistakes (or brilliant insights) will define what kind of apps we’re building (or able to build) for the next 10 years.]

Let me center the context here. A few days ago, I wrote about putting people in the protocol. I was talking about another evolution that will come alongside the rush to be open (I should note that “open” is an ongoing process, not an endpoint in and of itself). This evolution will be painful for those who resist but will bring great advantage to those who embrace it. It’s pretty simple and if you ask me, it lies at the heart of Tim’s Address Book 2.0 and Google’s OpenSocial; in a word, it’s people.

Before I get into that, let me just point out what this is not about. Fortunately, in his assessment of “What to Look for from Google’s Social Networking Platform“, David Card at Jupiter Research spelled it out in blindingly incorrect terms:

As an analyst who used to have the word “Unix” on his business card, I’ve seen a lot of “open” “consortia” fail miserably. Regular readers know my Rule of Partnership: For a deal to be important, two of the following three must occur:

– Money must change hands
– There must be exclusivity
– Product must ship

“Open” “consortia” aren’t deals. That’s one of the reasons they fail. The key here would be “Product must ship.”

This completely misses the point. This is why the first bubble was so lame. So many people had third-world capital in their heads and missed what’s new: the development, accumulation and exchange of first-world social capital through human networks.

Now, the big thing that’s changed (or is changing) is the emphasis on the individual and her role across the system. Look at MyBlogLog. Look at Automattic’s purchase of Gravatar. Look at the sharp rise in OpenID adoption over the past two years. The future is in non-siloed living man! The future is in portable, independent identities valid, like Visa, everywhere that you want to be. It’s not just about social network fatigue and getting fed up with filling out profiles at every social network you join and re-adding all your friends. Yeah, those things are annoying but more importantly, the fact that you have to do it every time just to get basic value from each system means that each has been designed to benefit itself, rather than the individuals coming and going. The whole damn thing needs to be inverted, and like recently rejoined ant segments dumped from many an ant farm, the fractured, divided, shattered into a billion fragments-people of the web must rejoin themselves and become whole in the eyes of the services that, what else?, serve them!

Imagine this: imagine designing a web service where you don’t store the permanent records of facets of people, but instead you simply build services that serve people. In fact, it’s no longer even in your best interest to store data about people long term because, in fact, the data ages so rapidly that it’s next to useless to try to keep up with it. Instead, it’s about looking across the data that someone makes transactionally available to you (for a split second) and offering up the best service given what you’ve observed when similar fingerprint-profiles have come to your system in the past. It’s not so much about owning or storing Address Book 2.0 as much as being ready when all the people that populate the decentralized Address Book 2.0 concept come knocking at your door. Are you going to be ready to serve them immediately or asking them to fill out yet another profile form?

Maybe I’m not being entirely clear here. Admittedly, these are rough thoughts in my head right now and I’m not really self-editing. Forgive me.

But I think that it’s important to say something before the big official announcement comes down, so that we can pre-contextualize this and realize the shift that’s happening even as the hammer drops.

Look, if Google and a bunch of chummy chums are going to make available a whole slew of “social graph” material, we had better start realizing what this means. And we had better start realizing the value that our data and our social capital have in this new eco-system. Forget page views. Forget sticky eyeballs. With OpenID, with OAuth, with microformats, with, yes, with FOAF and other formats — hell with plain ‘ol scrapable HTML! — Google and co. will be amassing a social graph the likes of which has yet to be seen or twiddled upon (that’s a technical term). It means that we’re [finally] moving towards a citizen-centric web and it means great things for the web. It means that things are going to get interesting, for Facebook, for MySpace, for Microsoft, for Yahoo! (who recently closed 360, btw!) And y’know, I don’t know what Spiderman would think of OpenSocial or of what else’s coming down the pipe, but I’m sure in any case, he’d caution that, with great power comes great responsibility.

I’m certainly excited about this, but it’s not all about Google. Moreover, OpenSocial is simply an acknowledgment that things have to (and have) change(d). What comes next is anyone’s guess, but as far as I’m concerned, Tim’s been more or less in the ballpark so far, it just won’t necessarily be about owning the Address Book 2.0, but what it means when it’s taken for granted as a basic building block in the vast clockwork of the open social web.

And you wonder why people in America are afraid of the Internet

Ladies and gentlemen, I would like to present to you two exhibits.

Here is Exhibit A from today’s International Herald Tribune:

In contrast (Exhibit B) we have the same exact article, but with a completely different headline:

Now, for the life of me, I can’t figure out how the latter is a more accurate or more appropriate title for the article, which is ostensibly about Google’ acquisition of Jaiku.

But, for some reason, the editor of the NY Times piece decided that it would — what? — sell more papers? — to use a more incendiary and moreover misleading headline for the story.

Here’s why I take issue: I’m quoted in the article. And here’s where the difference is made. This is how the how the article ends:

“To date, many people still maintain their illusion of privacy,” he said in an e-mail message.

Adapting will take time.

“For iPhone users who use the Google Maps application, it’s already a pain to have to type in your current location,” he said. “‘Why doesn’t my phone just tell Google where I am?’ you invariably ask.”

When the time is right and frustrations like this are unpalatable enough, Mr. Messina said, “Google will have a ready answer to the problem.”

Consider the effect of reading that passage after being lead with a headline like “Google’s Purchase of Jaiku Raises New Privacy Issues” versus “Will Google take the mobile world of Jaiku onto the Web?” The latter clearly raises the specter of Google-as-Big-Brother while ignoring the fallacy that privacy, as people seem to understand it, continues to exist. Let’s face it: if you’re using a cell phone, the cell phone company knows where you are. It’s just a matter of time before you get an interface to that data and the illusion that somehow you gave Google (or any other third party) access to your whereabouts.

I for one do not understand how this kind of headline elevates or adds to the discourse, or how it helps people to better understand and come to gripes with the changing role and utility of their presence online. While I do like the notion that any well-engineered system can preserve one’s privacy while still being effective, I contend that it’s going to take a radical reinterpretation of what we think is and isn’t private to feel secure in who can and can’t see data about us.

So, to put it simply, there are no “new” privacy issues raised by Google’s acquisition of Jaiku; it’s simply the same old ones over and over again that we seem unable to deal with in any kind of open dialogue in the mainstream press.

Data capital, or: data as common tender

Wikipedia states that Legal tender … is payment that, by law, cannot be refused in settlement of a debt denominated in the same currency. Currency, in turn, is a unit of exchange, facilitating the transfer of goods and/or services.

I was asked a question earlier today about the relative value of open services against open data served in open, non-proprietary data formats. It got me thinking whether — in the pursuit of utter openness in web services and portability in stored data — that’s the right question. Are we providing the right incentives for people and companies to go open? Is it self-fulfilling or manifest destiny to arrive at a state of universal identity and service portability leading to unfettered consumer choice? Is this how we achieve VRM nirvana, or is there something missing in our assumptions and current analysis?

Mary Jo Foley touched on this topic today in a post called Are all ‘open’ Web platforms created equal? She asks the question whether Microsoft’s PC-driven worldview can be modernized to compete in the network-centric world of Web 2.0 where no single player dominates but rather is made up of Best of Breed APIs/services from across the Web. The question she alludes to is a poignant one: even if you go open (and Microsoft has, by any estimation), will anyone care? Even if you dress up your data and jump through hoops to please developers, will they actually take advantage of what you have to offer? Or is there something else to the equation that we’re missing? Some underlying truism that is simply refracting falsely in light of the newfound sexiness of “going open”?

We often tell our clients that one of the first things you can do to “open up” is build out an API, support microformats, adopt OpenID and OAuth. But that’s just the start. That’s just good data hygiene. That’s brushing your teeth once a day. That’s making sure your teeth don’t fall out of your head.

There’s a broader method to this madness, but unfortunately, it’s a rare opportunity when we actually get beyond just brushing our teeth to really getting to sink them in, going beyond remedial steps like adding microformats to web pages to crafting just-in-time, distributed open-data-driven web applications that actually do stuff and make things better. But as I said, it’s a rare occasion for us because we’ve all been asking the wrong questions, providing the wrong incentives and designing solutions from the perspective of the silos instead of from the perspective of the people.

Let me make a point here: if your data were legal tender, you could take it anywhere with you and it couldn’t be refused if you offered to pay with it.

Let me break that down a bit. The way things are today, we give away our data freely and frequently, in exchange for the use of certain services. Now, in some cases, like Pandora or Last.fm, the use of the service itself is compelling and worthwhile, providing an equal or greater exchange rate for our behavior or taste data. In many other cases, we sign up for a service and provide basic demographic data without any sense of what we’re going to get in return, often leaving scraps of ourselves to fester all across the internet. Why do we value this data so little? Why do we give it away so freely?

I learned of an interesting concept today while researching legal tender called “Gresham’s Law” and commonly stated as: When there is a legal tender currency, bad money drives good money out of circulation.

Don’t worry, it took me a while to get it too. Nicolas Nelson offered the following clarification: if high quality and low quality are forced to be treated equally, then folks will keep good quality things to themselves and use low quality things to exchange for more good stuff.

Think about this in terms of data: if people are forced (or tricked) into thinking that the data that they enter into web applications is not being valued (or protected) by the sites that collect the data, well, eventually they’ll either stop entering the data (heard of social network fatigue?) or they’ll start filling them with bogus information, leading to “bad data” driving out the “good data” from the system, ultimately leading to a kind of data inflation, where suddenly the problem is no longer getting people to just sign up for your service, but to also provide good data of some value. And this is where data portability — or data as legal tender — starts to become interesting and allows us to start seeing around through the distortion of the refraction.

Think: Data as currency. Data to unlock services. Data owned, controlled, exchanged and traded by the creator of said data, instead of by the networks he has joined. For the current glut of web applications to maintain and be sustained, we must move to a system where people are in charge of their data, where they garden and maintain it, and where they are free to deposit and withdraw it from web services like people do money from banks.

If you want to think about what comes next — what the proverbial “Web 3.0” is all about — it’s not just about a bunch of web applications hooked up with protocols like OAuth that speak in microformats and other open data tongue back and forth to each other. That’s the obvious part. The change comes when a person is in control of her data, and when the services that she uses firmly believe that she not only has a right to do as she pleases with her data, but that it is in their best interest to spit her data out in whatever myriad format she demands and to whichever myriad services she wishes.

The “data web” is still a number of years off, but it is rapidly approaching. It does require that the silos popular today open up and transition from repositories to transactional enterprises. Once data becomes a kind of common tender, you no longer need to lock it; in fact, the value comes from its reuse and circulation in commerce.

To some degree, Mint and Wesabe are doing this retroactively for your banking records, allowing you to add “data value” to the your monetary transactions. Next up Google and Microsoft will do this for your health records. For a more generic example, Swivel is doing this today for the OECD but has a private edition coming soon. Slife/Slifeshare, i use this and RescueTime do this for your use of desktop apps.

This isn’t just attention data that I’m talking about (though the recent announcements in support of APML are certainly positive). This goes beyond monitoring what you’re doing and how you’re spending your time. I’m talking about access to all the data that it would take to reconstitute your entire digital existence. And then I’m talking about the ability to slice, dice, and splice it however you like, in pursuit of whatever ends you choose. Or choose not to.

I’ll point to a few references that influenced my thinking: Social Capital To Show Its Worth at This Week’s Web 2.0 Summit, What is Web 2.0?, Tangled Up in the Future – Lessig and Lietaer, , Intentional Economics Day 1, Day 2, Day 3.

OAuth Core 1.0 Final Draft is out — now build stuff!

I should have pushed this post out yesterday and no latter than earlier today, but what are you gunna do, y’know?

Anyway, I spent most of the day in #OAuth with Eran, Gabe and Mark Atwood and others plotting the release of the news about our release of OAuth Core 1.0 Final Draft. This news after three previous public drafts culminating the collective effort leveraged over four months of regular meetings, intense discussions and negotiations and constantly reminding ourselves to keep the scope creep to an absolute minimum.

We overhauled the website, got the blog going (with an official press release!), some initial tumbles, added some content to the wiki and ended up with an excellent Getting Started guide and an Introduction provided by Eran.

All in all, I want to quickly point out the technologies that are making this effort possible with just a small group of admin-advocates:

Website: Mephisto
Blog: hosted WordPress
Tumblelog: Tumblr
Wiki: PBWiki
SVN Repo: Google Code
Diagrams/Logos Hosting: Flickr
Presentations Group: Slideshare
Bookmarks Group: Ma.gnolia
Chat: Pibb and Freenode IRC, Diet Pibb
Mailing list(s): Google Groups
Forums: Get Satisfaction
Document collaboration: Google Docs, Google Code/SVN
Logo design: Basecamp
Promotions: Twitter, Blogs
Events: Upcoming, Facebook
Ego tracking: Twitter Tracking, Technorati, Google Blog Search

Without this technology and how far collaborative technology has come in just two years, it wouldn’t be possible for us to be moving as fast as we are and making as much progress as we have been, consistently, with as few person-hours as we have at our disposal.

Next steps

Of course, even with this Final Draft out, we’re only getting started. There are a number of things that still need to be done, and these are a few off the top of my head (I’m maintaining my personal list here if you want to help out):

Get the logo figured out. I’ve pinged like five guys about this. Why y’all gots ta be so busy! If you have an idea, please post it to the Flickr group. I’m patient on this one though.
Implement support for OAuth! If you can, replace your proprietary API access delegation protocol with OAuth. If you don’t code (like me!) add software that you think could benefit from OAuth to the Advocacy page.
Help improve the libraries. A bunch of folks have worked on the first open source implementations of OAuth but we need more testers, more implementors and more folks to get code running in the wild.
Spread the word! This is a grassroots-lead effort and if it’s going to be successful, has to spread from the bottom up. Early reviews suggest that the spec is clear and easy to implement. If you can promote this open protocol within your organization and get it adopted, please do…! And then blog it and point me to it so I can tumbleblog it!

I’m sure there’s more that needs to be done, but this is what I got now (yes Gabe, we still have to deal with IPR… I’m on it!).

Making history visible as it happens

I’d like to close by making a point of process explicit for the benefit of those just tuning in. Two defining aspects of successful community efforts with which I’ve been involved are 1) the ability of an enthusiast to tell a story about why some idea or technology is personally meaningful to her 2) and a large body of collected wisdom, notes, drafts, paper trails, ideas, struggles and all the things that went into the final product. Math teachers force you to show your work for a reason: it’s oftentimes not the answer that’s interesting, it’s how you got there.

So, I’m making explicit my intention to be as transparent, straight-forward and forthcoming about my experiences helping to usher OAuth forward. I’ve not really done this kind of thing before, but being surrounded by brilliant and talented people seems to bring out the best in me. That and I’ve watched what’s happened in the OpenID community for over a year now and, for what it’s worth, I want to avoid getting dragged down into endless loops and debilitating scope creep. In fact I’ve not been involved with the OpenID community for months because of this kind of stuff and I want to expressly make an effort to document openly the approach we take with OAuth to see if we can’t avoid the same fate.

Cheers and congrats to all the folks who helped to make this happen. It might be a relatively minor step in terms the development of new technology today, but looking out long enough into the horizon, I think we’re adding a significantly important piece of puzzle that’s been missing for some time.

Putting people into the protocol

I really don’t like the phrase “user-centric identity” and as I struggled to name this post, I came upon Pete Rowley’s 2006 phrase the people are in the protocol.

This isn’t much different from what I used to call “people in the browser” when I was at Flock, so I’ll use it.

Anyway, as part of another post I’m working on, it seemed useful to call out what I see as the benefits to services that “put people into the protocol” or, more aptly, those services that are designed around people who tend to use more than one web service and a single identifier (like an OpenID) to represent themselves across services.

Here’s what I’ve come up with so far:

I am me, wherever I go. I may have multiple personas, facets or identities that I use online, but fundamentally, I can manage them more effectively because services are oriented around me and not around the services that I use (it would be like logging into a new user account every time you want to switch applications!).
I have access to my stuff, wherever I am. Even though I use lots of different web services, just like I use lots of desktop applications, I can always access my data, no matter where I created it or where it’s stored. And if I want to get all of my data out of a service into another one, I should be able to do so.
My friends come with me, but continue to use only the services that they chose to. If I can send email from any domain to any domain, why can’t I join one network and then add friends from any other network?
I am the master of my domain. Both literally and figuratively, I should be able to choose any identity provider to manage all my external connections to the world, including running my own, from my own domain. While remote service providers can certainly set the standards for who they allow access to their APIs, this should be done in a clear and transparent way, so that even people who host their own identity can have fair access.

There may of course be other benefits that I’m forgetting or omitting, but I think I’ve covered some of the primary ones, at least so that I continue with my other post!

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”