[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Chat System, again

From: Marcos D. Marado Torres
Subject: Re: [GNUnet-developers] Chat System, again
Date: Wed, 29 Sep 2004 20:00:12 +0100 (WEST)

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

Mind Booster Noori

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]