Group: GNU Social P2P/Design

From LibrePlanet
Jump to: navigation, search

Design Overview

The Social P2P system is a platform for social application. Standardized environment and protocols allows the creation of diverse applications, user interfaces and integration with legacy systems.

A user's node is composed of three main components: the UI, the Agent and the Core

The Core implements a federated key/value storage abstraction. [1] All content is stored in a tree of path / value pairs ("Store").

The Store layout is standardized to allow end-user applications to inter-operate and replaced with alternative implementations.

The Core has no plaintext access to content or the social graph and therefore can be located at a less trusted location while maintaining a constant presence. The Agent is fully trusted and has access to the user's identity - their private key. For security sensitive individuals and corporations, the Agent would run on user controlled hardware.

Cryptographic methods are used to implement granular permissions and to protect content in the Core. Values in the Store are encrypted. The encryption key is further encrypted to one or more friend keys to allow for granular permissions.

Translators (integration plugins) to legacy systems can be co-located with the Core for public information, such as microblogging, or with Agent for privacy sensitive data.

Design Objectives

  • Separation between the Core component and Agent component
  • Define two APIs - Agent to Local Core and Agent to Remote Core
  • Implement APIs on top of multiple low level transports
  • Core does not have access to any plaintext content
  • Agent has a private key which defines the owner's identity
  • Core has access to Agent public key only
  • Once content is permitted to a friend, that content can be retrieved from the Core even if the Agent is currently down.
  • Granular permission system

Design Details

Sample Usage

Some end to end examples could be a good starting point.

Core

  • Storage
    • Path/value store
    • Remote stores can be mounted at specific path
  • Core to Core Protocol
    • Request the value at a path
    • Send the value at a path

Agent

  • Agent to Local Core Protocol
    • Get/Put/Delete (manipulate the Store)
    • Set permission keys (define which friends have access to a path)
    • Listen to events (such as notifications from a remote Agent)
  • Agent to Remote Core Protocol
    • Get (retrieve contents of a path)
    • Enqueue (send data to the remote agent associated with the Core)

UI

Targets:

  • Browser
  • IM Client (XMPP)
  • Desktop
  • ... etc.

Notes:

  1. I will use the term "path" instead of "key" to differentiate from cryptographic keys.