In my vision for social networks of the future I wrote about how I think they might look like. In this post I want to dig a bit deeper and write down some use cases. Let’s start with the data model upon which they are based.
The data model
The main object is a Person. A person has a profile and contacts. Contacts are Persons themselves. A connection between two Persons is a relationship which might have some attributes. One might be the type of contact which could be „friend“, „close friend“, „family“, „business contact“ and so on. Of course a relationship could also be of two types, e.g. „family“ and „business contact“.
This might be something other people call the „social graph“.
The relationship types could also be seen as groups, thus there would be groups like „friends“, „familiy“ and so on.
A person needs to be identified somehow so that you know two Persons are actually the same. You might use the OpenID for that but then again it should probably be open which method is used. In the end it might also be useful to store a list of possible identites, e.g. homepages, email addresses, profiles on other servers and so on.
The main scenario
Having defined the data structure there needs to be a place where it should be hosted. Today it’s hosted in every social network and you have to redefine it every time. This is even more complicated as people might be known under different names on different networks. In the future it should still be possible to use different names but your social graph should only be stored centrally on one server. It is similar to OpenID where you can use your identity on many sites but it’s only really stored on a central server (of your choice of course).
The use cases are now about how this contact list/social graph is manipulated and used.
Terms
Profile Server – this is the mentioned central server which stores your contact list and more.
Social Application – a web site which offers some functionality which works on your social graph, e.g. flickr for photos.
The Use Cases
Add a new contact on your central profile server
- A Person gets the identity information (might be an OpenID) from another Person and add it as a new contact on it’s profile server. The Person additionally might add this new contact to one or more of it’s groups.
- The new contact should be notified of this action so it can reciprocate this measure.
- Alternatively this might be the results of such a notification. In this case nothing needs to be done anymore.
Remove a contact on your central profile server
A Person selects a contact and deletes it. All permissions formerly given to that contact are deleted as well on every social application. Optionally this contact should be notified that it got removed from the Person’s contact list.
Define/change group membership of a contact
Groups can be added, edited and deleted. Contacts can be added to one or many groups and removed again. Groups can be used in many ways. One way is to define permission on social applications for different groups. Think of flickr and it’s use of family, friends and everybody. They might additionally be used for messaging, for aggregating content from their members (imagine „all photos from my family“) and so on.
Add a new contact on a social application site
This is basically the same as 1. but in this case it’s not done on the profile server itself. The process though stays the same as in the end the profile server will do the work.
Define permissions on a social application site for a group
On every social application site which you visit and which supports permissions you can at any time define permission settings for any of your individual contacts or contact groups (which are defined on your profile server). This might include who has access to your assets or who can comment etc.
Visit a new social application for the first time and initialize your profile
When you enter a new social application for the first time you might give your identification information, such as an OpenID, and the site can retrieve profile information, friends and groups from your profile server. You can decide which information you want tp share with this new application. Additionaly you can decide which friends or groups get which permissions. Again think of flickr where we have predefined groups already. These could be replaced (or mapped) to your own groups.
Somebody adds you as a new contact on a social application site
In this case you will get a notification that somebody has added you. This will in the end take place on the other Person’s profile server. This will contact you and give you a chance to add this Person as a contact, too. Notification could work e.g. via E-Mail but other mechanism could be used as well. In the end the email will contain the identity information and maybe some profile information about that Person and a link to your profile server to add this Person to your contact list.
Permissions
Some example of what you could define via permissions:
- who can see me on some social network
- who can contact me?
- who can see which assets on a social application
- who can change them
- who can comment on them
- who can see when I am online at that application
- who can subscribe to my activity stream or which parts of it
- who can see which part of my profile
Per social applications there might be even more permissions possible.
Disclaimer
All these thoughts are very much in the wild about what I would like to have in the future. As you can see there is a lot of discussion about permissions as I think these might get more and more important in the future. Right now most of the social networks out there usually only have a general permission by adding somebody as a contact or friend but not a more fine grained solution. But if we look at things like virtual worlds and how they might be part of the whole thing soon then we certainly need a more focused view on permissions. Esp. Second Life shows how difficult this is.
Tags: usecases, dataportability, diso, socialnetworks