Re: [GNUnet-developers] Chat System, again

[Christian Grothoff]

(Note that I deleted entire paragraphs from the original E-mail that I did not 
feel like responding to, mostly because I agree or have no suggestions.)

On Friday 01 October 2004 13:34, Arne Wichmann wrote:
> > 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.
>
> Hm. On first glance this seems to be tied to the machine a person is
> sitting at. This would be inconvenient, persons tend to be changing
> machines now and then. And such a concept should be movable. Which may mean
> to transfer a hash file from one machine to another, but it still should be
> movable.

Pseudonyms are RSA keys that are distinct from the hostkey (which is tied to a 
gnunetd instance in the network).  So people can easily take them from 
machine to machine.

> > GNUnet can do discovery and hopefully soon provide a DHT, but that does
> > not provide you with a chat-specific anonymizing routing algorithm. Also,
> > what are your reliability and latency goals?  Total message ordering? 
> > 3-way end-to-end handshake with all participants, one peer responsible
> > for routing (and in a position where that peer could selectively drop
> > messages and no one would know)?  What delays between messages are
> > acceptable?
>
> Latency requirements of a line-based chat systems are not so bad. Irc still
> works ok with latencies of about 10 seconds. More might still be doable.
>
> Reliability is desirable, and I know that this is not so trivial.
>
> There are some rough ordering requirements, such as answers should come
> after questions, but no total message ordering.

How do you determine that one answer belongs to a certain question?  I would 
not phrase it in those terms.  How about if I see message X and then type 
message Y, everyone else should see Y after X.  But how to ensure that in a 
cheap, distributed manner is again a different question.

> One peer responsible for routing is what i proposed above and am not very
> happy with.

How about a pool of peers?

> What is the question about delays?

Oh, I was just wondering about latency again.  There is end-to-end latency and 
then there are per-hop delays that peers introduce to be able to do better 
message scheduling. In practice, you can clearly pick the per-hop delay, but 
a certain end-to-end latency is what you want to achieve.

Christian