(original available at: http://appleseed.sourceforge.net/theory/future.appleseed.php)


0. Introduction

After determining the direction that I feel social networking should follow (in the essay, "The Future Of Social Networking"), I think it's necessary to lay out where I see Appleseed itself going as a software project. Although the project stands incomplete (with very few resources available for further development), I feel as though this project has a certain perspective and approach to social networking that has not been explored by other social networking projects, whether open source or proprietary. It also acts as a preliminary proof-of-concept for that approach as well.

The basic idea of this roadmap is to turn Appleseed into more than just a drop-in social networking solution, but to construct it as a distributed social networking application platform. Basically, what Joomla is to content, Appleseed will be to social relationships and social networks.

This is accomplished with a series of steps. It's a massive undertaking, extending the scope of the Appleseed project even farther than it already has been. But the advantages of having an open source, distributed solution which provides standardized identity, relationships, and privacy settings that developers can plug into, without having to worry about conflicts of interest (such as with proprietary solutions) or an unstable protocol (in the case of social network "glue").

I would be very interested in hearing feedback for this, so if you have any questions, answer, concerns, or praise, please don't hesitate to email me at michael.chisari@gmail.com.

1. The Core: Profiles, Relationships, and Inter-Node Networking

First things first, it's important to define the core functionality of Appleseed as a platform. This is what all Appleseed installations can be guaranteed to provide. There's actually a pretty simple answer to this, seeing as social networking ultimately relies on solving two basic questions: Who are you, and what are your relationships? So, ultimately, the core functionality that all Appleseed installations must have are profiles/identities and friend connections. Other functionality, such as messaging, photos, groups, etc. can all become components that, theoretically, could be switched out with custom replacements. But the profile/identity and friends functionality should be something that should only be changed by an Appleseed release.

The profile/identity functionality is important, because it represents how the user will manage their online presence. But it's necessary to differentiate between Profile and Identity. Your "profile" represents your existential self: Who you are, regardless of how you present yourself to the world. Out of this profile, comes an "identity", which is a derivative of your profile, but presented to the world in a certain context. A profile could, potentially, have multiple identities. For instance, I would set up a profile that is 'Michael Chisari', but have a Work identity, a Friends identity, and any number of separate identities that present information about me differently depending on who is viewing my profile. For instance, if someone who is not logged in or not on my friends list views my profile, they would see a generic view that simply states my name, my age, and my location, and possibly not much else. If a coworker views my profile, they would see my Work identity, which will have information specifically tailored to the workplace, such as my skill set, department, work phone extension, etc. The ability to define separate identities is very important in an increasingly socially networked world.

Appleseed is also capable of having site-specific user profile questions which the administrator of a node can define. This means that a site geared towards motorcycle enthusiasts can define a separate set of profile questions than a dating site. You can then search across sites for answers to questions that exist on some sites, but don't exist on others (skipping the sites where the question isn't defined). However, some mechanism needs to be in place to define a "cluster", which is a set of nodes which share some commonality, so that an administrator of a new node can inherit the definitions of the profile questions. Of course, that brings up the dilemma of how to define and manage clusters. I wasn't lying when I said that we were about to extend the scope of this project significantly.

