I've been brainstorming about a way to make a distributed social network using OpenID. The goals I have for such a network are:
- Use OpenID for global identities.
- If you have an account on service A, and I have an account on service B, we can call each other friends.
- Some sort of output format that third parties could read to know who your friends are.
What it seems to me is necessary is a way for Alice to make the statement "I have a relationship to Bob", and for that information to get to Bob's "relationship service". Then, Bob could make a similar assertion, or not.
My initial idea was to use OpenID attribute exchange, which has a "push" feature to push data from an external service to your OpenID provider. However, when this data is pushed, it has to be pushed by the OpenID holder -- not by someone else. So that won't work. Alice can't say "I know Bob" and have her service push that info to Bob's service using attribute exchange.
Here's my idea for how the protocol would work. Alice is a human who uses social networking Service A. Bob is a human who uses social networking Service B. And the steps go like:
- Alice logs into Service A.
- Alice tells service A that she has a relationship with Bob, identifying Bob by his OpenID URL. (Example UI: she puts Bob's OpenID into an HTML form. Another UI: she browses to Bob's OpenID page, and her browser identifies it as an OpenID page, and gives her a UI to add Bob to her preferred service, service A.) (Optional: nature of the relationship. "friend", "spouse", "coworker", etc.)
- Service A does some YADIS discovery on Bob's OpenID. If Bob's OpenID service doesn't support OpenRelationships (I just made that up!), we stop here. Otherwise, we continue. Service A will still show Bob's OpenID in Alice's friends list. (Note: what I've described up to this point is essentially FOAF or XFN.)
- Service A redirects Alice's browser session to Service B with an OpenRelationships message. (This message would work like OpenID and OpenID attribute exchange, but with a different namespace.) It includes the following info: Alice's OpenID, Bob's OpenID. Optionally, some tag to note the nature of the relationship ("friend", "parent").
- Service B uses a check_immediate OpenID Auth process to make sure that Alice is actually using the browser.
- Service B then asks Alice, "Are you sure you want to say that Bob is your 'friend'?" Alice confirms it.
- Service B stores the relationship info.
- Service B redirects Alice to Service A with an OpenRelationships confirmation message. (Alt: if Alice cancelled, it would return an error message instead.)
- Service A stores the relationship information.
- Optionally, Service B sends a message (email, IM, SMS, whatever) to Bob letting him know that Alice noted her relationship to him. Message may include an URL that Bob can click to confirm the relationship. Otherwise, the service might tell him next time he logs in, or some other way.
- At his option, Bob can make a similar statement about Alice, and the process runs in reverse.
- At his option, Bob can decide whether or not to show Alice's statement in his "friends list". If Alice is a stalker, a friend slut, or just someone Bob doesn't like, he may not want her listed, even though he'll stay listed on HER friends list.
There are some tricky parts here. There'd have to be some anti-spamming measures in place; Service B might check a whitelist/blacklist to determine whether or not it accepts friend statements from Service A or from Alice. Also, there may be some throttling (only X many statements in Y seconds from Alice or from Service A). Also, a CAPTCHA at step 6 would be useful.
An almost identical process would be used to remove a statement about friendship ("I'm no longer Bob's coworker") -- it'd just need a different verb at step 4.
Lastly, it's recommended that each person's friends list is available either in XFN or in FOAF format. This friends list would have to be discoverable from your OpenID, too.
Some fine points that would need more thought:
- Vocabulary for relationships. Is it fixed by the protocol, or can people define other kinds of relationships. For Open Source developers, for example, there may be a vocabulary to express relationships like "worked on a project together", "fixed bugs of". Some question of what to do when Service A receives a statement about a relationship in a vocabulary it doesn't understand.
- Comment text on the relationship ("coworker" + comment "at Great Big Corp.").
- Transitive relationships ("friend", "spouse") and complementary relationships ("parent" + "child", "employee" + "employer").
- Some sreg-like info may travel back to Service A from B. Examples: full name, avatar image URL.
- I'm not 100% sure, but I think Service A and Service B have to be OpenID providers. Obviously things are a lot easier that way. It may be possible to use delegation here, though.
Comments appreciated. I'm going to work on this a little more, and then try and write up a bare-bones draft spec to submit to the OpenID.net site sometime next week.