Zach Broderick - Brandeis University



Zach Broderick

26 April 2008

COSI 98a – Hickey

OpenDSN

OpenDSN: An Open, Distributed Social Network

Abstract

In the following paper I will present OpenDSN, a conceptual framework for an open, distributed social network. As the name suggests, OpenDSN is an alternative to the closed, centrally located social networks such as Facebook and MySpace that currently dominate the internet. Through an open, standardized communications protocol and design specification, it allows an infinite number of independently owned and operated social networks distributed across the internet to be part of one large homogenous social network, forming an additional “social layer” on top of the internet. To achieve this, OpenDSN was designed with four conceptual goals: seamless context switching, information migration, information synchronization, and information control. Seamless context switching means allowing the user to navigate the network without being too aware that he or she is changing servers, in order to create the illusion of a homogenous network. Information migration entails allowing a user who has a profile on one network to join another network and have his or her information imported from the first, so that he or she can quickly join networks without repeatedly typing in personal information. Similarly, information synchronization allows the user to update their information on one network and have it propagate to all of the others that the user is a member of. Finally, information control means having control of your own personal information and who sees it, in stark contrast to the policies of most of today’s popular networks. In this paper I will elaborate on the ideas behind OpenDSN and suggest some ideas for implementation.

1. Introduction

The phenomenon of online social networking is still only in its infancy, but it is growing at a breathtaking pace. Already ubiquitous among young people and college students, it is fast spreading to other demographics as well. Sites like MySpace, Facebook, and LinkedIn have hundreds of millions of users between them and are growing every day with no end in sight. They serve many different purposes, with niche networks serving small communities becoming increasingly popular. Like the web itself, online social networking is likely going to become a cultural staple in the foreseeable future.

Before we continue, let me formally define what I mean by online social networking. Online social networks are websites where a person can create a profile of themselves, which may include a picture and other personal information such as favorite music and movies, depending on the community the network is intended to serve. The user can then typically browse the profiles of other members, send them messages, and add them as “friends” or “contacts,” creating a link between themselves and the other member. Many networks also allow their members to join “groups,” sort of sub-networks of members for a more specific purpose, while others allow users to install a variety of custom applications for anything from blogging to posting classified ads. Online social networks are used for many different purposes, such as keeping tabs on people, looking up strangers, organizing events and projects, and just simply communicating, among other things.

As I mentioned before, however, online social networks are still in their infancy, and thus still have many problems stemming from their immaturity. The most important of these, and the one I am attempting to address in this paper, is the issue of openness. Today’s online social networks are still closed systems, centrally located and owned and controlled by a single (usually corporate) entity. This single entity owns all of the personal information collected by their network, and can do what they please with it. They control how their network is used, and if the site goes down or the entity goes out of business, the user is out of luck. Users must create a separate profile with separate credentials for each network they want to join, much of which is redundant, because the networks do not interoperate with each other. Users wanting to create their own network or functionality are limited to forming groups and using the site’s API, if there even is one—they cannot create their own network on another server and simply plug-in.

So far, there have been only minimal attempts to combat this issue of closed-ness. Google developed the OpenSocial API, which allows a developer to write an application that will work with any social network that implements it. OpenID allows a user to use one set of credentials across multiple sites, but the ability to migrate personal information is minimal and not well developed. Content management systems such as WordPress and ELGG allow administrators to deploy their own social networks, but as of yet they cannot interoperate with one another. None of these solutions even comes close to addressing the problem.

OpenDSN attempts to solve this problem completely and comprehensively by being both open and distributed, as opposed to closed and centrally located. OpenDSN allows anyone to deploy and manage their own social network on their own server, while automatically being plugged into the larger, internet-wide network consisting of other people’s social networks through a common communications protocol. On the other end, a user can create a profile and store their personal information on a network they trust, even one they own, and then control how that information is propagated to other social networks on the internet. In this way, control is transferred from a central, often untrusted entity to both the end-user and administrators of various interoperating social networks.

2. An Overview of OpenDSN

