Re: [GNUnet-developers] Chat System, again

[Arne Wichmann]

begin  quotation  from Christian Grothoff (in <address@hidden>):
> (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.

Then that might work. Thanks.

> > > 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?

[...]
> > 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.

This is a much better formulation of what I wanted to say. Thanks.

> > One peer responsible for routing is what i proposed above and am not very
> > happy with.
> 
> How about a pool of peers?

Why not have everyone in a channel know where to send to?

> > 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.

What latencies would be to be expected in gnunet?

begin  quotation  from Nagy Ferenc László (in <address@hidden>):
> On Sat, Oct 02, 2004 at 01:22:48PM -0500, Christian Grothoff wrote:
> > On Saturday 02 October 2004 12:20, Nagy Ferenc László wrote:
> > > (Note that I have deleted the entire original E-mail, mostly beacuse
> > > I agree or have no related suggestions.)
> > >
> > > Can the existing infrastructure be used in a way where channels are the
> > > keywords and messages returned like file descriptions in afs? So messages
> > > are not pushed, but queried repeatedly.
> > 
> > Not as such -- you would post a message to the channel and people would see 
> > it 
> > again and again, how would you 'expire' old messages?
> 
> Maybe an expire feature would be useful for afs, too. Forwarding nodes
> could drop expired answers (3HASH messages), and successful downloads
> could reinsert them with updated expire time.

That might help with those files of which only the 3HASH seems to be left.

cu

AW
-- 
<ThePhonk> *tueteKlammernUeberVariableAuskipp* Dereferenzier Dich, Du
+Miststueck!

signature.asc
Description: Digital signature