Relationships are complicated

Facebook | Confirm Requests

I’ve noticed a few interesting responses to my post on simplifying XFN. While my intended audiences were primarily fellow microformat enthusiasts and “lower case semantic web” types, there seems to be a larger conversation underway that I’d missed — one that both and have commented on.

In a treatise against XFN (and similarly reductive expressions of human relationships) from December of last year, Greenfield said a number of profound things:

  • …one of my primary concerns has always been that we not accede to the heedless restructuring of everyday human relations on inappropriate and clumsy models derived from technical systems – and yet, that’s a precise definition of social networking as currently instantiated.
  • All social-networking systems constrain, by design and intention, any expression of the full band of human relationship types to a very few crude options — and those static!
  • …it’s impossible to use XFN to model anything that even remotely resembles an organic human community. I passionately believe that this reductive stance is not merely wrong, but profoundly wrong, in that it deliberately aims to bleed away all the nuance, complication and complexity that makes any real relationship what it is.
  • I believe that technically-mediated social networking at any level beyond very simple, local applications is fundamentally, and probably persistently, a bad idea. From where I stand, the only sane response is to keep our conceptions of friendship and affinity from being polluted by technical metaphors and constraints to begin with.

Whew! Strong stuff, but useful, challenging and insightful.

Meanwhile, TBL defended a semi-autistic perspective in describing the future of the Semantic Web (yes, the uppercase version):

At the moment, people are very excited about all these connections being made between people — for obvious reasons, because people are important — but I think after a while people will realise that there are many other things you can connect to via the web.

While my sympathies actually lie with Greenfield (especially after a weekend getting my mom setup on Facebook so she could send me photos without clogging my inbox with 80MB emails… a deficiency in the design of the technology, not my mother mind you!), I also see the promise of a more self-aware, self-descriptive web. But, realistically, that web is a long way off, and more likely, that web is still going to need human intervention to make it work — at least for humans to benefit from it (oh sure, just get rid of the humans and the network will be just perfect — like planes without passengers, right?).

But in the meantime, there is a social web that needs to be improved, and that can be improved, in fairly simple and straight-forward ways, that will make it easier for regular folks who don’t (and shouldn’t have to) care about “data portability” and “password anti-patterns” and “portable contact lists” to benefit from the fact that the family and friends they care about are increasingly accessible online, and actually want to hear from them!

Even though Justin Smith takes another reductive look at the features Facebook is implementing, claiming that it wants to “own communications with your friends“, the reality is, people actually want to communicate with each other online! Therefore it follows that, if you’re a place where people connect and re-connect with one another, it’s not all that surprising that a site like Facebook would invest in and make improvements to facilitate interaction and communication between their members!

But let’s back up a minute.

If we take for granted that people do want to connect and to communicate on social networks (they seem to do it a lot, so much to that one might could even argue that people enjoy doing it!), what role should so-called “portable contact lists” play in this situation? I buy Greenfield’s assertion that attempts by technologists to reduce human relationships to a predefined schema (based on prior behavior or not) is a failing proposition, but that seems to ignore the opportunity presented by the fact that people are having to maintain many several lists of their friends in many different places, for no other reason than an omission from the design of the social internetwork.

Put another way, it’s not good enough to simply dismiss the trend of social networking because our primitive technological expressions don’t reflect the complexity of real human relationships, or because humans are just one of kind of “object” to be “semantified” in TBL’s “Giant Global Graph“… instead, people are connecting today, and they’re wanting to connect to people outside of their chosen “home” network and frankly the experience sucks and it’s confusing. It’s not good enough to get all prissy about it; the reality is that there are solutions out there today, and there are people working on these things, and we need smart people like Greenfield and Berners-Lee to see that solutions that enable the humanist web (however semantic it needs to be) are being prioritized and built… and that we [need] not accede to the heedless restructuring of everyday human relations on inappropriate and clumsy models derived from technical systems.