OpenDSN is shorthand for Open Distributed Social Network. In its current state, it is only a concept—no formal specification has yet been developed, and no implementation has been deployed, though both are in the works. What I am presenting here is simply the idea of OpenDSN and the design requirements it must follow in order to achieve its goals. The design is actually very simple, but it has the potential to become a very powerful and useful system.

Let us begin by going over the typical use cases for both the administrator of an OpenDSN social network and an end-user. The administrator wants to create his own social network for some particular purpose; let us say he is captain of the Brandeis Ultimate Frisbee team and wants to create a network where players can interact and plan events and practices. He downloads a software package that implements the OpenDSN specification, and deploys it on a webserver. He then downloads several server-side application modules that also adhere to the specification to add the specific functionality he desires for his network. He then downloads an OpenDSN CSS style sheet to give his site the look and feel he desires, and he now has his very own custom social network for the frisbee team. The real beauty however is that his network is automatically interoperable with any other OpenDSN network on the internet, as we will see in the end-user case next.

Let us now imagine a player on the frisbee team named Alex. Alex goes to Brandeis, which also has its own OpenDSN social network, and Alex is a member of that network. Because he trusts Brandeis, Alex also made this network his “home” network, putting it in charge of safe-guarding his personal information. Alex’s captain informs him that the team now has its own network, and that he needs to join it. Alex goes to the site and signs up by pointing the frisbee network to the URL of his home network. His credentials and personal information (at least, the info he wants the frisbee network to have access to) is propagated from the Brandeis site to the frisbee network, so he only needs one set of log in credentials and does not have to re-enter his personal info. Now whenever anyone views his profile on either network, it shows that he is a member of both networks, and a visitor can simply click on a link in his profile at one site and be taken to his profile on the other. If he ever needs to update his personal information, he simply goes to his home network, where he can see all his information from all of the networks he belongs to, and any changes he makes will automatically be propagated to his other networks.

The above use cases present us with four design requirements that must be followed in order to achieve such functionality: seamless context switching, information migration, information synchronization, and information control. The following sections will introduce each of these requirements in detail, and give suggestions as to how they might be implemented.

3. Seamless Context Switching

As stated earlier, the overall goal of OpenDSN is “openness,” and as the administrator use case demonstrates, we want creative control to be put in the hands of each individual social network. This means each OpenDSN network being deployed will likely be unique, with its own applications, its own look and feel (via CSS or something similar), and serving its own community, which requires its own set of personal information. For example, the Brandeis network may require its users to specify their major and class standing, while the frisbee network might only care about the person’s nickname and field position (as a side note, such information, like ‘field position’, I will call “properties” and can be thought of as key/value pairs). All of these factors form the “context” of a social network.

As we saw in the end-user case, a person can and will likely be a member of multiple social networks, and thus multiple contexts. Thus when another end-user is viewing a person’s profile and navigating through multiple networks (contexts), and therefore switching servers, the experience needs to be relatively seamless. Rules need to be established as to how a profile will be displayed relative to the context. The following use case demonstrates these rules better than a dry and overly-complicated explanation would.

Alex is a member of three different OpenDSN networks. First, he is a member of the Brandeis Computer Science Department, which has its own network. The look and feel of the site is a “Scheme Theme” with little lambda signs everywhere as decoration. The COSI network asks each member what his favorite OS and programming language is when signing up, in addition to the usual basic information such as email address. He also belongs to the Economics department network, which is decorated with dollar signs and asks its members what classes they are taking and who their favorite Econ teacher is. Finally, he is a member of the TRON Ultimate Team, which is decorated with Frisbees and contains his field position and team nickname.

Zach is a friend of Alex’s and is also in the COSI department at Brandeis. He has forgotten what Alex’s favorite operating system is, and just has to find out, so he logs on to the COSI network site and brings up Alex’s profile. The profile is decorated with lambda signs as per the site’s look and feel, and it shows Alex’s basic information, as well as that his favorite OS is Ubuntu Linux and that he prefers Java for programming. Also displayed is a list of his friends on the COSI network, of which Zach is one, because Zach is also a member of the COSI network. Below that is a list of the networks Alex belongs to with links: COSI, Econ, and TRON. Zach has always curious what Alex’s nickname was, so he clicks on the TRON link.

