TECHNOLOGICAL BOTTLENECKS AND IMPEDIMENTS IN DISTRIBUTED SOCIAL NETWORKS.

This document will discuss some of the theoretical problems in creating a distributed social network. Since a working implementation of the Appleseed Social Network is not yet developed, this document is currently a work in progress.

Given the basic idea for how the Appleseed Social Network will work, there are a few obvious examples of what possible bottlenecks might be encountered. Below are those examples, along with ideas for how to work around them or prevent them should they arise.

1. Latency issues when searching through the network.

Although searching in a social network is a very small part of it's functionality, it presents one of the bigger technological challenges. Since we start at Node A, and require Node B to contact Node C, if, for some reason, Node B goes down or times out, then we've effectively lost that branch of the social network. Even if Node B isn't down, but has a high server load and takes extra time to return with a response, this can make searching a distributed social network much more tedious than searching a social network contained in a single location.

Possible Solutions:

For latency, the immediate solution that comes to mind is to create a heirarchy of search results. For instance, start with the results that come directly from the site the user is on. Then, once those are presented, move out a level, and so on. Using XMLHTTPREQUEST to update the page as data is retrieved, or using it to retrieve data itself wouldn't do anything to speed up the process, but would help to give the user an impression of a faster search.

As far as a node going down, an option is to keep a cache of an extra level out. A friend record on Node A would also store cached information about a friend on Node B, so that if Node B does not respond, the cached information can be used instead. This, however, presents an unwieldy set of rules to follow, as the cached data cannot be authenticated against Node B. If the user on Node B had removed user on Node A as a friend, then the cached record wouldn't reflect that.

Another option is to simply replace the searched for user's icon with a question mark, and a message that states that their site is not responding. This, however, is not an optimal solution.

Looking at peer-to-peer networks such as Gnutella and Freenet might provide some insight as to how to deal with this issue.

2. Authentication And Misappropriation

The problem of spam and 'spimming' are a concern with social network websites. Because they provide an easy way to not only contact people with advertisements, but also to contact their friends, and their friend's friends, they have become a target of unethical advertisers. A distributed social network adds another element, whereby in a traditional social network you could create a dummy user account, and use that to maliciously use the site's resources, now it becomes possible to create even a dummy site to act as a network node in the ASN. How do we prevent this from happening?

Possible Solutions:

When a user adds another user as a friend, and that person reciprocates, that creates a basic trusted relationship. This can be used to limit the amount of misuse by possibly running untrusted communications through a spam filter. This causes a problem, however, for those users who have not entered into that relationship but are legitimate users. Technological solutions such as suspending accounts which send messages rapidly in succession may also work, especially if some form of bulletin exists for notifying large groups of people, so that CC'ing of messages aren't necessary. This, however, presupposes that the malicious user won't write their own software for doing such a thing.

In a lot of ways, technological limitations can be set to make it difficult to spam through the network. However, completely eliminating the possibility will happen directly after the same process occurs for regular email.

The problem of false nodes on the network is another dillemma. One possibility is for each site to have a trusted list of domains that they allow incoming communications from. This limits the effectiveness of a distributed social network. It's possible to propagate the trusted domains list, so that once a new trusted domain is added, it's trusted domains are merged with currently trusted domains. This could possibly work, but also could create a series of enclosed networks that don't talk to each other, which would defeat the purpose of the ASN.

Whatever the solution, it's important that it remain true to the principles of a distributed network. Therefore, having a centralized repository of trusted Appleseed sites is not an acceptable solution.

3. Interaction With Other Appleseed Sites.

Could a user who is on Node A be able to post to groups on Node B? What mechanism for authentication could be used? If a group maintainer on Node B adds a user from Node A to the group memberlist, how can the site be sure that the user from Node A is really who they say they are? This ties in with the question above, but takes it a step further. Making Appleseed sites completely interoperable would be the ultimate goal of this project, and that can't be done if users can't be properly identified.

Possible Solutions:

One possible way is if Appleseed is set up so that user from Node A can interact with groups from Node B, but only through Node A itself. To the user, it never looks as though they've left Node A. All data transfer is between Node A and Node B, and Node A presents simply an interface, and then a trusted relationship with Node B (assuming the issue of trust outlined in the previous problem has been addressed).

Another option is to have seperate passwords for seperate sites, but give the option to link a profile back to a single site. This is the less optimal solution because it provides a much less seamless experience for the user.

Regardless of what method is used, it's important that the potential for abuse is taken into consideration whenever a new feature is designed. It may be a hard decision to make, but it is usually best not add a feature if it cannot be protected against a malicious user.

April 25, 2005 - Revision 0.1