I can say that, from what I’ve observed so far, these are things that computers can do for us, to make the social computing experience more humane, should we establish simple and straightforward means to express a basic list of contacts between contexts:

  • help us find and connect to people that we’ve already indicated that we know
  • introduce us to people who we might know, or based on social proximity, should know (with no obligation to make friends, of course!)
  • help us from accidently bumping into people we’d rather not interact with (see block-list portability)
  • helping us to segment our friendships in ways that make sense to us (rather than the semi-arbitrary ways that social networks define)
  • helping us to confidently share things with just the people with whom we intend to share

There may be others here, but off the top of my head, I think satisfying these basic tasks is a good start for any social network that thinks allowing you to connect and interact with people who you might know, but who may not have already signed up for the service, is useful.

I should make one last point: when thinking about importing contacts from one context to another, I do not think that it should be an unthinking act. That is, just because it’s merely data being copied between servers, the reality is that those bits represent things much more sacred and complicated than any computer might ever be programmed to imagine. Therefore, just because we can facilitate and lower the friction of “bringing your friends with you” from one place to another doesn’t mean that it should be an automatic process and that all your friends in one place should be made to be your friends in the new place.

And regardless of how often good ol’ Mark Zuckerberg claims that the end game is to make communications more efficient, when it comes to relationships, every connection transposed from one context to another should have to be reconsidered (hmm, a great argument for tagging of contacts…)! We can and should not make assumptions about the nature of people’s relationships, no matter what kind of semantics they’ve used to describe them in a given context. Human relationships are simply far too complicated to be left up to assumptions and inferences made by technologists whose affinity oftentimes lies closer to the data than to the makers of the data.

Advertisements

Portable contact lists and the case against XFN

XFNI suppose it might come as a surprise that I’ve decided to question, if not reject, XFN as the format for expressing portable friends or contact lists. I’m not throwing out the baby in the bathwater here, but rather focusing on the problem that needs to be solved and choosing to redouble my efforts on an elegant solution that builds on existing work and implementations.

My thinking on this crystalized yesterday during the Building Portable Social Networks panel that I shared with Jeremy Keith, Leslie Chicoine, Joseph Smarr and David Recordon. I further defined my realization last night on Twitter and when Anders Conbere pinged me about a post he’d written more or less on the subject, I knew that I was on to something.

The idea itself is pretty simple, but insomuch as it reduces both complexity and helps narrow the scope of evangelism work needed to push for further adoption, I think the change is a necessary one.

→ Quite simply, contact list portability can be achieved with only rel-contact and rel-me. All the rest is gravy.

Here’s the deal: as it is, we have a pretty nasty anti-pattern that a number of us have been railing against for some time (and, as it turns out, with good friggin’ reason). As I pointed out on the panel yesterday, people shouldn’t be penalized for the fact that the technology allows them to be promiscuous with their account credentials; after all, their desire to connect with people that they know is a valid one and has been shown to increase engagement on social sites. The problem is that, heretofore, importing your list of contacts from various webmail address books required you to provide your account credentials to an untrusted third party. On top of that, your contact list is delivered as email addresses, which I call “resource deficient” (what else can you do with an email address but send messages to it or use it as a key to identify someone? URLs are much richer).

The whole mechanism for bringing with your friends to new social sites is broken.

Enter microformats and XFN

The solution we’ve been harping on for the last couple years is a web-friendly solution for marking up existing and (predominantly) public lists of friends, using 18 pre-defined rel values. WordPress supports XFN natively and is one of the primary reasons we started with WordPress as the foundation of the DiSo Project:

WordPress Add Link

Reading up on the background of XFN, you realize that one of the primary goals of XFN was simplicity. Simplicity is relative however, and you have to remember that XFN’s simplicity was in contrast to FOAF, a much denser and complex format based on RDF.

Given all the values (that is, the existing XFN terms) and the generally semantic specificity of XFN, I decided to contrast the adoption of XFN by publishers and by consumers with the competing (and more ubiquitous) solution for contact list portability (i.e. email address import).