Zach is now brought to Alex’s profile on the TRON network, which is located on a different server at the school. The profile is decorated with Frisbees, and there is a different picture of Alex sporting his uniform, and under “profile information” it has his team position and nickname, but NOT any mention of his favorite OS or language. His friends list is different, consisting exclusively of members of the TRON network, though some of them are also COSI members. Absent from the list is Zach, who is not a member of TRON. Under that is the same list of three networks. This time, Zach clicks on the Econ link, and is brought to Alex’s profile on the Econ server, which has dollar signs and his favorite Econ teacher…

The use case explains fairly clearly what is meant by seamless context switching. The look and feel of the profile, as well as what personal information is being displayed, is entirely dependent on which social network the profile is being viewed on (the context). Each person’s profile contains a list of all of the other networks he or she belongs to, and so someone viewing that profile can quickly and easily jump to that person’s profile on another site, without really noticing they are now connected to a different server. They will notice however that the context of the profile has changed, matching the context of the new network. This allows the various networks to be loosely connected but still maintain their unique identities.

Of course, in this example we assumed that all of the information was public, which is not realistic. For example, because Zach was not a member of TRON, he would likely, depending on Alex’s privacy settings, not be able to see his team nickname, which might be a team secret. However, because Zach is not only a member of COSI but also Alex’s friend on the COSI network, he would be able to see all of Alex’s personal information on the COSI network. I will discuss this in more detail in the information control section.

4. Information Migration

One of the problems with traditional online social networks that I discussed earlier is that they do not interoperate, and thus end-users must re-enter their personal information every time they join a new network, as well as remember several different sets of credentials. If they want to log in to multiple social networks each day, they must re-enter their credentials for each network. This is an unfortunate side-effect of the centralized, closed model that OpenDSN attempts to fix by implementing a system of information migration. Whenever an end-user signs up for a new social network, he or she can enter the URL of another OpenDSN network he or she already belongs to, and his or her information can be imported from the old network into the new one, and the same credentials can be used. Another use case might perhaps illustrate this best.

Zach has decided that he wants to minor in Business, whose department shares a social network with Economics. He points his browser to the Econ site and goes to the signup page. On the page is an optional set of form fields asking for an email address, password, and URL of another OpenDSN network the new member may already be a member of. Zach is a member of the COSI network, so he enters his credentials and the COSI URL and clicks submit. He is redirected temporarily to the familiar COSI network, where he is presented with a list his personal information properties with checkboxes next to them. The title of the page asks “What information would you like to export to the Econ network?” Zach checks off most of his general information like class standing and birthday, but leaves favorites OS and programming language unchecked as the Econ department likely does not care about such things. He then clicks submit, and is brought back to the Econ signup page, where many of the basic information form fields have been autopopulated with his information. He then fills out a few Econ-specific form fields like favorite Econ teachers and such, and after hitting submit he is an official member of the network. The whole process only took a couple of minutes, and his credentials are the same for both the Econ and COSI networks. In fact, if he navigates from network to network by clicking on the links in his profile as described in section 3, he only needs to login once in order to visit all of his networks (this will be elaborated on in section 6).

As can be seen from the above example, the process of information migration is simple and uses a model similar to that of OpenID. The end-user specifies the URL of another network, and his or her personal information is pulled from that network into the new one. By forcing users to enter their credentials for the old network, we ensure that their e-mail and password is consistent across all of their networks.

Before we move on, there is one design issue with information migration that necessitates some discussion. There are two possible models that could be used for information migration—centralized and peer-to-peer. While peer to peer may sound more consistent with the spirit of OpenDSN, I have found that the centralized model makes considerably more sense without sacrificing our design goals. Both are viable options that deserve further consideration, so I will lay them out here for analysis.

In the centralized model, the end-user designates one network (usually his or her first) as their “home network” or “trusted network.” This network will hold all of the personal information properties entered on all of his or her OpenDSN networks, and it is this network’s URL that the user will give when joining new networks. After joining each new network, all new personal information that the user entered is sent back to the home network. There are two significant advantages to this approach. First, it gives the user one central location from which he or she can manage his or her personal information from every network he or she belongs to, without having to visit each one. Secondly, it allows for less complex privacy controls, which I will talk about in section 6. The downside to this is that we again find ourselves dependent on one entity, an entity that could go belly up and take all of one’s information with it. However, the fact that you can choose any network, even one your run yourself on your own server, as your home network alleviates this issue significantly. Secondly, there are several design measures that can be taken to guard against the network going under, such as having multiple home networks or being able to download all of your information into an XML file and upload it to a new home network. These seem to be acceptable trade-offs for the benefits gained by having a centralized model.

