Group: GNU Social P2P/Design

From LibrePlanet
Jump to: navigation, search
m (→‎Design Objectives)
m (→‎Design Overview)
Line 20: Line 20:
 
The design features a federated key/value storage abstraction.  <ref>I will use the term "path" instead of "key" to differentiate from cryptographic keys.</ref> 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.
 
The design features a federated key/value storage abstraction.  <ref>I will use the term "path" instead of "key" to differentiate from cryptographic keys.</ref> 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, and the encryption key is further encrypted.  The encryption key can be decrypted through control points through the Store.  A control point can be represented to the end user as a tag or as a friend.  Permission is "additive" - content can be decrypted if it can be accessed through any of the control points.
+
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 ===
 
=== Core ===

Revision as of 00:25, 31 May 2010

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. [1] 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:

  1. ↑ I will use the term "path" instead of "key" to differentiate from cryptographic keys.
Retrieved from "https://libreplanet.org/wiki?title=Group:GNU_Social_P2P/Design&oldid=16504"