Service_Federation

Service Federation in Red

Unlike Friendica which was designed for "federation" amongst various free and commercial "social networks", Red has a completely different set of design goals. Plugging in the ability to cross-communicate with social networking sites can be potentially quite difficult. I'll attempt here to summarise how it might be done.

Nomadic Identities are Incompatible with Social Network Federation

This is the primary stumbling block. Red identities are not tied to a single server. Social networking identities generally are. If you were to offer federated access to a non-nomadic identity framework, Red members must be advised that they will be limited to communicating with that network from one server location. Posts from alternate locations will not reach the other network (without making friends with the same people on both server). Likewise comments and replies will only go to the server where that person was initially federated.

A future development task might be to reduce the impact of this issue by ensuring that the "primary hub" for a particular channel takes responsibility for federating nomadic posts to/from the external service network.

Basic Identity

Red uses a long hash with a low probability of collision as a network-wide identity. Additionally this is combined with a signature to guarantee that the probability of identity collision is reduced to infinitesimal quantities. This signature will not be available on many other social networks. So my proposal is to use the identity url or "handle" as the basis for what we call a "guid" in Red. Then if a public key is available, we'll take the identity URL, concatenate the public key and hash this with a whirlpool hash. We will use this as an 'xchan_hash' or globally unique address. It will be up to the individual service plugin to authenticate and prove identity. The xchan_hash is used in Red's internal tables as a unique key.

It is mandatory that the identity guid is constant and unchanging in order to produce the same hash repeatedly. For this reason, if it is a URL or DNS based entity, it should be normalised with respect to http vs. https, and domain.com vs. www.domain.com . It is OK if this string is not resovable via DNS, but it must be repeatable. Likewise if a service can have both a numeric ID and a "nickname" to identify an individual account, choose one or another and ensure that identifier is always used for resolving accounts. If the nickname is "optional" on the service, this means the numeric ID must always be used.

Hub Locations

Red allows more than one "hub" or server to be linked to an account. Federated servers will only have one hub, and the hub signature will be meaningless.

Permissions

Red allows a rich set of permissions to be set for any contact. Many networks use a binary permission model (friends or not friends). The driver for that network will be required to map permissions appropriately, and in the case of conflict, choose the "most suitable" closest match. For instance if a network "friendship means that members can see the streams of others and also send private mail, setting a value in Red where the stream is available but private mail is not will require the driver to mediate and perhaps over-ride the user choice.

Photos and Files and Profiles

There are cases where permission conflicts will mean that content is unavailable to the external network. For instance photos which are protected and available on to specific persons likely cannot be transmitted to an insecure service. If the service cannot provide a means of authentication for the intended viewer to view the photos, they will be unavailable.

Driver

Currently a prototype social network driver exists in include/ProtoDriver.php. We will need to work with the first federated service developer and ensure that we provide virtual functions for all necessary communication acitivities. The entry points envisioned are:

abstract class ProtoDriver {
    abstract protected function discover($channel,$location);
    abstract protected function deliver($item,$channel,$recipients);
    abstract protected function collect($channel,$connection);
    abstract protected function change_permissions($permissions,$channel,$recipient);
    abstract protected function acknowledge_permissions($permissions,$channel,$recipient);
    abstract protected function deliver_private($item,$channel,$recipients);
    abstract protected function collect_private($channel,$connection);

}

Photo library, webpage, and file management are not currently anticipated to be represented in the federated social networking driver.