Group: GNU Social P2P/Design
m (moved User:Teddks/P2P/Design to Group:GNU Social P2P/Design) |
m |
||
Line 18: | Line 18: | ||
* Separation between the Core component and UI component | * Separation between the Core component and UI component | ||
− | * Define two APIs - [[Group: | + | * Define two APIs - [[Group:GNU_Social_P2P/Design/Core2Core|Core to Core]] and [[Group:GNU_Social_P2P/Design/UI2Core|UI to Core]] |
* Implement APIs on top of multiple low level transports | * Implement APIs on top of multiple low level transports | ||
* Core does not have access to any plaintext content | * Core does not have access to any plaintext content | ||
Line 30: | Line 30: | ||
=== Sample Usage === | === Sample Usage === | ||
− | Some [[Group: | + | Some [[Group:GNU_Social_P2P/Design/End2End|end to end examples]] could be a good starting point. |
=== Core === | === Core === |
Revision as of 17:12, 16 August 2010
Contents
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 two main components: the UI and the Core. The Core is further composed of a router and a Store.
The Core implements a federated key/value storage abstraction. [1] All content is stored in a tree of path / value pairs ("Store"). A remote Store (belonging to a friend) can be mounted read-only at a path. A user's nodes can be notified of new content from the remote Store.
The Store layout is standardized to allow end-user applications to interoperate 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 UI is fully trusted and has access to the user's identity - their private key. For security sensitive individuals and corporations, the UI 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 the UI for privacy sensitive data.
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 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
UI
- Display Interface
- UI to Core Protocol
- Get/Put/Delete
- Mount/Unmount
- Set permission keys
- Send to remote
- Request from remote
- Listen to events
Display
Targets:
- Browser
- IM Client (XMPP)
- Desktop
- ... etc.
Notes:
- ↑ I will use the term "path" instead of "key" to differentiate from cryptographic keys.