Second part is relationships. This part has already been solved (although I'm sure not optimally) by the Appleseed software, and was pretty straight forward. Send a request, approve a request, attempt to keep integrity between records on two different nodes. The important part is that the core functionality provide this information to the components, so that the components can then build on these basic relationships. Also included in this is the privacy model based on friends circles that Appleseed also already handles. The ability to restrict or allow access based on a user-defined relationship will also be an important core functionality. The way it is structured now, however, each component needs to be trusted to use this information to restrict/allow properly. Since components should be audited by administrators before they are installed, this can be considered an acceptable risk.

Along with all this is the login functionality, both distributed and local. That's the basics of the core functionality, excluding of course the API that components will be built with and the protocol for communication. Which brings us to the next section...

2. The Appleseed Protocol and API

The Appleseed API is the base set of classes and functionality that components have access to in order to plug into the Appleseed framework. Included is the ability to retrieve friends connections, profile information, the currently logged in user, that user's privacy settings, etc. This functionality has already been pretty well defined, but a lot of work could be useful to make it more consistent and bug free. Documentation is also very important, seeing as these are the building blocks of any Appleseed components.

As for the Appleseed protocol, there are a lot of challenges when coming up with a protocol for an emerging field. The most important thing is to find a way to be both flexible and stable, as well as to provide basic backwards compatibility between protocol versions. Because each component will define a subset of the protocol that will be specific to their component, having a good precedent set by the core of Appleseed will help the project to build and grow in the long term. Ultimately, the goal is to work it out so that one node using Appleseed Protocol v1.1, one node running v2.0, and one node running v1.5 would not lose the ability to communicate. Certain features and options may not be possible, but the lowest common denominator of basic communication should not be lost. Appleseed already attempts to do this, although again, it could use quite a bit of refinement until it's optimal.

3. Building Appleseed Into A Full Component Architecture

This is where Appleseed becomes more of a component architecture. If you look at the code base right now, it's pretty monolithic. Obviously, it wouldn't make much sense to keep it this way, given the potential that distributed social networking holds. The first step is to break out the current code into various components. This includes the following:

    Login (core)
    Friends (core)
    Profile (core)

At this point, this is all speculative. I've considered some of the design issues with building an architecture like this, but the particulars are still up in the air. Most of this comes from my work with Joomla, which I basically like the structure of, but recognize that there's a lot that can be improved on. The structure of the code will be broken into the following elements:


Components are somewhat self-explanatory, they're self-contained applications which uses the Appleseed API to add additional functionality to the node. Included in the component are both the xhtml objects and the code. Libraries are shared extensions to the API that all components have access to. Plugins are collections of functions which can modify the data and output or perform tasks according to triggers. Modules are small content items that can be displayed anywhere depending on the framework. All pretty standard stuff, especially if you've used Joomla before.

Additionally, we have Applications. Applications are the equivalent of Facebook Applications. They're javascript applications that users are allowed to install themselves which have access to a small subset of the Appleseed API. Although this has the potential to turn into the hellish nightmare that is Facebook, the benefits are worth the pitfalls. Of course, security is a concern, so it's important that these Applications are properly scrubbed and restricted. As well, privacy is also an issue, and the API that Applications are provided should follow a philosophy of never knowing more than the user who installs them. More importantly, finding ways to avoid the glut of useless, invasive applications that has plagued Facebook would be a huge step in making Applications more than just novelties. As per usual with social networking, the solution to this problem may be more social than technical.

Next we have frameworks and themes. Frameworks are the basic XHTML layout of a page. Themes are the css (for user installed themes) and optionally images and xhtml (for server installed themes). This will use a system of overrides, similiar to to template overrides in Joomla. The order of importance (from least to most) are components, frameworks, and themes. The most important part of this is ease of development. In my opinion, this means forgoing Joomla's system of doing layout through the administrative backend, and instead focusing on placing functionality within the xhtml specified in either the framework, component or theme.

This may seem overly simplistic, but this is just an overview of how a component architecture would be structured. A lot of planning and work would have to go reworking and building Appleseed into this sort of a platform, but the benefits would be definitely worth it.

4. A Responsible, and Degradable AJAX Framework

One of the ways to make nodes more lightweight, and thus, lower the barrier to entry to running a node, is to utilize AJAX to offload as much onto the client as possible. When building Appleseed up as a development platform, having a well constructed AJAX framework that is robust and encouraged can make sure that components are not hitting the server unnecessarily. One way that I've worked out is to create a framework called DIAF (DOM Instructed Action Framework) which, when a page loads, attaches available functions to the corresponding elements and actions. This also encourages degradability by encouraging developers to write the component with javascript turned off, ensuring that it functions properly in the event of a javascript error.

Again, more work needs to go into fleshing out this aspect, as it is also a very important port of scalability and usability, and good standards and practices should be established along with good code.

5. Multi-Language Support

An extraordinary amount of work needs to be done on this, but the importance of multi-language support cannot be understated. The strength of any social network is dependent on it's ability to grow, and being limited to a character set or language only works against that. Appleseed should support any language that PHP and MySQL are capable of supporting.

6. Building the IM2000 Protocol

At this point, Appleseed utilizes a highly simplified implementation of the IM2000 concept, which is a sender stores system, as opposed to the receiver stores system of SMTP. This has plenty of advantages beyond just providing powerful tools against SPAM. It also allows, for instance, a user to send a file attachment to 10 users, but really only sending a link to the file that can then be retrieved by those who want it, as opposed to pushing out 10 copies of the same file through SMTP. This means it has instant read notifications and the ability to delete an email before it is read. The advantages of sender stores are numerous, and it's potential great, but at this point in general, it stands as an idea that is not yet realized. The momentum of SMTP is too great for a new protocol to push it's way through the crowd on it's own.

This is where Appleseed can come in. What better application than social networking to introduce a new mail protocol. Since most users are accustomed to their social networking mail (myspace, facebook, etc) being closed off from their regular mail, this provides an opportunity to build IM2000 alongside a "killer app" that will build it's popularity without requiring rogue system administrators to offer the option. For anyone interested in rethinking mail systems, this is an incredible opportunity to really flesh out the IM2000 protocol in a real-world setting, and to buil all the necessary features and options that keeps SMTP competitive. And that means that, maybe someday, SMTP and the lack of accountability that a sender stores system allows can be a thing of the past.

7. Connecting The Dots: Creating A Distributed Web Platform

Now what do we have? We have a multi-lingual identity server where multiple profiles can be presented according to which relationship is currently viewing. We have a framework for building distributed social networking applications. We have user-installable applications which can connect in any number of ways across users and across nodes. We have the world's first social network which is built with human society in mind as much as technical details. Developers can take this and run with it, building all types of extensions and tools for visualization and understanding of social networks. We can use this for much more than simply serving targeted ads.

As is the story of this project, resources are the only limit to the potential of Appleseed. Building Appleseed into a robust, extendible and open platform for distributed social networking means infinite possibilities, from everything from politics to economics to culture to even basic human interaction. Social networking is not a fad, it's a technical codification of the basis of human society. And here we have the opportunity to establish the building blocks on which to unlock our imaginations as to what is possible. This essay has not dealt with far reaching possibilities, but suffice to say, it's been a part of the dialogue about Appleseed.

None of it is possible, however, without a solid foundation to build on. Having a stable platform where users can establish profile, identity, privacy, and relationships, and then build out their information and interactions from that base would be indispensable to the future of social networking. At this point, it's only a matter of resources, not a lack of vision.