Re: [GNUnet-developers] GNUnet and chat ?

[Christian Grothoff]

On Friday 09 April 2004 07:16, Christian wrote:
> After reading into the AFS code i got a little but frustrated by the
> complexity :) I dont intend to stop looking into it and trying to
> contribute. But at the moment i would like to see the chat in a working
> state. So i decided to put some time into it. It should be "usable" by now
> but i doubt the chat will be reliable. If i understand the GNUnet layer
> right there is no guaranty to get my packages through to everyone. But a
> protocoll for chat i think forbids something like a response or retransmitt
> for economic reasons. 

I disagree. You can have confirmations (especially if they are short, possibly 
confirm multiple messages and are routed efficiently). 

> It might be a bit difficult to provide a chat system 
> at a low bandwidth cost. Or is there a way to get the packages through
> whatever it costs if they can wait long enough. (like 5 seconds or so)

Chat should not require much bandwidth to start with (who types that fast?). 
The latency is a more important question, and that probably depends more on 
if you want to hack up an anonymous chat or an ordinary chat.  In principle, 
both should be possible on top of GNUnet.

> Another point is: Does the GNUnet layer allready communicate with other
> nodes what kinds of data they can process. If an old Node can not do
> anything with chat-data why should we send it there. At least if it does
> not WANT to have the data (i.e. for bandwidth reasons).

Actually, it's less about old nodes vs. new nodes or supporting chat-protocol 
vs. not supporting chat protocol.  The actual messages should, as much as 
possible, only be relayed to the members of the particular chat room (and not 
broadcasted as it's done by the current code).  

The distinction between nodes that support the chat protocol and nodes that 
don't is then only to be made in the first stage where the chat room is 
formed (sign-on, find open rooms, etc.).  And there, peers that don't support 
the chat protocol should just be treated as peers that are 
'unreliable' (since a good implementation should never assume that any other 
peer actually does what they claim to do).  Sending a bit more traffic to 
peers that don't understand it this way should not be a problem since this is 
just done when the protocol is initiated and not for the actual bulk of the 
data.

At least that's my 2 cents.

Happy hacking

Christian