aboutsummaryrefslogtreecommitdiff
path: root/TODO
diff options
context:
space:
mode:
authorAlex Auvolat <alex@adnab.me>2018-10-12 11:10:17 +0200
committerAlex Auvolat <alex@adnab.me>2018-10-12 11:10:17 +0200
commitd15d5fbfc5133a9d0f0d99dbbfc023849f61cc37 (patch)
treedaedfd26af6978301b2633a338a137a874876d1f /TODO
parent6dcc2eefc3c8db0cadd7300536527dbd1905fa48 (diff)
downloadshard-d15d5fbfc5133a9d0f0d99dbbfc023849f61cc37.tar.gz
shard-d15d5fbfc5133a9d0f0d99dbbfc023849f61cc37.zip
Update TODO, refactor a bit
Diffstat (limited to 'TODO')
-rw-r--r--TODO86
1 files changed, 46 insertions, 40 deletions
diff --git a/TODO b/TODO
index 177f292..dd13e1d 100644
--- a/TODO
+++ b/TODO
@@ -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)