If you use Google’s new Social Graph API and actually go looking for XFN data (for example, on Twitter or Flickr or others), you’ll find that, by and large, the majority of XFN links on the web are using either rel-contact or rel-me.

If you’re lucky, you might find some rel-friends in there, but after rel-me and rel-contact, the use of the other 16 terms falls off considerably. Compound that fact with the minor semantic distinction between “contacts” and “friends” on different sites (sites like Dopplr dispense altogether with these terms, opting for “fellow travelers”) and you quickly begin to wonder if the “semantic richness” of XFN is really just “semantic deadweight”.

And, in terms of evangelism and potential adoption, this is critical. If 16 of the 18 XFN terms are just cruft, how can we maintain our credibility, especially when arguing against the email import approach, in which there are little to no semantic descriptors at the time of import (instead, you basically get a dumb list of email addresses — with no clues whatsoever as to which addresses are “sweethearts”, “crushes”, “kin” or the like). It’s not that XFN in and of itself is bad, it’s that, when compared with the reigning tactic of email import, we look as complicated and convoluted as FOAF did. The reality is, even if it’s “heinous” to data purists or pragmatists, email import works today, and what works, wins.

Defining Contact List Portability

The more I talk to Leslie (of Satisfaction), the more sensitive I become to the language that we use when we talk about the technologies that we work on. I mean, what the fuck is an “XFN”? Even “social network portability” probably causes rational people to break out in hives when they hear the phrase (not like we’ve hit mainstream or anything). I mean, from a usability perspective, the words we use to describe this stuff is about as usable as Drupal was five years ago (zing!). I can only imagine that when we technologists open our mouths, this is what goes through most people’s heads:

SO, I’m not advocating ditching XFN altogether; on the contrary, compared with FOAF, I think we’ve achieved a great deal of mindshare, at least in gaining the support of technologists who work on fairly large social sites (though that’s apparently being disputed). The next stage of the process should be to simplify, and to focus on what people are already doing and on what’s working. If we simply want to defeat the email import approach (which I think is a good idea, albeit with the caveat that we still need a notification mechanism — perhaps something easily ignorable like Facebook-app invites?), then I think we need to consolidate our efforts on rel-contact and rel-me and let people discover (and optionally implement) the remaining 16 values if they’re bored. Or have free time. As far as I’m concerned, they offer little to no actual utility when it comes to contact list portability.

So to the definition of contact list portability, I would suggest that it’s the ability to take a list of identifiers (read: URLs, formerly email addresses) that represent people that you know and connect with them in a new context (bonus points if by “taking” you read that as “subscribing” (but not “syncing”)).

This is consistent with Joseph’s Practical Vision for Friends-List Portability. It also importantly ignores the non-overlapping problems of groupings/relationship semantics and permissioning (things which should not be conflated!).

What’s next

Kveton agrees with me; Recordon dissents, wanting more extensibility.

