Re: [GNUnet-developers] Chat System, again

[Marcos D. Marado Torres]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 28 Sep 2004, Christian Grothoff wrote:

> Well, the transport layer provides some functionality helpful for
> anonymization (notably link encryption, batching, delaying, constant-size
> messages, relatively constant traffic due to message scheduling), but that is
> not necessarily sufficient to obtain anonymity.  An anonymous routing
> protocol is still required.

Can't SEP use the routing protocol that the file-sharing system uses?

> I would use / recycle the existing pseudonym construct in GNUnet: the hash of
> your public key is your unique pseudonym; you can choose a nickname and sign
> it to get a more user-friendly handle, but if two nicks conflict the public
> key is the ultimate unique handle.  Anything else is unlikely to work in a
> distributed setting anyway.

My idea in this field was to use the hash as the "real nickname" and relate a
"chosen nickname" to it. Everytime someone new enters SEP, a database in each
client connected at the time is updated, and if there is some other different
hash with that nickname, then a request to change nickname must be sent. On the
other side, the guy who finds that there is already another person with that
nickname may have the ability to, in his client, change the nickname that will
appear in messages from that hash. This doesn't warrant against repeated
nicknames, but will prevent people to think they're talking to someone when in
fact they aren't.

> So suppose we have channels that are identified by some name (or hash of some
> name?).  How do you (or can you) prevent listening of users on the channel
> that are not listed as participants (users that run some peer in the network
> that routes traffic of the channel should still not be able to listen in
> without being visible to the other users, right?  That means re-keying for
> every join/leave, which introduces a big DoS problem (rapid join/leave)).  Do
> you want to be able to ban users from participating in a channel (operator
> status?).  How would that be implemented?  Do we want open channels (anyone
> can join) or should we for security require 'invite only' channels?

There must be the abillity to create public or private rooms. Room names must
be unique. The creator of a room is it's owner (maybe we can add a feature that
lets "give" the ownership of a room to another person). "tell's" (private
messages) must be achievable between people in different rooms. The owner must
have the ability to turn the room public or private, fixed or not fixed. People
in a room (or owners of some room) must have the ability to give or take
invitations for that room. Room owners must have the ability to "kick" someone
from that room. And yes, every join/leave in a certain room will create a DoS
problem.

Mind Booster Noori

- -- 
/* *************************************************************** */
   Marcos Daniel Marado Torres       AKA        Mind Booster Noori
   http://student.dei.uc.pt/~marado   -   address@hidden
   () Join the ASCII ribbon campaign against html email, Microsoft
   /\ attachments and Software patents.   They endanger the World.
   Sign a petition against patents:  http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFBWwY/mNlq8m+oD34RAtZ6AKCkcWaBX2+e202v7B02uMpkOtS4qQCffNbQ
jUIlGOueGQoEaPkZ/mrg2zs=
=xoYo
-----END PGP SIGNATURE-----