Brian Oberkirch captured some video today of a conversation between him, David Recordon and myself at GSP East about social network interop, among other things.
Hot on the heals on my last post, this conversation is rather timely!
Tag: social networking
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 XFN and hcard:
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?
The inside-out social network
Anne Zelenka of Web Worker Daily and GigaOM fame wrote me to ask what I meant by “building a social network with its skin inside out” when I was describing DiSo, the project that Steve Ivy and I (and now Will Norris) are working on.
Since understanding this change that I envision is crucial to the potential wider success of DiSo, I thought I’d take a moment and quote my reply about what I see are the benefits of social network built inside-out:
The analogy might sound a little gruesome I suppose, but I’m basically making the case for more open systems in an ecosystem, rather than investing or producing more closed off or siloed systems.
There are a number of reasons for this, many of which I’ve been blogging about lately.
For starters, “citizen centric web services” will arguably be better for people over the long term. We’re in the toddler days of that situation now, but think about passports and credit cards:
- your passport provides proof of provenance and allows you to leave home without permanently give up your port of origin (equivalent: logging in to Facebook with your MySpace account to “poke” a friend — why do you need a full Facebook account for that if you’re only “visiting”?);
- your credit/ATM cards are stored value instruments, making it possible for you to make transactions without cash, and with great convenience. In addition, while you should choose your bank wisely, you’re always able to withdraw your funds and move to a new bank if you want. This portability creates choice and competition in the marketplace and benefits consumers.
It’s my contention that, over a long enough time horizon, a similar situation in social networks will be better for the users of those networks, and that as reputation becomes portable and discoverable, who you choose to be your identity provider will matter. This is a significant change from the kind of temporariness ascribed by some social network users to their accounts today (see danah boyd).
Anyway, I’m starting with WordPress because it already has some of the building blocks in place. I also recognize that, as a white male with privilege, I can be less concerned about my privacy in the short term to prove out this model, and then, if it works, build in strong cross-silo privacy controls later on. (Why do I make this point? Well, because the network that might work for me isn’t one that will necessarily work for everyone, and so identifying this fact right now will hopefully help to reveal and prevent embedding any assumptions being built into the privacy and relationships model early on.)
Again, we’re in the beginning of all this now and there’ll be plenty of ill-informed people crying wolf about not wanting to join their accounts, or have unified reputation and so on, but that’s normal during the course of an inversion of norms. For some time to come, it’ll be optional whether you want to play along of course, but once people witness and come to realize the benefits and power of portable social capital, their tune might change.
But, as Tara pointed out to me today, the arguments for data portability thus far seem predicated on the wrong value statement. Data portability in and of itself is simply not interesting; keeping track of stuff in one place is hard enough as it is, let alone trying to pass it between services or manage it all ourselves, on our own meager hard drives. We need instead to frame the discussion in terms of real-world benefits for regular people over the situation that we have today and in terms of economics that people in companies who might invest in these technologies can understand, and can translate into benefits for both their customers and for their bottom lines.
I hate to put it in such bleak terms, but I’ve learned a bit since I embarked on a larger personal campaign to build technology that is firmly in the service of people (it’s a long process, believe me). What developers and technologists seem to want at this point in time is the ability to own and extract their data from web services to the end of achieving ultimate libertarian nirvana. While I am sympathetic to these goals and see them as the way to arriving at a better future, I also think that we must account for those folks for whom Facebook represents a clean and orderly experience worth the exchange of their personal data for an experience that isn’t confounding or alienating and gives them (at least the perception) of strong privacy controls. And so whatever solutions we develop, I think the objective should not be to obviate Facebook or MySpace, but to build systems and to craft technologies that will benefit and make such sites more sustainable and profitable, but only if they adopt the best practices and ideals of openness, individual choice and freedom of mobility.
As we architect this technology — keeping in mind that we are writing in code what believe should be the rights of autonomous citizens of the web — we must also keep in mind the wide diversity of the constituents of the web, that much of this has been debated and discussed by generations before us, and that our opportunity and ability to impose our desires and aspirations on the future only grows with our successes in freeing from the restraints that bind them, the current generation of wayward web citizens who have yet to be convinced that the vision we share will actually be an improvement over the way they experience “social networking” today.
Factory Joe 