Group: GNU Social P2P/Design
Contents
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 friend keys to allow for granular permissions.
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.