This Saturday Mediamatic is hosting an event on Federating Social Networks (Upcoming) to further the ongoing dialogue regarding opening the social graph information.

The conversation that started earlier this year and had a big flare with the announcement of OpenSocial just before Barcamp Berlin is going on.

Ralph Meijer presented (announcement on his blog) on the subject during the Web 2.0 Expo on how to solve the problem using XMPP.

At the same time OAuth 1.0 and OpenID 2.0 are coming to fruition and Chris Messina is talking about distributing social networking applications. And Hyves —our Dutch social network— is busy opening up their API.

These are exciting times, but this technological groundwork is just the beginning. The real challenge is making understandable and usable systems using this stuff.

One of the talks at the Future of Web Apps (FOWA) showed me a way to use OpenID that I hadn’t realize yet. Many people, when they think of OpenID, think of it as a way to log in a.k.a. authenticate themselves towards a system. Clearly you could give them anything you want as long as you give them the same OpenID every time you drop by.

Matt Biddulph from Dopplr though, showed some ways how OpenID could be used beyond authentication. Dopplr for example lets you add more than one OpenID account to your Dopplr account, which enables you to login to Dopplr with any OpenID provider. This becomes quite redundant when you add more than two OpenIDs, but Matt Biddulp showed that you can use people’s OpenID for more purposes besides authentication.

I already knew, you could use an OpenID to verify that a person is simply a member of a certain group of people. Much like you could use your student card to get discount at a cinema, an OpenID from your university would show that you are a student. Extending on this your national OpenID could prove your nationality, and your corporate OpenID could prove the company you work for.

Note that the actual identity of the user is not relevant and doesn’t really need to be checked as only the type of the OpenID is the important part. Even better, there is no extension like XRI needed to make this even work.

+

A second example though showed how OpenID+Microformats would be able to give any application a nice read-only API. Imagine that you have an app, and you would like to give your user a simple way to add their friends from their other networks. A simple way to do this would be to let the user provide the OpenIDs of some other networks. Checking with the OpenID server if this OpenID really belongs to that user would be enough for you to then simply fetch the Microformatted contact lists from their profile pages on those sites, and compare that info with your own list of users.

Many networks like Twitter and Jaiku already present their friend lists using Microformats, but they don’t yet provide their users with an OpenID login that would allow any other app to actually verify if user X on your application is actually user Y on that other site. Currently Dopplr just scrapes your Twitter profile page for friends when you give them a username, so you could give them any name you want, but if Twitter would become an OpenID provider than they could use this to check if you are really that person on that network.

[More brainstorming on combining Microformats and OpenID]

I just had a look at Simon Willison’s talk at Google about the implications of OpenID. Basically he covered a short FAQ list, answering some of the most common questions about OpenID. During the talk it was interesting to see how often he had to refer to the notion that OpenID doesn’t try to solve every problem, but that there is enough opportunity to build on OpenID to try and solve any other issues. This got me thinking about the problem of localization and how we could solve/aid this with OpenID

As a Dutch person I am very interested in localization as I would like to use a lot of service with my Dutch friends and family (mother). I would like to motivate many of my less tech-savvy Dutch friends to use things like Twitter, Jaiku and Flickr instead of local copycat versions. In many non-English speaking countries these services get copied, for example Zezz.nl which is a Twitter/Jaiku clone build by Alper for the Dutch market.

The problem with this copycat-approach is that you get localized silos of separated networks, with some people like me having to sign up to a localized version and an English version in order to be able to share with everyone I know. A good example is that I currently had to sign up for Facebook AND Hyves for social networking, as Hyves is far more popular in The Netherlands than Facebook. To make things worse: would I ever move to Brazil then I would also have to sign up for Google’s Orkut which is far more popular there!

So why not localize? First of all localization is a tedious job and secondly it is easily done wrong. To understand what goes wrong quite often, you should realize that in the English language we use the same terms over and over again on different sites for the same concepts. We use “save” for saving a file, “delete” for deleting it, and so we use other standard terms for other concepts. Calling the delete action “purge” and the save action “store” would still be understandable but defy expectations and possibly create confusion. This is exactly what happens in most localizations of systems, as there is no standardization of the terms used across sites.

