\documentclass[dvips,11pt]{article}

\usepackage[pdftex]{graphicx}
\usepackage{url}
\usepackage{fullpage}
\usepackage{algorithm2e}
\input{rdefs}
\begin{document}

\section{Adda - The chat client}
We named our chat application as ``Adda''.
Here we try to chalk out the different functionalities of Adda.
Following functions need user's interaction to complete
\begin{newenum}
  \item {\bf Connecting:} The user starts the Adda client and connects to
        Kademlia server on the same host.
        Client accepts an alias from user and stores a value containing the
        alias and address (ip:port) where it is listening to chat
        The key is hash of the user's public key.
   \item {\bf Adding contacts:} User can manually add ANY hash of public
        key and alias pair, which will saved in a contacts list.  The
        default state for contacts added this way will be ``offline''.
        Additionally, when an unknown remote user contacts the client
        with a chat invite, that user sends its public key and chosen
        alias.  The local user may save this contact.  The contact
        will be shown as ``online''.
   \item {\bf Finding contact's address:} The user can search for the
        address of the contacts whose public key is available to him
        through Kademlia.  If an address is found, and a PK/SK PING
        challenge succeeds, the contact is shown as "online" and the
        address is shown with the alias.
   \item {\bf Sending invite:} User $A$ can at any time invite
        another user $B$ to chat, including a short message or
        greeting.  If $A$ is already chatting, the client first
        informs all chat members that he is inviting $B$ (not asking
        permission) and receives all current logical clocks.  In that
        case, $B$ is provided with a list of chat members and the MAX
        of all the logical clocks, $L$.
  \item {\bf Joining chat:} If $B$ declines, $A$ will send a cancel to all
        members (cancel overrides a late join at all clients).
        If $B$ accepts, he will connect to all members and tell all, including
        $A$, at clock ($L+1$).
        All members must replay their own messages sent after ($L+1$) to $B$.
  \item {\bf Leaving chat:} Any participant can choose to leave the chat any
        time.
        Graceful leaving is where they send a message to everyone else in the
        group about his leaving.
        While in case of network failure or his Adda is shut down, the others
        will be notified when the TCP connection will break.
  \item {\bf Removing peer from chat:} All the participant can vote someone out
        of the group chat.
        In that case, someone proposes the idea of voting someone out.
        Everyone replies to that message saying accept or reject.
        In case more than 50\% (except the victim) accept to remove him,
        everyone will drop connection with that person.
  \item {\bf Typing/sending chat:} Finally after setting up the keys with
        correct participants the user is all set to send chat.
        We currently create a one to one TCP connection to send or receive
        messages.
        This guarantees fast message delivery.
        We can move from this clique connection to something different but we
        leave that for future application.
\end{newenum}

\noindent \\\\
Above these we need to support two more important functions which does not need
active user interactions but should be done under the cover.
\begin{newenum}
  \item {\bf Ordering chats:} We want to convey a global view of the chat to all
        the participants.
        Its very difficult when multiple people are sending chats simultaneously
        and causal dependencies of the chats.
        But given the fact that the participants are human and they can clarify
        the discrepancies in ordering of the messages, we just focus on
        maintaining a global eventually complete ordering of messages.
        To be precise, our goals are that (a) all users eventually see the same
        chat transcript, including membership change events and (b) the delay
        between a message being displayed and a later message being ordered
        before that message is kept low to avoid irritating or confusing UI.
        We used Lamport's clock to get the partial ordering of the messages and
        broke the tie amongst `simultaneous' messages by the hash of the public
        key of the sender (why hash? just more complexity for no savings, 
        \rcnote{because we will probably save the hash anyway in the file, and hash
          is much easier to handle for even python than 1024 or bigger keys}).
        We have discussed in detail about the approach and their effect in
        chatting in next section.
  \item {\bf Setting up keys:} We want to make chatting completely encrypted.
        So, before someone start chatting to other participant they need to
        setup a private key of communication.
        We use SSL connection library provided by Twisted to setup the secure
        channel between two participant.
\end{newenum}

\end{document}
