[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Chat System, again
From: |
Arne Wichmann |
Subject: |
Re: [GNUnet-developers] Chat System, again |
Date: |
Sun, 3 Oct 2004 23:19:05 +0200 |
User-agent: |
Mutt/1.5.6+20040722i |
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