So in comes OpenID, which when I log in to multiple sites already identifies me to every site, and is able to provide personal info using SRE. So why not extend this concept or create a new system that can enable an OpenID consumer to request what my localization should be, an possibly request translations directly from the OpenID provider. Obviously this should at first only work for basic terms like “Save”, “Delete”, “Open”, as full sentences might be a bit far fetched (for now).

I actually don’t think this is a problem though, as most people in foreign languages have some experience with the English language, but are just scared by a 100% English system. If for example Flickr would only localize their menu, I would expect that the user experience for many new Dutch Flickr users would become way easier. Funny enough Zooomr already has a localized version that is semi-translated.

Clearly it is not OpenID’s task to solve the problem of localization, but as Simon Willison stated: there is a lot of potential to build upon the OpenID idea. Combining this with the idea that OpenID providers will have to differentiate themselves by the services they offer leads me to conclude that they are all thinking of new techniques to implement.

An accessible OpenID interface to the localized verbs and nouns of the user would come in very handy here, especially for small sites that don’t want to do any localization. Making these libraries of terms user-generated would even make it a less tedious job and actually just a technical job. Does anyone know if this idea has been coined before?

A while back I read a post by Boris about how OpenID is not really easy to use (yet). He is completely right, and if Boris can’t use it, our moms definitely do not stand a chance.

I had a conversation about this with Ted Rheingold of Dogster, who was thinking of implementing OpenID for their users so people could user their Dogster logins to log in to affiliate third party sites.

A very important issue for him is that a lot of his users are not geeks and do not really want to get into the technological side of things. In most cases people will not be familiar yet with OpenID and you want to shield them from the complexities while still offering the benefits.

Do I have a OpenID?

When confronted with an OpenID login box, this is the first question that people —like Boris— are confronted with. What is this OpenID thing and do I have one or where do I get one?

Luckily more and more sites are offering hosted OpenID identities to their users. Wordpress.com does this for their blog owners and LiveJournal does this as well. Most people will probably prefer to use one of these hosted solutions offered by a third party site instead of hosting their OpenID themselves.

This way identities will be created until most people will have multiple OpenIDs. That still does not solve the problem of knowing that you have an OpenID and knowing what it is. I will propose a solution to this problem just after the next point.

URLs for what?

The whole concept that you use an URL to login —though I think it is quite elegant— will be difficult to explain to users, who already have trouble telling their login names and e-mail addresses apart. Adding another entity that you can use to login at sites, will only add to the confusion.

Signing in with e-mail addresses is firmly settled but it did take some time to get there. We may get to the same level with OpenID (and hopefully replace e-mail based logins altogether) some day but that is too distant currently. URLs are generally perceived as user unfriendly and normal users should not have to deal with them too much (yet).

Maybe i-names will be a solution to this sometime, but I don’t see it becoming mainstream any time soon.

Solve away the URLs

Taking both previous points together: most people will use a hosted OpenID solution and people do not want to type URLs, we can just abstract away the URLs completely.

When logging into an OpenID consuming site, that site can provide a selector with a couple of well known sites providing OpenIDs. This list of OpenID providers should be attuned to the target audience so they are familiar with these sites. With a fairly small list of providers, you can probably cover a large part of your user base.

I have made an example login box that works this way. It gives users the choice between several well known sites or the possibility to fill in your own OpenID. This is just a mockup which you can adjust in any way you like. You could expand the different login options or present them anyway you like. A site which already takes such an approach is the site for the band Rooney. You could also display the generated OpenID to the user at some point to get them accustomed to the OpenID they will be using.

Using that selector and a textbox users can pick a site they have an account on and fill in their username. The consuming site can then construct an OpenID URL from the given username and use that to log the user on. So taking my Wordpress.com username illustir it would construct my OpenID http://illustir.wordpress.com/ automatically (see the example).

What site are you taking me to?

The step where you leave the site you are logging into for another site can be a bit distressing for users. The approach that sites such as Wordpress.com take by having their own identity provider which looks and feels familiar dampens this transition a lot.

Large sites using OpenID should generally have their own provider so that they can control and attune the experience for logging users in.

Dogster’s use for OpenID

Suppose Dogster wanted their users to be able to log into third party sites using ther Dogster login credentials. This seems like it is exactly the kind of problem that OpenID is meant to solve. Especially in the case where the login is more a dependent syndication —a third party site affiliating with a bigger site— than that it is a general login (though nothing stops it from working that way as well).

