Group: GNU Social P2P/Design

Sample Usage

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

Overview

Design Objectives

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

Design Overview

The design features a federated key/value storage abstraction. All content is stored in a tree of path / value pairs ("Store"). A remote Store can be mounted read-only at a path. Remote nodes can be notified of new content at a path.

Cryptographic methods are used to implement granular permissions. Values in the Store are encrypted. The encryption key is further encrypted through one or more other keys (attached to "control points") to allow for granular permissions. A control point can be represented to the end user as a tag or as a friend. Permissions are "additive" - content can be decrypted if it can be decrypted through any control 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

UI

• Display Interface

• UI to Core Protocol
  • Get/Put/Delete
  • Mount/Unmount
  • Set control key
  • Send to remote
  • Request from remote
  • Listen to events

Display

Targets:

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

Notes: