How (not) to make friends

Image by Chewbacka via FlickrRegarding the social web and linking of 'friends', the currently available implementations such as Facebook etc. take the following approach:

First you identify who is your 'friend' (within the same network or application), this in turn determines which attributes they are allowed to see. Other classes of relationships like 'acquaintance', 'co-worker' 'school-mate' 'best friend' are now being proposed on the Data Portability forums to manage this.

This not only smells like bad design, but it appears to me to be an inversion of what happens in reality.

It is not the appointing of a 'friend' class to someone which determines who can see which of your attributes. It's the other way around: by allowing different identities to see different subsets of your attributes (gradually and over time), you define your relationship with these other identities. In other words, someone might become a friend after you decide he may see some of your attributes.

You don't have to decide on the relationship type upfront if you could granularly disclose attributes to various other identities (and maybe have the favor returned to you).

Off course people don't want to be bothered continuously with such fine-grained control over their individual attributes. As usual, software programs can ease the burden and help with common tasks.

Not many people currently craft their HTML documents and HTTP requests by hand to publish or read on the world-wide web. Still, inter-operability of all the different software is possible, thanks to the underlying standards. Sadly, we don't have these for identities and their attributes yet.

Information sink vs information source

How Sticky Is Membership on Facebook? Just Try Breaking Free - New York Times

Another example of how most applications act like information sinks. It's easy to enter your information (data about you), but once you do, you lose control. The Facebook application (like almost any other online application) is an information sink.

To me it seems the only approach to preserve control over your data is to leave those applications alone. That's why I'm not on Myspace, Facebook or others (Linkedin being the exception, for some reason).

Ideally, I would like to have the ability to create an information source, totally under my control, in which I design and edit my profile. A generic protocol for addressing and disclosure would then allow other applications and people to use this information source for many different applications (which would then basically become views on my data, and that of others in the aggregate).

What do you think?

DataPortability - bad name for a real problem

It's about you

The recurring theme in social web data is that the data concerned is about an individual (ie. you). Anything that describes (a part of) you or your actions or preferences or you name it, qualifies to be part of your 'profile'. It doesn't matter if you typed it in yourself, or if it is generated by some system. (As long as something pertains to you, represents you, it should be under your control. I'm taking an extremely user- or identity-centric approach here).

Currently almost any data describing you is not under your control. See The Profile Problem of which the Scoble vs Facebook case is an example (not the latest, methinks).

Let me be clear: I totally agree with the problems that DataPortability tries to solve. Only the name of the project is misleading to say the least.

The name Data Portability (and some of the things I've read on their website and forum) gives me the feeling that they want to be able to extract and import 'user data' from and into various existing social-web applications, just like Scoble did. That's a nice problem to solve, but it all depends on what level of abstraction the standards are formulated.

Let's do a thought experiment, Imagine a less-than-world-wide web where pre-existing publication platforms were hosting content, each in its own proprietary way. At some point the need for inter-operability (linking) and re-usability of this content becomes apparent.

Thanks to Tim Berners-Lee, and lucky for us, we don't have this situation on the current world-wide (webpage) web. We're not porting documents from one web-server implementation to the other, and we don't need or want standards to do so. Instead we have the HTML standard for the document format, the HTTP protocol for accessing and creation, and the URL for addressing.

These are key components. But on the social web, we do have this situation.

The problem isn't then that we can't port or migrate data (we really shouldn't be wanting to go that way), the problem lies deeper in that there aren't any standards for representing, addressing and manipulating this type of content.

Similar to the standards that make the world-wide web so successful, I sincerely hope that the DataPorters want to come up with a similar addressing standard for identities and for individual attributes. Already OpenID covers the part of the solution.

Once identities and specific attributes are uniquely addressable, data at these addresses should be in a standard document format (like HTML documents which resides at url addresses, 'attribute documents' should reside at attribute-url's). I would like to have an addressable document in a standard document format for each of the attributes that are part of my self-representation. (Unlike web-pages, these attribute-documents shouldn't be automatically world-readable, the documents themselves should include disclosure settings, and part of the access protocol should be the decision to disclose or not, depending on the 'requesting party'.)

It follows then that we also need a protocol for sending messages to create, retrieve, update, remove and share (disclose) these attribute-documents (defined by their unique addresses); HTTP does this for viewable documents and we should have something similar for identity-centric attribute documents.

Once the standards are there at the right level of abstraction (the attribute level imho), the rest is easy. You could implement a Facebook in no time, and it would be inter-operable with any other such system (no need to shovel data to and fro).

Conclusion

It seems to me that trying to make current proprietary social-web applications inter-operable after the fact, by devising a standard at the application level, is a waste of effort. Too bad we have existing applications without standards, but this still leaves us with the need for low-level standards for the identity-attribute domain. Once we have that, data portability is a non-issue.