So in the Dogster case they should start their own OpenID provider and OpenID enable all their accounts which are both relatively easy steps. Then, third party sites could use a Dogster login to log onto their site by simply becoming an OpenID consumer and by constructing the correct OpenID from the Dogster login.
The only problem with the Dogster case is that they use e-mail addresses as usernames and you would have to construct an URL with the e-mail in it. You probably would not want to spread e-mail addresses in that fashion.

This approach can be taken by any big site which wants to enable its users logging in elsewhere with the same credentials.

Update: I updated the example to be more clear and more educational about the actual OpenID that is being constructed.
Besides that a lot of people are missing the point. I am completely in favor of browser integration rich identity homepages and everything. Go out and build them already, but should/could/would are not going to help us right here right now. Given Livejournal+Wordpress+AOL almost everybody already has an OpenID but most of them do not know it yet. This —admittedly trivial example— is meant to fix that.

This is a delayed entry about a small session I held on Reboot about social networks. It ties in nicely to a recent series on Four Starters about trust and how friends are a solution to this.

In this article I will lay out why social networks are too important too leave in other people’s walled gardens and I will lay out a tentative way to connect the gardens and cultivate your own using microformats and other open standards.

Feedback is greatly appreciated.

The buddy list is key

Social networks and your online identity were prominent in various Reboot talks this year. I lifted Stowe Boyd’s quote: “The buddy list is the center of the universe.” (see slide). This has been true always but is ringing more so as the web matures and we are seeing the breakdown of centralized application models.

In a recent article, Dare Obasanjo wrote about the same subject and how he thinks that Facebook is going to be a big driver in this space. Maybe for America, but I don’t see this happening for Europe in the near future.
And does it seem like a good idea to have all the social information of the world under the control of one company?

But as Dare says, knowing who I know and who I trust, whether that information is in your address book or in your IM application, is usable in other contexts and can greatly improve the trust and interaction in those contexts. You apply the wisdom of crowds to a subset of people —the people you know— to circumvent the trust breakdown Reinier wrote about in current sites.

Yet another social network

My session was after that of Willem Velthoven (write up) who talked about their anyMeta social networking application. Their angle is to reduce the duplication of effort and enable sharing of data. Willem spoke about how he got quite sick of filling in his profile on every social networking site he wanted to participate in.

I have the same feeling and that is mainly what stopped me from filling in my Facebook profile, that and the fact that nobody I know is on Facebook. I could not bring myself to fill in another profile and try to get all my friends onto a new social network just because it looks like the next big thing.

Putting your profile information into these closed social networks gives them a lot of value but you rarely get the option of retrieving that information or using it elsewhere. The facebook API is an exception and is one way of getting access to data while it stays firmly in the silo. At what terms you can get at the data and what you can use it for is firmly in the hands of Facebook.

Microformats to the rescue

What I propose and what we talked about during my session is the concept of Portable Social Networks enabled by microformats. A social network that is open and readable and can be with you anywhere you want. During the Mediamatic session we discussed the use cases and the issues that would crop up and I invited people to attend my session for a discussion on the technical aspects.

We had a brief chat afterwards with interested people and after a break I was joined by some people among whom Willem Velthoven and Jeremy Keith (his post) to talk further about the technical stuff. I got the impression that some of the people attending my session were happy —maybe relieved even— that there was also a technical session to be found on Reboot.

Photograph by Jeremy Keith

Photograph by Tijs Teulings

I will go into deeper technical detail in a following post but the concept is to use microformats to markup most of the information found on a typical Myspace, Facebook or Hyves (the Netherlands’ most prominent social network) profile page. This way you can either get the data out from supporting social applications or hook into the network by hosting your own identity web page with correctly formatted data.

So what can we do with technology we already have (POSH+microformats)? As it would seem, a lot:

hCard

Your hCard can contain most of your personal information including your personal details, your address and your picture. This is equivalent to the personal details and picture which are usually listed on any given social network.

XFN

Most social networks have a prominently visible list of friends and a count of your total number of friends. This is very easy to implement using XFN. You can markup the links to the people in your network with the rel=”" metadata which XFN defines. XFN allows you to hook into the network from anywhere. So an XFN link from suppose Hyves could also lead to a profile page on another social network or a self-hosted one. Or at least, that is the vision.

