diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 86 |
1 files changed, 46 insertions, 40 deletions
@@ -10,19 +10,26 @@ achieves our goals. TASK LIST ========= -- Highest priority: comm, privchat, ep +- High priority: invite - Medium priority: dht, dep -Architecture for communication primitives (comm, MED) ------------------------------------------ +Invitation system (invite, EASY) +-------------------------------- -Find the right abstraction(s) for communiation channels. +A user may generate invitation tokens: an invite token is a signature of the +invited user's pk by the inviter user's sk. The user that redeems the token +writes some data that is saved temporarily in the user's identity shard, which +might be stored by a 3rd party node for instance if we are on mobile devices +that cannot connect directly. + + +Networking improvements (net, HARD) +----------------------- Here are some things to keep in mind that we want at some point: -- Encrypted point to point communication (to communicate private info after ACL check) -- Flooding, gossip, RPS +- RPS - Congestion control, proper multiplexing of feeds - Proper management of open connections to peers @@ -43,22 +50,6 @@ Second option: custom DHT protocol (we probably won't be doing this anytime soon, if ever at all) -Epidemic broadcast (ep, EASY) ------------------- - -When a shard recieves new information from a peer, transfer that -information to some other neigbors. - -How to select such neighbors ? - -a. All those that we know of -b. Those that we are currently connected to -c. A random number of known peers - -Best option: those that we are connected to + some random to -reach a quota (for example 10 or so) - - Partial merges, background pulls, caching (cache, req: bg, HARD) ----------------------------------------- @@ -78,22 +69,6 @@ infrequently used pages, for examples those of old data that is only kept for archival purpose. -Private chat (privchat, MED) ------------- - -Proof-of-concept for private things: shard for private chat between two people. - - -Invitation system (invite, EASY) --------------------------------- - -A user may generate invitation tokens: an invite token is a (sk, pk) plus a -signature of pk by the user's sk. The user that redeems the token writes some -data signed by sk that is saved temporarily in the user's identity shard, which -might be stored by a 3rd party node for instance if we are on mobile devices -that cannot connect directly. - - User groups and access control (groups, req: sign, HARD) ------------------------------ @@ -124,8 +99,8 @@ access control decisions (obviously these can only run when an identity with admin privilege is running). -Shard dependency management (dep, MED) ---------------------------- +Shard lifetime and dependency management (dep, MED) +---------------------------------------- Some Shards may pull other shards in, under certain conditions. For example a stored folder shard will just be a list of other shards that we all pull in. @@ -181,3 +156,34 @@ a correct signature from a certain identity. We can have a special "identity" shard type that enables storing profile information such as nickname or other information that we might want to make public. + + +Architecture for communication primitives (comm, MED) +----------------------------------------- + +- Encrypted point to point communication (to communicate private info after ACL check) -> SHS +- Flooding, gossip -> netgroups + + +Private chat (privchat, MED) +------------ + +Proof-of-concept for private things: shard for private chat between two people. + + +Epidemic broadcast (ep, EASY) +------------------ + +When a shard recieves new information from a peer, transfer that +information to some other neigbors. + +How to select such neighbors ? + +a. All those that we know of +b. Those that we are currently connected to +c. A random number of known peers + +Best option: those that we are connected to + some random to +reach a quota (for example 10 or so) + +Implementation: netgroups (lib/net/groups.ex) |