Group: GNU Social P2P/Design
(→Design Overview) |
(→Design Objectives) |
||
| Line 17: | Line 17: | ||
== Design Objectives == | == Design Objectives == | ||
| − | * Separation between the Core component and | + | * Separation between the Core component and Agent component |
| − | * Define two APIs - [[Group:GNU_Social_P2P/Design/Core2Core| | + | * Define two APIs - [[Group:GNU_Social_P2P/Design/Core2Core|Agent to Local Core]] and [[Group:GNU_Social_P2P/Design/UI2Core|Agent to Remote 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 | ||
| − | * | + | * Agent has a private key which defines the owner's identity |
| − | * Core has access to | + | * 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 | + | * 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 | * Granular permission system | ||
Revision as of 22:55, 20 November 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 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
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.
