You are here


FreeServices is not a concept of mine, but it is a concept that is still present on GNUnet's "todo" list, even if a description of it, unfortunately, isn't present on the new website anymore. So, for the sake of documentation, here is the text from GNUnet's old website regarding FreeServices (with only small changes):


At the moment, GNUnet implements one application (file-sharing) and plans to implement another (chat).
Most of the existing and well-known Internet services could transmit data through GNUnet and thus establish anonymous connections between publishers and receivers.
This concept proposes "GNUnet FreeServices" as an application-independent solution without the need to modify existing protocols and software.

Status of this document

This document is currently an early request for comments. Important details may be added, changed or left out in the final implementation.

Setting up a FreeService

Every Internet service that is to be published through GNUnet has to be defined in a central configuration file that is stored on the computer that runs gnunetd:

[My homepage]
[My mailboxes]

In this example, a FreeService called "My Homepage" (actually a "Freesite") is defined. The webserver (perhaps Apache) serving it runs locally on port 8080. Because Google is known to censor search hits in certain countries, we (who are living in a free country) also relay anonymous traffic to them. After that, we accept anonymous mail destined to us. Our mailserver (perhaps Sendmail or qmail) runs at port 25 and accepts mail for our anonymous domain (see below). Finally, we relay all ( IRC traffic (port 6667).

For every FreeService, a RSA key is generated. The hash of the Public Key is used as an unique identifier just like a domain name (FQDN). The private key is used to digitally sign responses to proof authenticity.
The "destname" specification is used to rewrite our anonymous domain name to a official domain name. This is important for virtual HTTP hosting (multiple domains on a single server) and mail over SMTP (so the mail server doesn′t have to be configured to accept mail for our anonymous domain.).
Server side

1. An encrypted request for a FreeService is received as usual (port 2086)
2. The request gets decrypted by the core of gnunetd and is forwarded to the FreeService module (just like FS or Chat messages).
3. The FreeService module connects to the destination as defined in the configuration file (webserver at port 8080, for example), forwards the request (HTTP GET, for example) and forwards the response to the core of gnunetd, that in turn sends it to the requester through the GNUnet network.

Client side

Client connections are always routed through a special GNUnet SOCKSv5 proxy to the GNUnet server that makes the requested FreeService available. This SOCKS proxy accepts TCP-stlye requests and forwards it to the local GNUnet server (its FreeService module to be precisely) which forwards the request to the GNUnet server homing the FreeService. Depending on the application/protocol, an application proxy has to be put in front of the SOCKS proxy. This is recommended in case the protocol compromises anonymity (anonymizing HTTP proxy). [Picture]
Addresses and Hyperlinks

As described above, every FreeService is identified by the hash of its Public-Key. Therefore, it can be used to construct an URI. Example:



Because such a URI is hard to remember, the SOCKS proxy maintains a database of alternative names. In that way, an alias "mysite" could be defined for the hash above:


Because there′s no way to set up a central registry for such names (as for German domain names), they are only stored for local use.

To request content from .gnunet-Sites, a browser has to be configured to forward all requests to the GNUnet SOCKS proxy. The proxy server checks the domain name for the postfix ".gnunet" and forwards these requests to the GNUnet server. Requests besides the TLD ".gnunet" are treated as normal requests and are forwarded to either the destination server or a final HTTP proxy server (yours or your provider′s).

Links to non-anonymous content

A freesite may embed or link to pictures or other content. In case this is not done through the .gnunet-Address, but the usual address (, for example), the requester looses anonymity when requesting the content: the request does not get routed through GNUnet, but a normal - maybe not encrypted - direct connection to the destination server. To circumvent this, an additional proxy server has to be added in front of the SOCKS proxy. This proxy checks every "normal" request whether it is the result of a link on an anonymous page (through the HTTP header "Referrer"). In this case, a warning message is returned first.

Mail addresses look like those presented above. Mail is sent to susan@D9HF28EPQ403TSJH8333UIFG85JDM56.gnunet or susan@mysite.gnunet. To accept these addresses, the mailreader has to be configured to forward all mail to the GNUnet SOCKS proxy. It checks for the TLD ".gnunet" and sends the mail through GNUnet if necessary.