This way you can also differentiate between trust levels withouth using numeric values which Reinier also talked about would be necessary. I am bound to trust a friend more than a contact and you could derive more relations like that.

You could also link to other sites where you have a profile or store data such as your Flickr account, your del.icio.us bookmarks or any other site. The rel="me" value could be used for this, but it is required to be symmetric, so those other sites would have to link back using the same rel="me".

hResume

A lot of social networks also allow you to markup your current job, sometimes your previous places of employment as well and in many cases also your school history so you can get in touch with former school friends.

This information is very similar to the information you can markup using hResume. You could only present the information you want to share in a casual social network but you might want to enter a full hResume to provide all the functionality of professional social networks such as LinkedIn or Xing.

hReview

Most social networking sites and even Flickr have you keep lists of your hobbies, favorite music, movies and books. You could easily mark these up as hReviews and have the fn be an URL to a generally known catalog for that item. For books I would say something such as Librarything or Amazon (with an associate ID!), for music maybe Last.fm and for movies probably IMDb.

This also solves the problem Willem suggested could arise when we use different (language) titles for the same object. Just link them all to the same uniquely identifying resource.

OpenID

The microformatted information listed above can be on any page you want, in fact it probably already is if you have a Flickr or a Twitter account. I do think that there is a case to be made for linking this to your OpenID.

OpenID solidifies the notion of identity online and creates a place for everything to come together. It gives you a URL with which you can refer to a person and you can be reasonably sure that the person and the URL belong together.

Applications that will want to use this kind of information will probably already ask for your login credentials. Those credentials could very well be an OpenID from where on you could automatically retrieve a load of information as described above.

Consolidating or delegating

The question is: do you host this information yourself or do you have someone else do it for you? Since I already host my own OpenID at http://alper.nl, I have already started by embedding an hCard there and I am building the MySpace-esque portal page with all my information on there (preview).

Not everybody will want to host this themselves, but it is analogous to OpenID. Anybody can self-host their OpenID but they can also use a hosted version and the same for the providers. If at any time you want to switch OpenID providers, just change the reference.

The various internet sites which host your profile information such as the social networks and the profile sites such as MyBlogLog or 30boxes need only to mark up their essential data with these standards for it to become instantly accesible and portable.

Even for those hosting this information themselves, it would be nice to have some sort of interface beyond editing the HTML yourself. For instance it would be nice to have an ‘Add as friend’ button on your own site which would ask for your permission to add somebody to your XFN list.

Completeness and Clients

You can make the markup as rich as you want or you can leave stuff you don’t want to share out. Adoption and convention is completely up to you. There are advantages in adhering to a certain standard, but smart clients should be able to deal with holes in this picture.

Below are some use cases which can be realized today already and will also work if not all of the information is present.

Use case: Get an Avatar for somebody

I already talked about this in a previous article (“OpenAvatar - Combining OpenID and hCard”). This concept is just an extension which loads more data onto the page. If a page —such as an OpenID page— contains an hCard with an associated picture, you can retrieve it.

My avatar retrieved from my Flickr profile page

I already wrote a parser as a webservice which takes a URL and returns the associated picture. This parser can take either my OpenID or my Flickr profile (which contains an hCard). This way you can get an avatar for someone that they can manage and update to their own liking.

This concept had already been brainstormed on the microformats wiki.

Use case: Get registration information

A lot of information you need to fill in once during registration such as your full name, date of birth and some other stuff can be gleaned from the hCard. The site getsatisfaction.com already offers to scrape this information from an hCard supporting profile when signing up, saving you the trouble to fill it in.

Flickr lets users list their preferences in music, literature and cinema on their profile page. This listing could be marked up as an hReview with a rating of 1.0 on a worst/best scale of -1.0 to 1.0 (like is 1.0, dislike is -1.0). Then I could reuse it on all the social networking sites that want to know my favourite movies.

Use case: Find out who I trust

The stuff Dare and Reinier talked about with building trust networks and using that information can be realized by walking the XFN web.

Any site imaginable can be improved by adding the knowledge of my network. Imagine IMDb which shows you which movies your friends have recently watched. Or anything really, and all this without having to add your friends on every such network.