In the peer to peer model, no network is any different than the other in terms of data migration. When signing up for a new network, the user can specify the URL of any one of his or her networks to pull his or her information from. This seems more in line with our goal of decentralization, and lacks the downsides described above that are the result of relying on a central information repository. However, the peer to peer model of information control, which I will discuss in section 6, is extremely complex. For example, if there is not one central location with all of an end-user’s information, then he or she may have two networks with disjoint sets of personal information, both sets of which he or she wants to import into his or her new network. This becomes even more complex when certain networks cannot know about certain others, and synchronization just throws another wrench into the machine. It is quite possible there is an elegant algorithm to achieve this model, but for now the centralized model appears more practical.

5. Information Synchronization

A natural corollary to the problem of data migration is that of consistency. Currently, the average end user might be a member of several social networks such as Facebook, MySpace, and LinkedIn, which may have overlapping information, such as which school the user is attending. If the user transfers schools, he or she has to go to each network and update his or her personal information, which can be a tedious task, especially for changes in personal information more frequent than a transfer of schools. Thus OpenDSN has the design requirement of synchronization, whereby if information is updated on one network, it is relatively quickly reflected on all of the user’s other networks. This concept is fairly simple and I do not believe it warrants a use case to illustrate it. However, a suggestion for implementation may be in order, as it fits really well with the aforementioned idea of data migration, and with the centralized home-network model.

In the centralized data migration model, when the user submits the signup form for a new network, all of the form fields are sent back to his home network as well as to the network he just signed up for. We imagine these fields of personal information to be key/value pairs, as this seems to be the most natural abstraction. When the home network receives this information, it can compare the incoming keys to the keys it already has. For those that are the same as existing keys, the home network makes a note that that key is present on this new network, along with any other existing networks. If the end-user then changes that key, say while logged into his home network, the network looks up the key and alerts all networks associated with that key to the changes. If the user instead updates the key on one of his or her satellite networks, that network alerts the home network, which then proceeds to alert all of the other satellite networks attached the that key. In this way, all of the end user’s personal information stays consistent across networks with minimal effort on his or her part.

6. Information Control

Any system that deals with an end user’s personal information needs a system of control. Unlike some of the above issues, the current generation of social networks have made an effort to address this problem. Facebook especially now has very granular privacy controls that specify who and under what circumstances other users can see or even search for your personal information. This works fairly well for the closed, centralized model; however, how do we implement privacy controls in an open, distributed model such as OpenDSN? How do we control information being sent across the internet by multiple independently owned and operated networks? The answer is actually not all that complex (assuming you are not using the peer to peer model for data migration) and flows naturally from the previously discussed design parameters. The information control model I’m about to discuss is certainly not the only one that could fit with our current design requirements, but I believe it to be one of the simpler and easier to implement choices available while still guaranteeing an acceptable degree of control.

In this model, when a user signs up for an OpenDSN network, next to each form field is a drop down menu with three privacy settings: public, network-only, and friends-only. If the field is set to public, anyone browsing the network, even if they are not a member of the site or are not logged in, can see that item of personal information. If it is set to network-only, then only members of that particular social network that are logged in can see the item of information. If it is set to friends-only, only people who are friends with the end-user on that particular network can see the information. These three settings are the most natural levels of privacy a user would desire and does not require a tedious amount of fine tuning.

