THE FUTURE OF THE APPLESEED PLATFORM
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)
Messages
Photos
Groups
Journals
Search
Comments
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
Libraries
Plugins
Modules
Frameworks
Themes
Applications
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.