[Nym3-commit] r169 - trunk/nym3/Client

[laurent at conuropsis.org]

Author: laurent
Date: 2005-04-02 16:22:03 +0200 (Sat, 02 Apr 2005)
New Revision: 169

Added:
   trunk/nym3/Client/README.Dev
Log:
Add development documentation for the client.


Added: trunk/nym3/Client/README.Dev
===================================================================
--- trunk/nym3/Client/README.Dev	2005-03-31 17:39:04 UTC (rev 168)
+++ trunk/nym3/Client/README.Dev	2005-04-02 14:22:03 UTC (rev 169)
@@ -0,0 +1,52 @@
+A reminder of what each file in this directory is for, and what it's supposed
+to do:
+
+ - User.py: this really should be read as "Account.py". It contains
+   objects and methods to create, modify and access an account's data.
+   And it is currently a mess that will need a rewrite.
+   An account consists of the following components:
+    o an identity public key
+    o an encryption public key
+    o an `synbox' or mailbox of received synopsis
+    o a mailbox of received complete emails
+    o a server name where this account is registered
+    o the nymname (name of the account registered at the nymserver)
+    o an idTag used to tag SURBs generated for this account. It should
+      be reasonably random, and above all unique to this account. When
+      message come back to the server this is the sole information we
+      can use to know which account it comes back for.
+    o a filtering policy
+    o some latencies and general options as described in nym-spec §2.1
+    o a nickname which is the handle by which the user choses this
+      account from the CLI. It is unique for this account, and need
+      not be the same as nymname (because the same name can be
+      registered at different servers by the same user), although
+      chosing something like 'nymname at server' is probably easier to
+      remember.
+
+ - Main.py: command line client. Chose the right account from the
+   arguments given and performs the requested operation. The interface
+   is as of yet unspecified. We should mimic mixminion itself I think.
+
+ - Keyring.py: contains all accounts' identify and ecnryption key in a
+   same file, hence protected by the same passphrase. Maybe we can
+   borrow mixminion keyring too.
+
+The directory layout for storing the accounts and corresponding files
+is the following:
+
+    NYMROOT/
+	  | keyring
+	  | tagmap
+	  | account1/
+	  |	   | synbox
+	  |	   | mbox
+	  |	   - params
+	  - account2/
+	  	   | synbox
+		   ...
+
+Each account lives in its own subdirectory, named after idTag because
+naming it after the nickname or the registered nymname might me a
+security issue.
+The tagmap performs the bidirectionnal idTag <--> nickname mapping.