secushare Architecture

secushare Architecture

Architecture for actual private social interaction

For reasons we have elaborated in the Scalability & Paranoia paper we prefer to entrust a distributed network of nodes run by people in our social neighborhood rather than a federated network of servers which are well-intended but by design easier to corrupt.

The distributed architecture still allows us to have all the functionality users typically expect from a social network, in fact it also allows for things which are hard to do in a federated web type of approach.

Routing

As we discussed in the paper, we think privacy is best achieved using a distributed network of agnostic relays such as GNUnet, Maidsafe, A3 or Tonika. In the last years we have integrated a PSYC implementation into GNUnet.

This lightning talk gives you an idea what sort of things we use from GNUnet. It provides us with encrypted communications over all sorts of transports including direct mesh networking between wifi devices.

Some of the traffic intensive GNUnet services such as file sharing are not necessary for secushare, so they can be turned off in the configuration. We leverage GNUnet's sybil-attack resistant routing mechanism and its GNU Naming System (GNS) while combining it with PSYC's distributed social graph.

How can I leave a message if I need to shutdown my node?

It is part of our architecture to have agnostic relays act as offline storage and packet routers. From the first rendezvous, some people in your first contact's extended social network will probably own long-lived nodes that can easily maintain encrypted data for you. The more you make contacts, the more non-stop running nodes your node will know, so you distribute things evenly.

This is similar to the supernode concept in other P2P architectures, only in secushare people have a good motivation to contribute processing power and bandwidth, because they know it will be used by themselves and their social network.

The network will provide services to you while disconnecting your legitimacy to use it from your actual identity. Agnostic nodes will want to store data for you without actually knowing where it came from and where it is going to.

How does it scale to billions of users?

That is discussed in scalability.

Implementation

Core Daemon

The core should be a daemon running on the user's machine, written in a native language (we are doing it in C) in order to maximize likelihood that free operating system distributors will ship it as a 24/7 tool running in the background. Scripting or bytecode languages would reduce this degree of acceptance.1 For most operating system vendors a dependency on a non-stop running Java application would probably be considered a no-go (Java being the most popular contender).

Things look different in the mobile arena where Java is a well-established alternative to C and the gap in performance isn't as big. Still, compiled programs run tighter to the hardware and have hardly as much random-access memory requirements. Java can still be used for higher layer applications and user interfaces, but the core daemon is in C.

Recently, GNUnet has been ported to OpenWRT, allowing for wifi routers to participate in the network natively. Here, writing the code in C is again a winning factor.

Our PSYC daemon, which is implemented as a GNUnet service, provides efficient multicast data distribution, extensible messaging and basic social modeling using the pubsub paradigm.

Cross-Platform User Interface

When thinking of social services everyone seems to think in terms of a web-based interface, and it will in fact be useful when using secushare on a router box. We could seek collaboration with a federated social web platform for the user interface, but in fact we just need to rip out the HTML, CSS and Javascript as everything under the hood is very different from the usual rails and sequels.

Interestingly, the technologies to do cross-device development for mobile devices use HTML, CSS and Javascript, too. They are employed as user interface description languages rather than as web pages. These days doing a web-style user interface doesn't mean you aren't going to be tightly integrated with the operating system.

Native User Interfaces

We are currently implementing a smartphone-compatible responsive user interface in Qt/QML with a special focus on usability: making social networking easier to use as it is with Facebook and the like while at the same time enabling privacy by end-to-end encryption in every gesture.

Further details

A more detailed view on APIs and layers is given on the protocol page.

Footnotes:

1 Most Linuxes are set up in such a way that after boot up and log in only native applications keep the system running. Script languages are only used temporarily to do some short-lived jobs or as a wrapper to launch some binary executables. No distributor likes to break this good habit of efficiency.

Top