I get Dave’s point, but before we worry about extensibility, we have to look at what minimal bits of XFN are being picked up. By only specifying that an outgoing link is either a “contact” or “another link of mine”, we greatly reduce the cognitive tax of grokking the problem that XFN set out to solve and minimize the implementation tax of rolling out the necessary logic and template changes. Ultimately, it also simplifies the dataset, and pushes the semantics of relationships deeper into applications where I’d argue they belong (again, looking at the Dopplr model as well as Pownce (friends, fans, fan of) and Twitter (following, followers). While the other 16 XFN values are certainly not off limits, their marginal value is negligible compared with the cost of explaining why anyone should care of about them (let along understand them — i.e. “muse”??). And, compared with emails for identifiers, URLs are definitely the future.

So, with that, I’m no longer going to both with advocating for the complete adoption of XFN. Instead, I’m going to advocate for supporting Contact List Portability by implementing rel-me and rel-contact (a “subset” of XFN). And that’s it.

This won’t solve the problems that Anders is talking about, but I think it’s radical simplification that’s been long overdue in the effort towards social network portability.

The Existential DiSo Interview

The Existential DiSo Interview from Chris Messina on Vimeo.

Here’s what I asked myself:

how are you?

we’re going to talk about diso today? is that right?

what is diso?

you say it’s a social network, so how would it work with wordpress?

how is this different from myspace or facebook?

so who’s involved in this project?

so what comes next?

how is this different than opensocial?

what’s going to be the big win for diso?

so do you see this model applying in any other domain on the web?

what kind of support do you need?

are you talking to any of the bigger social networks? like facebook or myspace?

so who cares?

how will you draw customers away from myspace or facebook?

any last thoughts?

It’s high time we moved to URL-based identifiers

Ugh, I had promised not to read TechMeme anymore, and I’ve actually kept to my promise since then… until today. And as soon as I finish this post, I’m back on the wagon, but for now, it’s useful to point to the ongoing Scoble debacle for context and for backstory.

In a nutshell, Robert Scoble has friends on Facebook. These friends all have contact information and for whatever reason, he wants to dump that data into Outlook, his address book of choice. The problem is that Facebook makes it nearly impossible to do this in an automated fashion because, as a technical barrier, email addresses are provided as opaque images, not as easily-parseable text. So Scoble worked with the heretofore “trustworthy” Plaxo crew (way to blow it guys! Joseph, how could you?!) to write a scraper that would OCR the email addresses out of the images and dump them into his address book. Well, this got him banned from the service.

The controversy seems to over whether Scoble had the right to extract his friends’ email addresses from Facebook. Compounding the matter is the fact that these email addresses were not ones that Robert had contributed himself to Facebook, but that his contacts had provided. Allen Stern summed up the issue pretty well: My Social Network Data Is Not Yours To Steal or Borrow. And as Dare pointed out, Scoble was wrong, Facebook was right.

Okay, that’s all well and fine.

You’ll note that this is the same fundamental design flaw of FOAF, the RDF format for storing contact information that preceded the purposely distinct microformats and :

The bigger issue impeding Plaxo’s public support of FOAF (and presumably the main issue that similar services are also mulling) is privacy: FOAF files make all information public and accessible by all, including the contents of the user’s address book (via foaf:knows).

Now, the concern today and the concern back in 2004 was the exposure of identifiers (email addresses) that can also be used to contact someone! By conflating contact information with unique identifiers, service providers got themselves in the untenable situation of not being able to share the list of identifiers externally or publicly without also revealing a mechanism that could be easily abused or spammed.

I won’t go into the benefits of using email for identifiers, because they do exist, but I do want to put forth a proposal that’s both long time in coming and long overdue, and frankly Kevin Marks and Scott Kveton have said it just as well as I could: URLs are people too. Kevin writes:

The underlying thing that is wrong with an email address is that its affordance is backwards — it enables people who have it to send things to you, but there’s no reliable way to know that a message is from you. Conversely, URLs have the opposite default affordance — people can go look at them and see what you have said about yourself, and computers can go and visit them and discover other ways to interact with what you have published, or ask you permission for more.

This is clearly the design advantage of OpenID. And it’s also clearly the direction that we need to go in for developing out distributed social networking applications. It’s also why OAuth is important to the mix, so that when you arrive at a public URL identifier-slash-OpenID, you can ask for access to certain things (like sending the person a message), and the owner of that identifier can decide whether to grant you that privilege or not. It no longer matters if the Scobles of the world leak my URL-based identifiers: they’re useless without the specific permissions that I grant on a per instance basis.

As well, I can give services permission to share the URL-based identifiers of my friends (on a per-instance basis) without the threat of betraying their confidence since their public URLs don’t reveal their sensitive contact information (unless they choose to publish it themselves or provide access to it). This allows me the dual benefit of being able to show up at any random web service and find my friends while not sharing information they haven’t given me permission to pass on to untrusted third parties.

So screen scrape factoryjoe.com all you want. I even have a starter hcard waiting for you, with all the contact information I care to publicly expose. Anything more than that? Well, you’re going to have to ask more politely to get it. You’ve got my URL, now, tell me, what else do you really need?

Fluid, Prism, Mozpad and site-specific browsers

Matt Gertner of AllPeers wrote a post the other day titled, “Wither Mozpad?” In it he poses a question about the enduring viability of Mozpad, an initiative begat in May to bring together independent Mozilla Platform Application Developers, to fill the vacuum left by Mozilla’s Firefox-centric developer programs.

Now, many months after its founding, the group is still without a compelling raison d’être, and has failed to mobilize or catalyze widespread interest or momentum. Should the fledgling effort be disbanded? Is there not enough sustaining interest in independent, non-Firefox XUL development to warrant a dedicated group?

Perhaps.

There are many things that I’d like to say both about Mozilla and about Mozpad, but what I’m most interesting in discussing presently is the opportunity that sits squarely at the feet of Mozilla and Mozpad and fortuitously extends beyond the world-unto-itself-land of XUL: namely, the opportunity that I believe lies in the development of site-specific browsers, or, to throw out a marketing term: rich internet applications (no doubt I’ll catch flak for suggesting the combination of these terms, but frankly it’s only a matter of time before any distinctions dissolve).

Fluid LogoIf you’re just tuning in, you may or may not be aware of the creeping rise of SSBs. I’ve personally been working on these glorified rendering engines for some time, primarily inspired first by Mike McCracken’s Webmail.app and then later Ben Willmore’s Gmail Browser, most recently seeing the fruition of this idea culminated in Ruben Bakker’s pay-for Gmail wrapper Mailplane.app. More recently we’ve seen developments like Todd Ditchendorf’s Fluid.app which generates increasingly functional SSBs and prior to that, the stupidly-simple Direct URL.

But that’s just progress on the WebKit side of things.

If you’ve been following the work of Mark Finkle, you’ll be able to both trace the threads of transformation into the full-fledged project, as well as the germination of Mozpad.

Clearly something is going on here, and when measured against Microsoft’s Silverlight and Adobe’s AIR frameworks, we’re starting to see the emergence of an opportunity that I think will turn out to be rather significant in 2008, especially as an alternative, non-proprietary path for folks wishing to develop richer experiences without the cost, or the heaviness, of actually native apps. Yes, the rise of these hybrid apps that look like desktop-apps, but benefit from the connectedness and always-up-to-date-ness of web apps is what I see as the unrecognized fait accompli of the current class of stand-alone, standards compliant rendering engines. This trend is powerful enough, in my thinking, to render the whole discussion about the future of the W3C uninteresting, if not downright frivolous.

A side effect of the rise of SSBs is the gradual obsolescence of XUL (which already currently only holds value in the meta-UI layer of Mozilla apps). Let’s face it: the delivery mechanism of today’s Firefox extensions is broken (restarting an app to install an extension is so Windows! yuck!), and needs to be replaced by built-in appendages that offer better and more robust integration with external web services (a design that I had intended for Flock) that also provides a web-native approach to extensibility. As far as I’m concerned, XUL development is all but dead and will eventually be relegated to the same hobby-sport nichefication of VRML scripting. (And if you happen to disagree with me here, I’m surprised that you haven’t gotten more involved in the doings of Mozpad).

But all this is frankly good for Mozilla, for WebKit (and Apple), for Google, for web standards, for open source, for microformats, for OpenID and OAuth and all my favorite open and non-proprietary technologies.

The more the future is built on — and benefits from — the open architecture of the web, the greater the likelihood that we will continue to shut down and defeat the efforts that attempt to close it up, to create property out of it, to segregate and discriminate against its users, and to otherwise attack the very natural and inclusive design of internet.

Site specific browsers (or rich internet applications or whatever they might end up being called — hell, probably just “Applications” for most people) are important because, for a change, they simply side-step the standards issues and let web developers and designers focus on functionality and design directly, without necessarily worrying about the idiosyncrasies (or non-compliance) of different browsers (Jon Crosby offers an example of this approach). With real competition and exciting additions being made regularly to each rendering engine, there’s also benefit in picking a side, while things are still fairly fluid, and joining up where you feel better supported, with the means to do cooler things and where generally less effort will enable you to kick more ass.

But all this is a way of saying that Mozpad is still a valid idea, even if the form or the original focus (XUL development) was off. In fact, what I think would be more useful is a cross-platform inquiry into what the future of Site Specific Browsers might (or should) look like… regardless of rendering engine. With that in mind, sometime this spring (sooner than later I hope), I’ll put together a meetup with folks like Todd, Jon, Phil “Journler” Dow and anyone else interested in this realm, just to bat around some ideas and get the conversation started. Hell, it’s going on already, but it seems time that we got together face to face to start looking at, seriously, what kind of opportunity we’re sitting on here.

Public nuisance #1: Importing your contacts

Facebook Needs OAuth

I’ve talked about this before (as one of the secondary motivators behind OAuth) but I felt it deserved a special call out.

Recently, Simon Willison presented on OpenID and called the practice that Dopplr (and many many others) uses to import your contacts from Gmail absolute horrifying. I would concur, but point out that Dopplr is probably the least offender as they also provide safe and effective hcard importing from Twitter or any URL, just as Get Satisfaction does.

Unfortunately this latter approach is both less widely implemented and also unfamiliar to many regular folks who really just want to find their friends or invite them to try out a new service.

The tragedy here is that these same folks are being trained to hand out their email address and passwords (which also unlock payment services like Google Checkout) regularly just to use a feature that has become more or less commonplace across all social network sites. In fact, it’s so common that Plaxo even has a free widget that sites can use to automate this process, as does Gigya. Unfortunately, the code for these projects is not really open source, whereas Dopplr’s is, providing little assurance or oversight into how the import is done.

What’s most frustrating about this is that we have the technology to solve this problem once and for all (a mix of OpenID, microformats, OAuth, maybe some Jabber), and actually make this situation better and more secure for folks. Why this hasn’t happened yet, well, I’m sure it has something to do with politics and resources and who knows what else. Anyway, I’m eager to see a open and free solution to this problem and I think it’s the first thing we need to solve after January 1.

Data portability and thinking ahead to 2008

So-called data portability and data ownership is a hot topic of late, and with good reason: with all the talk of the opening of social networking sites and the loss of presumed privacy, there’s been a commensurate acknowledgment that the value is not in the portability of widgets (via OpenSocial et al) but instead, (as Tim O’Reilly eloquently put it) it’s the data, stupid!

Now, Doc’s call for action is well timed, as we near the close of 2007 and set our sights on 2008.

Earlier this year, ZDNet predicted that 2007 would be the year of OpenID, and for all intents and purposes, it has been, if only in that it put the concept of non-siloed user accounts on the map. We have a long way to go, to be sure, but with OpenID 2.0 around the corner, it’s only a matter of time before building user prisons goes out of fashion and building OpenID-based citizen-centric services becomes the norm.

Inspired by the fact that even Mitchell Baker of Mozilla is talking about Firefox’s role in the issue of data ownership (In 2008 … We find new ways to give people greater control over their online lives — access to data, control of data…), this is going to be issue that most defines 2008 — or at least the early part of the year. And frankly, we’re already off to a good start. So here are the things that I think fit into this picture and what needs to happen to push progress on this central issue:

  • Economic incentives and VRM: Doc is right to phrase the debate in terms of VRM. When it comes down to it, nothing’s going to change unless 1) customers refuse to play along anymore and demand change and 2) there’s increased economic benefit to companies that give back control to their customers versus those companies that continue to either restrict or abuse/sell out their customers’ data. Currently, this is a consumer rights battle, but since it’s being fought largely in Silicon Valley where the issues are understood technically while valuations are tied to the attractiveness a platform has to advertisers, consumers are at a great disadvantage since they can’t make a compelling economic case. And given that the government and most bureaucracy is fulled up with stakeholders who are hungry for more and more accurate and technologically-distilled demographic data, it’s unlikely that we could force the issue through the legal system, as has been approximated in places like Germany and the UK.
  • Reframing of privacy and access permissions: I’ve harped on this for awhile, but historic notions of privacy have been out-moded by modern realities. Those who do expect complete and utter control need to take a look at the up and coming generation and realize that, while it’s true that they, on a whole, don’t appreciate the value and sacredness of their privacy, and that they’re certainly more willing to exchange it for access to services or to simply dispense with it altogether and face the consequences later (eavesdroppers be damned!), their apathy indicates the uphill struggle we face in credibly making our case.

    Times have changed. Privacy and our notions of it must adapt too. And that starts by developing the language to discuss these matters in a way that’s obvious and salient to those who are concerned about these issues. Simply demanding the protection of one’s privacy is now a hollow and unrealistic demand; now we should be talking about access, about permissions, about provenance, about review and about federation and delegation. It’s not until we deepen our understanding of the facets of identity, and of personal data and of personal profiles, tastestreams and newsfeeds that can begin to make headway on exploring the economic aspects of customer data and who should control it, have access to it,

  • Data portability and open/non-proprietary web standards and protocols: Since this is an area I’ve been involved in and am passionate about, I have some specific thoughts on this. For one thing, the technologies that I obsess over have data portability at their center: OpenID for identification and “hanging” data, microformats for marking it up, and OAuth for provisioning controlled access to said data… The development, adoption and implementation of this breed of technologies is paramount to demonstrating both the potential and need for a re-orientation of the way web services are built and deployed today. Without the deployment of these technologies and their cousins, we risk web-wide lock-in to vender-specific solutions like Facebook’s FBML or Google’s , greatly inhibiting the potential for market growth and innovation. And it’s not so much that these technologies are necessarily bad in and of themselves, but that they represent a grave shift away from the slower but less commercially-driven development of open and public-domained web standards. Consider me the frog in the luke warm water recognizing that things are starting to get warm in here.
  • Citizen-centric web services: The result of progress in these three topics is what I’m calling the “citizen-centric web”, where a citizen is anyone who inhabits the web, in some form or another. Citizen-centric web services, are, of course, services provided to those inhabitants. This notion is what I think is, and should, going to drive much of thinking in 2008 about how to build better citizen-centric web services, where individuals identify themselves to services, rather than recreating themselves and their so-called social-graph; where they can push and pull their data at their whim and fancy, and where such data is essentially “leased” out to various service providers on an as-needed basis, rather than on a once-and-for-all status using OAuth tokens and proxied delegation to trusted data providers; where citizens control not only who can contact them, but are able to express, in portable terms, a list of people or companies who cannot contact them or pitch ads to them, anywhere; where citizens are able to audit a comprehensive list of profile and behavior data that any company has on file about them and to be able to correct, edit or revoke that data; where “permission” has a universal, citizen-positive definition; where companies have to agree to a Creative Commons-style Terms of Access and Stewardship before being able to even look at a customer’s personal data; and that, perhaps most import to making all this happen, sound business models are developed that actually work with this new orientation, rather than in spite of it.

So, in grandiose terms I suppose, these are the issues that I’m pondering as 2008 approaches and as I ready myself for the challenges and battles that lie ahead. I think we’re making considerable progress on the technology side of things, though there’s always more to do. I think we need to make more progress on the language, economic, business and framing fronts, though. But, we’re making progress, and thankfully we’re having these conversations now and developing real solutions that will result in a more citizen-centric reality in the not too distant future.

If you’re interested in discussing these topics in depth, make it to the Internet Identity Workshop next week, where these topics are going to be front and center in what should be a pretty excellent meeting of the minds on these and related topics.