Let us return to the seamless context switching use case for a demonstration of how this works. Zach is currently logged into the COSI network and is viewing Alex’s profile. Because Zach is both a member of COSI and Alex’s friend on the COSI network, he can see all items of personal information that Alex has on his profile. Zach looks down at Alex’s list of networks and notices Econ, which Zach just joined earlier. Zach has not yet friended Alex on the Econ network and wishes to do so, so he clicks on the link. Before transferring Zach to the Econ network, the COSI network looks at Zach’s list of networks to make sure he is a member of the Econ network before blindly sending over his log in credentials. It sees that he is, and so the COSI network seamlessly transfers Zach over to the Econ network along with his email and password. The Econ network checks Zach’s credentials and automatically logs him in, transferring him to Alex’s profile on the Econ network. Looking at Alex’s profile, Zach can only see the information Alex designated network-only and public, but not friend-only, because they are not yet friends on the Econ network. For example, Zach can see that Alex’s favorite Econ teacher is Mr. Coiner, but there is no mention of his political preference, which Zach knows is there because he had to fill it out when signing up for Econ.

Zach then clicks a link to friend Alex on the Econ site. Alex confirms they are friends, and now Zach can see that Alex is a Democrat, because he is now privy to all of Alex’s friends-only information. Zach then clicks on Alex’s link to the TRON network, of which Zach is not a member. The Econ network checks Zach’s networks and confirms this, and simply transfers Zach to the TRON network without sending any credentials. The TRON network sees that Zach is not a member, and transfers him to Alex’s profile, but he can only see information that Alex marked as public, which is only his name and picture.

As can be seen from the above example, the solution is very simple but also very elegant and functional. Controlling what information is seen by end users is only half of the equation, however. Sometimes we may not want certain social networks to know information about us, or to know about the existence of other social networks we belong to. Here is an example: Alex is a member of the COSI network, as well as the Hiatt network, which helps students find jobs. Alex is running his own home network on his personal computer, so that he controls all of his information. Alex is also a member of the Cross-Dressers social network, which is not quite professionally acceptable and may impact his chances of getting a job. He also doesn’t want his friends in the COSI department to know that he is a cross-dresser. Similarly, he does not want people on the Cross-Dresser network to know his real name and what dorm he lives in, for fear that someone might show up and embarrass him.

Now, in this situation, it is probably wisest to just create two separate identities rather than combine both with OpenDSN integration. However, there are many less extreme examples where creating multiple identities would be a real hassle and the risk of a unified profile is not so extreme. For example, many people have pictures and information on their Facebook profile relating to their casual life that they would not want potential employers to see on LinkedIn. Thus it makes sense to have some mechanism to control how information propagates from network to network, especially when some of those networks are not to be trusted. The model I am presenting here naturally falls into place from the previous design requirements, and while it has not been 100% fleshed out at this time, it is not hard to imagine doing so in the near future.

The natural point of information control between networks is during the signup period, when the user inputs the URL of his home network and is redirected and asked what information he or she would like to share with the new network. The user need simply leave unchecked those items of information that he or she does not want the new network to know about. Less obvious however is that these items of information can include which other networks the user belongs to. For example, if Alex is signing up for Rudy Guliani Fan Club, he might want them to know that he is a member of Cross-Dressers but not that he is a member of COSI and Hiatt. He would simply uncheck the COSI and Hiatt networks, and whenever someone viewed his profile at Cross-Dressers or the Guliani Fan Club, it would only show that he was a member of those two networks; the same goes for COSI and Hiatt. Thus Alex can lead two separate lives while still managing all his information from his home network, which acts as the “gatekeeper” of information, because it is trusted.

7. Conclusion

In this paper I have presented OpenDSN, a conceptual framework for an open, distributed social network meant to solve many of the problems of today’s closed, centralized social networks such as Facebook and MySpace. OpenDSN allows anyone to set up their own social network and instantly be a part of a larger, internet-wide network of other OpenDSN social networks through a standardized communications protocol and design specification. End-users can become members of multiple social networks without having to retype their personal information or log into each of their networks separately, and when they update their information on one it is reflected in all of the others.

I have described in detail the four design principles behind OpenDSN, which include seamless context switching, information migration, information synchronization, and information control. Each of these design requirements complements the other, resulting in a simple and elegant model that naturally flows from them but which is also very functional. I have presented detailed use cases to illustrate how each of these design principles is to be implemented. If implemented correctly, OpenDSN or a similar approach could power the next wave in the rapidly growing phenomenon of online social networking.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download