Wouldn’t that be a dream?

The series finale. (previously: intro, part 1 and part 2)

Part 3: Future of Trust: Ponderings on the future of the social web

In parts 1 and 2 we’ve created a pretty sweet hypothetical article recommendation engine based on networks of trust relations.

That was merely an example; almost everything you do on the web involves trust. Consider the following current internet practices that really need some sort of trust web to solve a bunch of defects:

• eBay needs more trust. Not just the general “Can I trust this guy to actually deliver what he’s selling?”, but even simpler, what if you could reduce a buyer/seller’s feedback score to only the feedback given by your trust network?
• Receiving e-mail: What if your spam filter could take into account the trust relation between you and the email sender? A respectable company would be able to get their form emails easily past your spam filter, and any companies that do engage in spam will see real repercussion and cost: Massive loss of trust, undermining any future endeavours. If the trust vectors are interconnected, this loss of trust hurts them on the entire web, not just on email.
• Blog commenting: Almost analogous to receiving email —no more need for akismet. Knowing the trustability of a server operator also helps directly in cutting down on linkjacking and shill blogging (Trust #3 in the reddit/digg/delicious analysis: Can I trust the host of the linked article to be honest is satisfied with such a system!)

You can come up with similarly elegant fixes to just about everything you do on the web.

Trust is universal

The one problem with setting all web services up to work with webs of trust is that it’s annoying to upload your list of friends to all these webservers. Optimally you really want a single site/space/page where you can drop your list of people you trust, and let all other services —your email provider, digg, reddit, del.icio.us, eBay, your blog software, your web browser, your flickr account, etc.— simply read out your trust web from there.

There are 2 separate movements underway to help out in this regard.

Facebook and Open web APIs
A number of disjointed web platforms already are aware of (some of) your web of trust. For example, your average ‘social network’ server (facebook, MySpace, Hyves, etc) knows about your friends, your friends’ friends, etcetera. In theory at least you trust your friends at least somewhat. Facebook has made the bold first move of making it relatively easy to ‘surf’ this network of trust, which should make it possible for other sites to simply glean your trust network from there instead of re-inventing the wheel.
Hopefully other services which have a part of the network of trust relations will open up their services as well. For example, mutual email conversations —you both sending and receiving— is a pretty good indicator of trust. Some crafty database queries on the gmail server could produce a very useful web of trust graph. The blogs you have in your RSS feed are also a (usually) positive reflection on the amount of trust you have for a given user in this case the author/operator of the sites behind those feeds.

Interesting startup idea here - or probably more likely a lucrative opportunity for an existing social network service, like facebook: You leave your username and password details of a number of web services, to get a heuristic attempt at recreating your complete trust web. Because the indicators I named above sometimes might be wrong, this site should also offer a simple way to give someone an explicit positive or negative review.

The biggest challenge here is simply realizing that two accounts on two different web services belong to the same person. Not all web services use email, and most people have more than one e-mail address.

OpenID
The OpenID movement is taking a more distributed approach to the problem. We at Four Starters have written lots about OpenID, but the basic gist is simply the ability to store all the information you usually need to fill in to register at sites (username, password, email, home address, website, thumbnail foto, etcetera) on one server, so that you can then allow other websites to simply ask that server for the information. The ‘OpenID’ server, upon getting a request for any sort of information —including just authenticating that you are you— then asks you to identify yourself. The upshot is that only your OpenID provider even needs to know a password. For all other sites you simply enter your OpenID —which is a URL. Mine is http://reinier.zwitserloot.com/ for example.

The amount of data you can put on the OpenID server is extensible; it doesn’t have to be limited to just the usual name, email, address information. You could stuff your trusted contacts in your OpenID database as well —a list of OpenIDs combined with a trust percentage. This system solves the problem of linking identities that the aggregate existing services plan listed above suffers from.

This is really the solution Dick Hardt seems to be talking about in his world famous Identity 2.0 presentation. I had the good fortune to see an extended and updated version of it live at The Next Web 2007 where he presented.

I’d love to delve deep into what needs to happen to the web to make this solution work, but I couldn’t possibly do as good a job at it as Dick’s presentation, so I will simply suggest you watch it, if you haven’t already.

Maintaining the trust web

As Cristiano wrote yesterday, and as Deborah Schultz talks about in her presentation, there are gradations of friends. There’s a parallel here to trust: There’s also a gradation of trust. Some people I trust almost completely, others I only trust a little bit. Just like friends, these levels are also dynamic —sometimes trust (and friendship) waters down over time, sometimes you make new friends, or learn to trust new people and sometimes someone does something to lose your trust.

Because it’s important to keep your web of trust updated, the idea of letting each site run its own little web of trust doesn’t scale very well. Centralizing your web of trust into a single repository is crucial to making this vision of the web a reality. It also means that this trust relation thing really needs to be a read/write proposal: It must be possible for me, optimally speaking, to very very quickly downgrade or upgrade an individual’s trust percentage in reaction to for example getting screwed on/satisfactorily completing a transaction with someone on eBay. There’s no good reason why OpenID (or the facebook API) can’t be extended in such a way as to make this possible.

While it can be argued that trust is dependent on the type of action. For example I trust my baker to make me a nice pie much more than e.g. some of my friends who can’t cook for beans. I doubt this is needed. After all, I DO trust my friends not to try and saddle me up with a nasty tasting pie I don’t actually want.

Security: Hurdles ahead

Unfortunately it is now time to delve into the issues that will have to be solved before this is going to work.

Primarily, there is identity theft. It’s already a big problem now, but with trust webs, getting your identity jacked is even more of an issue. Lots of spam is already sent from compromised computers. It’s a small leap to go from there to also jacking that user’s OpenID login, so that the spam software can add itself as a trusted resource, or, alternatively, to just identify itself as you. Either way, everyone who trusts the user with a compromised computer now also trusts the spammer. It doesn’t even have to involve keylogging. The world doesn’t change in day, in practice we’ll be stuck with old services using user/pass based login for decades. Random users are very likely to use the same password there as they do for their OpenID provider. In effect we create a single point of failure by centralizing identity in this way.

One solution is to not use a password to identify for OpenID. Instead, use a ‘shape password’ (the act of drawing a little image), or a ‘visual password’ (the act of picking an image or a series of images out of a large set of them). By aggregating all the user/pass stuff into a single page, it is possible to be a little more thorough and intelligent about the way this site verifies your identity. Another option is to use hardware, like a USB key, to serve as authentication device.

Still, none of these solutions are completely impervious to security leaks of some sort. As Bruce Schneier explains, in general security products tend to suck. Designing for failure is going to be necessary.

I don’t really have the answer here, unfortunately. Brighter minds will have to crack this nut.

Going the distance

A couple of web-based services would be made possible with such a centralized web of trust that currently aren’t really feasible. Just to really dig deep into the possibilities, imagine a political system based on this web of trust. Instead of electing a representative based solely on ideas, you elect on trust - basically on the idea that a given individual will be honest and integral about representing you. If a system exists to anonymously inform your representative about your preferences, the representative will then have to filter and interpret the spirit of his constituents’ opinions. Attempts to pander to company lobbyists, or to go too far against the opinions of those who voted such an individual into power should lead to a loss of trust, which will prevent re-election, or, preferably, at some point just means he is ‘fired’ from his job as representative the moment his trust level drops too far.

We here at fourstarters seem to care somewhat about OpenID.

Looks like OpenID developers don’t have to worry about potential patent problems in the near future: sun microsystems has pledged to never use their patent portfolio against any sort of OpenID usage, except against companies that use their portfolio to stifle OpenID. That last one is actually the good news: It means any company that tries to muck up OpenID by trying patent shenanigans has to contend with the idea that sun will start a patent battle. I don’t know if sun even has patents that matter, but I doubt this is relevant: So long as the company has a nice patent portfolio, enough money to pay a law firm, and the economic clout to make it stick, you can sue. It’s one of the reasons every tech professional I know is vehemently anti-patent.

While google might be best known for it, I really like this brave new world, where certain companies have taken the do no evil directive to heart. I guess Sun is aware that the real in-the-trenches techies eventually make decisions on which server hardware to buy, and thus they better get on our good side.

Sun’s “covenant” on patents and OpenID.

A FAQ on the covenant.

(via TheServerSide.com)

Cristiano and myself wanted to add avatar support to Four Starters so that people could put a face to the writer of a post or comment. There already exist some solutions for this, but something more open might be nice.

(more…)