Abstract
Finaly, after four years talking about it, gnunet-chat is on
GNUnet's roadmap (for GNUnet 0.7.4), and there has been some discussion on how to implement it.
This article aims to provide a description on how could gnunet-chat be implemented, and should be seen as a "Request For Comments".
Background
In this section I'll try to give you some background on what are talkers and what is GNUnet, so it turns easier to explain how and why should we mix both concepts together.
Talkers
Talkers are text-based online virtual worlds to which multiple users are connected at the same time to chat. People log into the talkers remotely (usually via telnet), and have a basic text interface with which to communicate with each other, in a somewhat similar way to how
MUDs work.
When a user connects to a talker, he enters a room (a "virtual space") that has some links to some other rooms in order to make some kind of map. Talker users can talk privately to another talker users, wherever they are in the talker, chat publicly to someone (in a way that others near can watch them talking) in generally (to all of those who are in the same room as he is). Shouting is also possible, making all the talker users to hear what that user has to say. Of course, users are able to move themselves from one room to another, unless the room where they're walking towards is closed.
GNUnet
GNUnet is a framework for secure peer-to-peer networking that does not use any centralized or otherwise trusted services. Since such a framework provides the means to do any kind of network communications, virtually any network application you might want to do is feasible using this network. A first service implemented on top of the networking layer allows anonymous censorship-resistant file-sharing.
gnunet-chat
So, if we have a simple form of chat that is a simple form of a virtual world (as a matter of fact that are
claims that a talker is "the simplest possible Virtual World"), and then a way to make any kind of communication in a censorship-resistant secure and anonymous fashion, why not combine both things and create a
secure, censorship-resistant and anonymous virtual world and way to chat?
Let's think, first, on the concepts that needed to be implemented.
avatars
Each gnunet-chat is able to have any number of avatars (meaning a "virtual
persona"), although I'll talk (for simplification purposes) in only one avatar per node. Each avatar (also to be called user or node) has properties such as a
name (mandatory), a
description (optional), a
keyring (optional) and a
location (optional). All of this are self-explanatory, but let me
empathize some things: the description should be in ASCII. Also, the keyring is to be taken as in the original sense of the word: a set of keys to several places. If a room is locked, the avatar can only walk in if he has the key needed to do so. Finally, the location is mandatory if you are online, and needed to know where to spawn him when the user is connecting to the gnunet-chat world. If there's no "location" set, he must spawn in a never-private are, the "by default" room of gnunet-chat.
rooms
Each room also has a set of properties: a
name (mandatory), a
description (optional), a
owner (optional), a
gate (mandatory), and a list of
links (optional). The name is to be how the room is referred to: something like "Jungle", "island", "castle"... The description is optional and is to be something like an ASCII banner. That way you can have a room called "island" with a description like
You open your eyes and find yourself on a deserted island. The sky is blue
and the water is clear. Suddenly, you hear voices and laughter far away.
Excited, you follow the sounds to a calm beach. Hiding behind the bushes,
you see... MERMAIDS! A couple of them spot you and signal you to come near
them. "Hi! Follow us to a magical world!" a little mermaid says. The
mermaids dive into the ocean. You don't hesitate and dive in after them...
or a room called "Jungle" with a description like
WELCOME TO THE JUNGLE!
("\''/").___..--''"`-._
`o_ o ) `-. ( ).`-.__.`)
(_Y_.)' ._ ) `._ `. ``-..-'
_..`--'_..-_/ /--'_.' .'
(il).-'' ((i).' ((!.-'
-----------------------------------------------------------
Of course that if a room has no description, then no description will be shown.
The original creator of a room will be automatically it's owner, The owner can offer that room to another avatar (and the room changes ownership), or to revoke ownership (and the room belongs to the virtual world and no avatar will have it). Being the owner of a room is important since only the room owner can lock the gate (which has two states: locked or unlocked). If one room is unlocked anyone can come in, but if it is locked only the key owners can enter.
Finally, each room can have a list of links (if a room hasn't one then it will have the same behavior as if it has an empty list). Each link represents a pointer to another room, showing a "virtual physics connection". Once again, only room owners can create or remove room links.
Rough scheme of implementation
While the user interface will let the user refer to a room by its name, the gnunet-chat node will talk to the network not by it's name but by it's public key.
If a node X wants to go to an open established room, it broadcasts a request to all chat-enabled GNUnet nodes. Other nodes ("Y") that are in that room will update their info, seeing that avatar as present in the room, and reply to him with an advertisement.
If a node X wants to go to a closed established room, it broadcasts a request to all chat-enabled GNUnet nodes. Other nodes ("Y") that have the key for this channel answer and request an AES sessionkey S for encryption of chat messages. The joining node X must not reveal the room key to the answering node Y, because this node might be someone pretending to be a member of Y trying to get the channel key. Instead, the joining node generates the random sessionkey S, encrypts it using the room key and sends the result to the answering node Y. Y decrypts the session key and uses the sessionkey to encrypt a channel advertisement. If either X or Y don't have a valid key for the room, the decrypted advertisement is invalid.
An advertisement consists of the room description, and a list of avatars (public keys of the members of the room).
Nodes achieve anonymity by acting as relays for other nodes. Since all relays decrypt new messages, they have to be signed by the author to guard against forgery. To detect censorship, members of a channel regularly post user statistics ("user A: 10 msgs, user B: 23 msgs") that every nodes compares with local statistics.
Further work
I hope this article will lead the interest parties into an healthy discussion of this model. Furthermore, and before the actual implementation of such a thing, this concept (specially the scheme of implementation) have to be enhanced to describe all possible commands (actions) an avatar has, and what are the reactions for it (and how they're achieved).
If you want to comment on this, please feel free to do it here on my blog or
by e-mail. I intend to post a copy of this on
GNUnet's community so you'll be able to see some reactions there too (or so I hope).
