[nym3-devel] Starting?

[Laurent Fousse]

--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Jean-Ren=E9 Reinhard [2004-05-01]:
> Hi,
>=20
> I think that it would be reasonnable to develop the client and the
> server in parallel, it would be easier for testing.

I agree.

> +++++++++++++
> Let's start with the server:
>=20
> what he has to do :
>=20
> _maintain nym accounts
>  [User adjustable options]
>       - Identity public key of the nymholder
>       - Encryption public key of the nymholder
>       - A filtering policy (described below)

Maybe we can leave the filtering policy for the moment, and think of a
way to implement this later?

>       - A maximum unencrypted synopsis time, in 30-minute
>         increments. (described below)

=46rom the spec I don't see the use of the synopsis latency. For what
purpose would the nymserver want to keep synopsis in clear for some
amount of time?

>  [Administrator adjustable options]
>       - Maximum number of queued emails
>       - Maximum email size
>       - Maximum disk space used
>=20
> the question whether it is good or not to have a lot of User
> adjustable options has been raised.

My first suggestion is to drop the unencrypted synopsis time.

> In addition to these data, for each nym we have to store :
>       - A set of emails, each consisting of:
>             An encrypted synopsis [XXX which can remain unencrypted
>             during a certain amount of time, specified by the user
>             XXX]=20

As I already said, I don't see the point.

>			  An encrypted emails
>=20
> [XXX what kind of structure do we use for this? a mbox-like one? or
> files stored in a rep? XXX]

I like maildir-like format. One email per file is simple to use and
saves us the trouble of mbox and escaping special characters.

> Each message also has:
>             A 32-byte message identifier
>             A 'sent' tristate: "Nothing sent", "Synopsis-sent",
>             "Sent-In-Full".  A time of receipt.

I'd suggest we keep each message in a seperate file, along with its
synopsis, and have a database (simple DB would be enough) where the
keys would be the 32-byte identifier and the value would be the tuple
of the 'sent' tristate, time of receipt and name of the file storing
the mail.

Do we really need 32 _bytes_ ? 32 bits should be more than enough for
an identifier.

>       - A set of SURBs
> [XXX idem? XXX]

Each one in its file stored in a directory. For the moment the
directory structure would look like :

/nym1/msgs/msg1
		   msg1.syn
		   msg2
		   msg2.syn
		   ...
	 /subs/1
		   2
		   ...
	 /msgs.db
	   |
	   0xbeef -> (msg1, "Nothing sent", 1083491046)
	   0x4217 -> (msg2, "Synopsis sent", 1083491278)
	 =20

> _process incoming messages, that's to say=20
>    _mail from a nym to a receiver (special case if the receiver is a
>    nym on the same server?)

It means extra work: what is the benefit ?

> the type of the control messages are described in nym-spec.txt. I
> think it would be better to implement the CREATE control message
> first. (in other words the creation of an account on the server),
> and then proceed from there.

Good idea. How do we specify the challenge protocol ? The type I
nymserver has a simple protocol :

 - generate a random string,
 - wait for any message contenaing this string and mark the nym as
   created when it receives it.

My suggestion for the challenge response protocol :

 - in response to a CREATE request, the nymserver generates a random
   string which is included in the CREATED response.
 - in response to a CREATE2 request containing this random string as
   challenge response, mark the nymm as created and reply with a
   CREATED response with empty challenge.

We *could* make the challenge protocol more complicated, but since
control messages to the nymserver are already signed, and
surbs-response are encrypted, I'm not sure we need to.

> ++++++++++++++++++
> What the client should do :
>=20
> _send and receive control messages to/from the nymserver.
> _provide the server with surbs
> _under heavy load retrive synopses explicitely, present the list of
> retrievable message to the user, request that the nymserv sends
> message to the nymholder or deletes messages
> _if sending configuration cpontrol message (eg to change the public
> key of the nymholder) keep the message until it has been aknowledged

=46rom the synopsis/email retrieval point of view, I see the nymclient
as one improved newsreader.

> ++++++++++++++++++
> programming stuff
> what module will we use for manipulation of files, directories...
> I already know unix module, which seems to be compatible with
> Windows as long as we don't use fork and kill :=20
>=20
> http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/book-ora166.html
>=20
> but you may know no a better one?

Did I mention the fact that I'm really an OCaml AMATEUR?

--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAlMtpRoAVF6FpbSsRAi7hAJ9CEQT4fRjlHUQ1Du9qQn1gg02s/wCgkpu6
cfmzBkBKLRJb6451UgZB7to=
=6TcF
-----END PGP SIGNATURE-----

--0OAP2g/MAC+5xKAE--