gnunet-chat: the next-generation talker?



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


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


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 cencorship-resistant secure and anonymous fashion, why not combine both things and create a secure, cencorship-resistant and anonymous virtual world and way to chat?

Let's think, first, on the concepts that needed to be implemented.


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 emphatize 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. Finaly, 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'ed, he must spawn in a never-private are, the "by default" room of gnunet-chat.


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

`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 automaticly 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 behaviour 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).


  1. I dont know very well gnunet protocol but i know similar p2p protocls, i think gnutnet realy do isn't for server centrix server like others protocols, bitorrent and emule, but it can be implement a chat protocol inside any p2p. whith de good client any think could be done.

    first two problems:
    - users, users are chating they need do know person they a talking is da same person with the same nick name of yesterday. solution: login system on talker server?? above all gnunet protocol's;
    - if are many gnunet-talker, one person connect to only on at the time, or what?
    if login name on one server A could be a another login/nickname on server B...
    no centric server, remember...

    (to be continue...)

  2. GNUnet is different from those other p2p networks: it is completely de-centralized. You don't do a "good client" for GNUnet, you do an application (like gnunet-chat) that uses that network resource (the gnunet network itself), but since each node is equal you don't have centralized info anywhere. A table that compares GNUnet with other file-sharing protocols can be found here.

    You can't have centralized info (which could be a point of failure on censorship-resistance, anonymity and security), so you can't have a "login system on a talker server". Each user has to be identified with an ID, consisting of a pair of private/public key. While users will refer to other users in their UI by their nickname's, gnunet-chat nodes will refer to another gnunet-nodes by their public key. Only the right user has the private key, so only him can decrypt the message in it.

    I don't see the point on having various instances of gnunet-chat running (like there are many talkers nowadays), because anyone can build their own "corner" in the virtual world.

  3. Uzume4:02 PM

    Hmm...interesting concepts but I honestly do not know enough about gnunet and have some doubts.

    One is decentralized storage with access rights. I know what has happened in IRC-like spaces (of course they are not very highly decentralized but they have some degrees of such on larger networks). Perhaps the "room" linking and "gates" would solve that but I also am not so sure.

  4. Anonymous4:34 PM

    This sounds like a very interesting idea - however with so many people out there wanting more little 'add-ins' like smily faces, or sound effects for their IM chats, I don't think it will really catch on amoung the masses.

    As for those that currently use talkers. Less and less are using them it seems - most appear to go for the 'theme' or just because that's where they have always gone. I can see having a theme for your room or rooms on your own place and inviting others in - who are then now subject to the rules created by you in that space. How is this really different then going to a talker? Expect you won't get any of the custom cmds or features that have been set up in a talker? Or could you do that, have it so it remembered when you are in Jo's place there you have 15K in chips to use in his poker game or that you only have 5 to use on Sally's place over there for hangman.

    seems like a good idea but there are many good ideas out there that never go anywhere because people just won't change from what they have.. M2C

  5. Well...

    GNUnet uses could start using it.
    Talker users should move to it.
    And it wouldn't be that hard to do a gnunet-chat client that would show those jumpy smilies like any IM...

  6. Milan3:43 PM

    Interesting... But don't you think we could try to implement a Jabber encapsulation instead of reinventing the wheel ? The issue here is you will have to code your UI to chat, and to manage more and more complex chatting protocol inside GNUnet. And chatting via gnunet-gtk won't be as nice as using Gaim.

    If we were able to simply add a framework to make Jabber work through GNUnet, this will allow to use classical clients, and don't bother about the protocol. We could use GPL code used in Jabber servers, and tell the clients to connect to localhost. GNUnet would only have to forward the messages, translating usernames to keys, and to check whether they're valid.

    What do you think ?

  7. gnunet-chat can be lot's of things - that's for sure. It can be something IRC-like, it can be (as you're suggesting) IM-like, or it can be Talker-like (as I'm suggesting). OR you can do all those three. What catches me with the talker-like gnunet-chat is that, besides the fact that it has, in its conception, a lot more flexibility. It is, in its essence, a virtual world, so if you want to build a virtual world (arguably any kind of VW) it would be possible to. If you want to create an IRC-like interface, it's feasable (and already done to other talkers, no innovation here). Finaly, if you want to to a jabber-proxy (I would rather see a piece of middleware that would recieve jabber messages and translate them to gnunet-chat ones than seeing gnunet to be used as yet-another-jabber-server, even if distributed), it also was done in the past. But that's looking in the "gnunet" prespective. In the "talkers" prespective, you might want to read this article, and will surely see that my gnunet-chat purpose would solve the issues raised there, and some more.

    I don't know if this actualy replies properly to your question... but if it doesn't, feel free to comment. This is the right time to discuss this, since, as I see it, gnunet-chat's development is going to start soon.

  8. Milan9:21 PM

    OK, I was just trying to say that we shouldn't work much on the chat UI, but rather try to use the standards, allowing to chat via GNUnet in clients really well-designed and popular. Maybe middleware is the appropriate term for this: I wasn't talking of a central proxy server.

    Now the question is: could we implement a GNUnet internal framework design that would allow to forward messages to chat clients using different protocol, and different conceptions (IRC, IM...) ? I'm really not a specialist of these questions. Anyway, it's good you're thinking about this!

  9. Exactly.

    "Now the question is: could we implement a GNUnet internal framework design that would allow to forward messages to chat clients using different protocol, and different conceptions (IRC, IM...) ?"

    Well, my idea is that if you can do a flexible-enough "protocol" on the gnunet-site (which I'm calling gnunet-chat, but maybe that name is more apropriate for a simple "client" implementation), then you can have gnunet-chat to be the "anonymous, encrypted, censorship-resistent, blablabla" version of any of those things (talkers, IMs, VWs, IRC, you name it). We're also seeing some development on the other side of the road: it was yesterday that finaly this website was created, to give a frontpage to it's wiki and Trac. That links to "Tints", and the idea behind it is to define both "an architecture and a protocol" for talkers. Now, the idea is to have it broaden-enough, so I guess that "The Tints Specification" should be good enough to use as the specs for gnunet-chat (we have to see how to use that protocol with gnunet as a "server"), and, if not, it will be so close to it, that we could just "embrace and extend". It would be nice to have a decision regarding this, since both sides would benefict if gnunet-chat devels and tints specification devels were working together for this.